A product question needs an engineer only when its answer is not a fact in the code. A default value, a limit, whether a feature exists or when something changed are facts: they are written down somewhere, and you can read them without interrupting anyone.
The rest (why a choice was made, what is planned, what is negotiable) belongs to a person. The whole job is knowing which side a question falls on before you ask it.
One day of questions, sorted
Here is a fictional day, labeled illustrative, for a product manager and a salesperson. Each question was put to an engineer. For each one, ask what it was really looking for.
9:10 a.m., sales: "The prospect asks whether export handles more than 10,000 rows." → A fact in the code: a limit. The answer sits in a constant and in the last change that touched it. No person needed.
10:30 a.m., PM: "Do invitations still expire after seven days?" → A fact in the code, with a trap: the value may have changed since the help page was written. The diff says so. No person needed.
11:00 a.m., sales: "Do we have an integration with this billing tool?" → Whether a feature exists is a code fact. But the answer must separate "the code exists" from "it is turned on for customers". The first is readable; the second is a release decision.
2:20 p.m., PM: "Why did we remove the old settings screen?" → Half fact, half reason. The code shows when and in which commit; it does not always say why. The commit message and the pull request sometimes keep the trace. Otherwise, ask the one person who knows, once.
4:45 p.m., sales: "Can we promise this feature to the customer for next quarter?" → Not a code fact. It is a commitment. This one deserves a person, or rather whoever owns the roadmap.
Out of five questions, two settle themselves, two call for care in how they are phrased, one needs a person. The ratio is an example, not a rule, but it shows the point: the sorting happens by reading the question, not by asking it.
Three filters before you message someone
- Does the answer exist without anyone having to invent it? If so, it is a fact. Look it up.
- Does it depend on a date? An answer that held last month may not hold now. Ask since when it has been true.
- Does it commit someone? A promise, a deadline, a priority: that is a decision, not a reading.
If the answer is "fact, datable, no commitment", it does not need an engineer. It is a matter of access, not expertise.
Why people ask anyway
It is not laziness. Reading code is not an option for a non-developer, and written documentation is suspect because it has misled them before. Asking a colleague is the only reliable path, and it costs an interruption. Sorting the questions that bounce back to a developer already exists on the support side: this is the same mechanism seen from product and sales.
The fix is not to discourage questions but to give them another route. An answer that cites the file or the change it comes from can be checked in ten seconds by someone who does not read code. That is what an interrogable product expert does, and why a human asker agrees to use it.
The objection: "a tool can be wrong, a colleague cannot"
A colleague is wrong too, with fewer traces. The difference is that a sourced answer can be challenged: you see what it rests on. Apply the opposite rule to the one used for people: an answer without a source is worth nothing, and "I don't know" is a valid result that sends you to a person.
For high-stakes questions (a contractual commitment, compliance), keep the engineer's review. The tool is there so you do not have to ask for it on everything else.
The mirror objection: "we can already read GitHub"
Yes, if you can read code and have access. A product manager or a salesperson often has neither, and granting repository access to answer a prospect's question is out of proportion. A read-only MCP server that answers instead of exposing the code skips that step. For the access model in detail, see giving AI agents safe access to your code.
What DeployIt does here
DeployIt reads the real code (resynchronized on every push) and the git history, commits and diffs, through its own MCP servers, and checks the code before asserting. Read-only, revocable at any time. A question about a limit, a value or a change gets an answer that cites its source, and silence when the source is missing. DeployIt does not settle a commitment or a priority: those decisions stay with your team. The same foundation powers a living help center and an MCP server, in early access / design partner program.
Frequently asked questions
Do salespeople need training to ask these questions? Hardly any. A plain-language question is enough. What can be learned is spotting the ones that are commitments.
What if the answer depends on a customer's configuration? Then the code alone is not enough. The answer should say so and point to whoever knows the configuration.
Does this eliminate questions to engineers? No, it removes the ones that were never theirs. The rest, which nobody else can settle, arrive better framed.
Key takeaways
Sort the question before you ask it: fact, datable, no commitment, and it can be read. Otherwise it is a decision, and it goes to a person.
DeployIt is free during early access; paid plans arrive in January 2027. The MCP server is in early access / design partner program, and the program is open.
Frequently asked questions
Which product questions do not need an engineer?
The ones whose answer is a fact in the code: a default value, a limit, whether a feature exists, when something changed. Questions about intent, priority or a future decision still belong to a person.
How can a product manager query the code without reading it?
By asking in plain language a tool connected read-only to the repository, which answers and cites what it found. DeployIt's MCP server, in early access / design partner program, works this way.
Can an answer drawn from the code be wrong?
Yes, if the question was badly framed or the behavior depends on configuration that is not in the repository. Hence the rule: an answer must cite its source and say when it does not know.