How can product managers find out whether something can be built, or was built before, without a meeting with engineers?
Ask a context engine that reads your code, pull requests, tickets, docs and Slack. It can tell you whether the feature exists, whether someone tried it and stopped, and which services and data it would touch, with links to each source. It cannot give you an estimate. That part still needs an engineer, but it becomes a short written question instead of a meeting.
Product managers can answer most of "was this built before?" and much of "can this be built?" on their own, by asking a tool that reads the code, pull requests, tickets, design docs and Slack together. The first question is a search problem. The answer sits in a merged pull request, a closed ticket or an old thread. The second splits in two. What exists today, what data is there and what stopped the last attempt are all written down somewhere. How long the work would take and how risky it is still needs an engineer. A prior-art check is the search a product manager runs before raising an idea: has this shipped, been tried, or been ruled out, and why. Run it first and the meeting with engineering shrinks to one written question.
Why this question still turns into a meeting#
The answer usually exists. Product managers just can't reach it without engineering help. In the 2026 Stack Overflow Developer Survey, "people you work with" was still the top source for work answers at 72 percent, ahead of code and comments at 63 percent and internal docs at 60 percent (Stack Overflow). If developers go to a person first, a product manager who can't read the code has no other option.
Coordination time is also scarce. Atlassian's State of Teams 2026 surveyed 12,035 knowledge workers. It found 87 percent say they lack the time or capacity to coordinate once everyone is in execution mode (Atlassian). A "quick sync to see if this is possible" lands on the people with the least spare time. We analyzed 284 sales calls from May to October 2026, and five companies asked this exact question. Our post you are the context engine covers what that costs the engineer on the other end.
Where "was it built before?" is actually written down#
Prior work leaves traces in four places. Each has its own search, and each needs the right words.
- Pull requests, including the ones that never merged. GitHub search filters pull requests by state, and
is:unmergedfinds pull requests "that are either open or were closed without being merged" (GitHub Docs). A closed, unmerged pull request is often the best evidence that someone tried and stopped. - Tickets. In Jira,
text ~ "customize"searches all text fields, and word stemming applies (Atlassian Support). Tickets closed as won't-do tend to carry the reason in their comments. - Slack. Modifiers such as
in:,from:andduring:narrow a search to a channel, a person or a time period (Slack). Decisions often get made here, informally. - Design docs and the code itself. The design document describes what was planned. The code describes what actually shipped.
Doing this by hand is a prior-art check across four tools. It works if you know the feature's internal name, the right channel and roughly when it happened. Most product managers don't, which is why they end up asking an engineer to remember.
Which parts of "can it be built?" a tool can answer#
A feasibility check is the set of smaller questions behind "can we build this?" Most of them have written answers. Take a made-up example: you want bulk export for invoices.
| Question | Where the answer lives | Can a tool answer it? |
|---|---|---|
| Does something close already exist? | The code: maybe a report export job that could take a new record type | Yes |
| Is the data there? | The schema and the service that stores the field | Yes |
| What blocked it last time? | A pull request comment such as "not until the billing migration lands" | Yes, and it may show the blocker is gone |
| Who owns this area? | Recent commits and reviews | Yes |
| How long would it take, and how risky is it? | An engineer's judgment | No |
| Should we do it this quarter? | The team's priorities | No |
The last two rows are judgment calls. Treat any AI estimate of engineering effort as a guess.
How a context engine runs the check for you#
A context engine is a service that reads code, pull requests, tickets, docs and chat together and returns one answer with links to the sources it used. You ask in plain language, without knowing project names or where to look.
Unblocked is one such engine. It connects to GitHub, GitLab, Bitbucket or Azure DevOps, plus Jira, Linear, Confluence, Notion, Slack and Teams (Unblocked docs), and answers in Slack or Teams, the web app, or a coding agent through MCP (Unblocked docs). With Data Shield on, an answer only contains material the asker is allowed to see in each source system (Unblocked docs). A product manager can ask "Have we ever built bulk export for invoices, and if someone tried, why did it stop?" Each answer lists the resources it used at the bottom, and clicking one opens the original (Unblocked docs). Chris Hovanessian, Group Product Manager at Cloudbeds, describes the shift: "Engineers could always read the code. I never could. Unblocked levels that playing field. It gives product people first class access to how and why the system works, without an active translator. And because it's an MCP, it plugs into whatever tooling you already use." (Cloudbeds customer story)
The source links are the point. A March 2026 benchmark of language models on repository questions found that "overall accuracy remains limited for repository-scale comprehension" (arXiv). Check the source before repeating it. In the same Stack Overflow survey, 93 percent of respondents said trusting AI output requires source attribution. Reading decision history out of tickets and threads is covered in why was this built this way and in our answer on asking why code was written this way.
What to send engineering instead of a meeting invite#
Once the check is done, write the engineer one message with four parts. The lines below use the invoice example, with an invented pull request number and history.
- What you found. "Bulk export for reports exists; PR #2210 added it."
- What was tried before. "An invoice export was attempted in 2024 and closed; the thread says it was blocked on the billing migration."
- What you think it touches. The services and data the answer pointed to.
- The one question you can't answer. "Is the migration done, and is this a week or a quarter?"
An engineer can usually answer that in a reply, because the searching and the history are already done. If the answer is "it's complicated," you now have a meeting worth having. For how other non-engineering roles use the same approach, see codebase answers for product managers and support and our answer on support and sales getting answers without GitHub access.
