Almost every day, on Slack, I am treated to the product question.

Not an abstract one. Not a grand reflection on the five-year vision. A real question from the field.

Can we do this?

What happens if the customer sets the product up like that?

What is the limit?

Does this rule apply in that case too?

Why does the product block here?

Can we promise this to the customer?

Some of these questions are strategic. They call for an understanding of the market, the customer, the positioning, the direction we want to take. Those need a product manager. They need judgement. Sometimes you have to say no, sometimes make a call, sometimes own a direction.

But plenty of questions are not of that kind.

They are about how the product actually behaves.

A rule. A limit. An exception. A constraint. A use case. A configuration. An interaction between two features.

And there, in theory, the answer should be simple.

The trouble is that it is not always simple.

The hidden cost of the product question

When the question is a fine-grained one, opening the documentation is not always enough.

First, because the documentation does not always exist.

Then, because it sometimes exists, but nobody knows whether it is still up to date.

And finally, because the real question is often about an edge case nobody has documented explicitly.

So you do what every PM, CSM, support agent or developer does when in doubt: you test.

You open a test environment.

You prepare a data set.

You replay the scenario.

You check whether the product blocks, accepts, computes, displays, hides, triggers, sends, refuses.

And half an hour has gone.

Sometimes an hour.

Sometimes more.

That time shows up nowhere. It is not in Jira. It is not in the roadmap. It is not in the estimates. It is simply absorbed into the normal running of the organisation.

There is another cost too, even more invisible: context switching.

The question rarely arrives at a good moment. It arrives because a customer is waiting. Because a sales rep is in a meeting. Because a CSM is preparing a review. Because support has to answer before the end of the day.

So you break off what you were doing. You get into the subject. You test. You answer. Then you try to get back to what you were on before.

That is not just lost time. It is a lost train of thought.

And it is exactly the kind of task AI should absorb.

The problem is not the question. It is the source.

One answer would be: just write better documentation.

In theory, yes.

In practice, no.

Product documentation is almost always behind the real product. This is not a matter of individual discipline. It is not only that someone forgot to update a page.

It is more structural than that.

A spec describes an intent. A PRD describes a goal, the rules expected, the scenarios. A mockup describes a desired interface. But between that intent and production, something always happens.

Compromises get made.

Details get adjusted.

Edge cases turn up.

Decisions are taken during development.

Technical constraints force small changes to the behaviour.

Discussions happen in a pull request or a merge request.

The calls made along the way do not always find their way back into the original documentation.

None of that is necessarily a problem. It is fairly normal, in fact. A living product is not built like a frozen document.

But it has one simple consequence: the spec is not the truth about the product.

It is a useful approximation at a given moment.

The truth is what runs.

And what runs is the code.

Code as the source of product truth

Production is the reality.

Not the spec.

Not the PRD.

Not the Notion page.

Not the PM's recollection.

Not the Slack conversation from three weeks ago.

To know how the product really behaves, you have to look at what has shipped. And what has shipped is carried by the source code.

Put like that, it may sound brutal. You might read it as: "throw away all your documentation."

That is not the idea.

The right distinction is not between "code" and "documentation".

The right distinction is between what explains and what describes.

You keep what explains.

You regenerate what describes.

The Contexts have to be kept. They hold the discussions, the sources, the reasoning, the ideas that led to a choice. They are reusable building blocks.

The decisions have to be kept. When a company picks a direction, you need to keep the why. Why this choice? Which alternatives were set aside? Why does this decision supersede an earlier one?

That is what Product Decision Records — PDRs — are for. I have written about this already: a PDR does not describe a feature, it records a structural product decision.

Some constraints also have to stay accessible: contractual and regulatory constraints, external documents, specific commitments. Not everything can be derived from the code.

But the documentation that describes product behaviour should, as far as possible, be regenerated from the code.

Because the code is the truth about the behaviour that was implemented.

What AI makes possible

Until now, this idea had an obvious limit.

Code is code.

It is not always readable for support. It is not always readable for sales. It is not always readable for a C-level. It is not even always easy to read for a PM, especially one without a technical background.

So for a long time an intermediate layer was needed. Specs. Support documents. Product pages. Changelogs. Tables. Diagrams.

AI changes that equation.

It can become the interface between a business question and the source code.

A support agent can ask: "What happens if the customer cancels this item after approval?"

A CSM can ask: "Under what conditions does this workflow get stuck?"

A sales rep can ask: "Can we promise this configuration to this prospect?"

A PM can ask: "Where is this rule implemented and which cases are not covered?"

And the AI can go and look in the code, in the Git history, in the merge requests, in the feature flags, in the business Contexts, and then produce a readable answer.

Not a magic answer.

A grounded answer.

A good product answer has to show its evidence

That is the key point.

If the AI answers without evidence, it becomes one more approximate piece of documentation. Faster, more elegant, but not necessarily more reliable.

So you have to force the AI to ground its answer.

When it states that a rule exists, it has to say why.

Not just: "the product works this way".

But: "the product works this way because this function applies that rule, because this exception blocks that case, because this merge request introduced that behaviour, because this test covers that scenario".

The evidence does not have to sit at the centre of the answer. For support or sales it can live at the bottom of the document. Not everyone needs to read the technical detail.

But it has to be there.

Its presence changes how the AI behaves. It can no longer answer by plausibility alone. It has to tie its statements to factual elements.

It is the same logic as in text analysis. If I ask an AI to analyse a corpus, I would rather it gave me, for every conclusion, the sentence or the paragraph it rests on. That cuts hallucinations sharply.

For a product question, it is the same.

The evidence can be a file.

A function.

An exception.

A test.

A commit.

A merge request.

A pull request.

A feature flag.

A product decision.

A business source.

Without that, you are only moving the problem. You replace the PM's imperfect memory with a model's probabilistic memory.

That is not enough.

You also have to say what you do not know

A good product answer should not only answer.

It should also say where it gets stuck.

That is an essential directive.

The AI has to be able to write:

"I found no test covering this case."

"The code shows two possible behaviours depending on the state of the feature flag."

"I cannot determine the exact behaviour for this customer without access to their configuration."

"The PDR states one rule, but the code appears to implement something else."

"The current support documentation contradicts the behaviour observed in the code."

It is uncomfortable, but it is valuable.

A serious human does the same. When they do not know, they say so. When they have a doubt, they flag it. When they need to test, they test.

The goal is not to pretend the AI knows everything.

The goal is to cut the cost of looking things up while making the answer more traceable.

Not every audience needs the same read

A product question can matter to several teams.

Support often wants an answer they can use in front of the customer.

The CSM wants to understand the usage and the impact.

Sales want to know what they can promise, and which value to put forward.

The PM wants to check the rule, the limit, the exception.

Leadership may want to understand what is at stake strategically.

You could therefore imagine a different answer for each audience.

But that is not necessarily needed.

One answer can be structured along several angles. A short part that answers the question. A support part. A usage part. A value part. A limitations part. An evidence part.

Everyone reads what they need.

And sometimes it is genuinely useful for a sales rep to see a product limit, or for a CSM to understand the technical origin of a behaviour. It depends on the company culture. Some organisations prefer to restrict information. Others gain in maturity by sharing it.

This is not a purely technical question.

It is a question of culture.

The building blocks you need

Technically, plugging an LLM into a Git repository and hoping for the best is not enough.

Several tools complement each other.

RAG lets you find the right fragments. It is often very effective at surfacing the relevant pieces in a large mass of documents or in a big codebase.

But RAG is not always enough. It finds. It does not necessarily get you around.

A semantic graph can help you explore what sits nearby: related concepts, neighbouring modules, connected rules, events that trigger other events.

Walking the filesystem is still essential too. Once you have identified an area, you sometimes need to read the directory, open the neighbouring files, understand the local structure. It is less elegant than a vector search, but often very effective.

Git brings another dimension: time.

The current code tells you what exists. The history tells you how you got there. Commits, pull requests and merge requests can reveal the intent, the discussions, the compromises, the fixes.

Feature flags add one more nuance. The code can hold several possible behaviours. Which one is real then depends on the state of the flag.

If the AI has no access to that state, it has to answer conditionally: if the flag is on, the behaviour is this; if not, it is different.

If it has access to the environment, it can go further: for this particular customer, in this particular configuration, the active behaviour is that one.

That step matters. The product question is not always about abstract code. Sometimes it is about the product as a particular customer experiences it.

The condition: code that speaks the business

There is one basic condition, though.

The code has to represent the business.

If the code is spaghetti, if the business concepts are hidden behind technical names, if the rules are scattered, if the exceptions do not carry the vocabulary of the domain, then the AI will struggle.

But that is not a new limitation.

A human developer will struggle too.

A technical PM will struggle too.

A team trying to evolve the product will struggle too.

Code that does not represent the business is not good code. It forces a permanent translation between the business need and the software machinery. Every change means rebuilding that link in your head. Every debugging session costs more. Every rule gets harder to find.

That is exactly why approaches like DDD have been around for a long time. The idea was not born with AI.

AI simply makes the requirement more visible.

If you want to query the code as the source of product truth, the code has to speak the language of the product.

The entities have to carry the names of the business.

The actions have to be readable.

The events have to tell you what happened.

The exceptions have to express rules, not only technical errors.

The policies have to make the knock-on reactions visible.

The modules have to have a predictable structure.

An exception like ElementAnnuléNonModifiable is not just an error message. It is a business rule written in code.

That is the kind of code that becomes queryable.

Not because the AI is magic.

Because the business is already there in the material it reads.

From the one-off answer to regenerated documentation

Answering a Slack question is the first use case.

It is not the only one.

If you can answer a product question from the code, you can also regenerate part of the product documentation.

You can produce a support FAQ.

Keep a living article about a feature up to date.

Generate a changelog.

Reconstruct a spec from the current state of the product.

Produce sales documentation that is more reliable about what can and cannot be promised.

The logic is always the same: do not maintain by hand artefacts that describe real behaviour, when that behaviour can be rebuilt from the source of truth.

Specs do not disappear entirely.

They change status.

Before production, they serve the conversation.

They let you discuss, explore, frame, decide.

After production, they should no longer claim to be the lasting truth about the product.

They become regenerable.

This is not a religious rule

You obviously have to keep some pragmatism.

Not every company can apply this to the letter.

Some carry a heavy documentation legacy.

Some have difficult legacy code.

Some have strong regulatory constraints.

Some do not yet have enough technical culture.

Some have poorly recorded product decisions.

Some cannot expose the same information to every team.

So this is not about saying: delete all your documentation tomorrow morning.

That would be absurd.

It is about shifting the centre of gravity.

Stop treating descriptive documentation as the source of truth.

Stop asking the PM to check by hand, again and again, what the product already does.

Stop maintaining by hand artefacts that mechanically drift out of date.

And start building a system where the code, the decisions, the Contexts and the sources talk to each other.

More than a product method

Really, the product question is only one particular case.

It reveals a wider shift.

For a long time, a company's information system was made of databases, document repositories, wikis, tickets, spreadsheets, folders, documents.

You searched.

You read.

You copied things over.

You updated.

You forgot.

With AI, you can start doing something else.

You can hold a conversation with the information system.

You can ask a question.

You can ask for evidence.

You can explore the neighbouring ideas.

You can go back through the history.

You can spot a contradiction.

You can regenerate an artefact.

The product question is a good way in because it is concrete. It costs time every day. It interrupts work. It exposes the gap between documentation and production.

But behind it, the subject runs deeper.

This is not only about helping support answer faster.

It is about making the company queryable from its real sources.

And in the case of the product, the real source of behaviour is the code.