Almost every day, on Slack, I get the product question.

Not an abstract question. Not some grand reflection on the five-year vision. A real, on-the-ground question.

Can we do this?

What happens if the customer configures the product like that?

What's the limit?

Does this rule also apply in this case?

Why does the product block here?

Can we promise this to the customer?

Some of these questions are strategic. They require understanding the market, the customer, the positioning, the direction we want to take. In those cases, you need a product manager. You need judgment. You sometimes need to say no, to arbitrate, to own a direction.

But many questions aren't of that kind.

They're 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 problem is that it isn't always.

The hidden cost of the product question

When the question is precise, opening the documentation isn't always enough.

First because the documentation doesn't always exist.

Then because it sometimes exists, but you don't know whether it's still up to date.

Finally because the real question often concerns an edge case that nobody documented explicitly.

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

You spin up a test environment.

You prepare a dataset.

You replay the scenario.

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

And half an hour has gone by.

Sometimes an hour.

Sometimes more.

That time shows up nowhere. It's not in Jira. It's not in the roadmap. It's not in the estimates. It's simply absorbed by the normal running of the organization.

There's also another cost, even more invisible: the context switch.

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

So you interrupt what you were doing. You dive into a topic. You test. You answer. Then you try to get back to what you were doing before.

It's not only a waste of time. It's a loss of intellectual continuity.

And this is precisely the kind of task AI should absorb.

The problem isn't the question. It's the source.

You could reply: just get better documentation.

In theory, yes.

In practice, no.

Product documentation is almost always behind the real product. This isn't a matter of individual discipline. It's not just because someone forgot to update a page.

It's more structural.

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

Compromises are made.

Details are adjusted.

Edge cases appear.

Decisions are made during development.

Technical constraints force slight changes to the behavior.

Discussions happen in a pull request or a merge request.

Trade-offs don't always make it back into the original documentation.

This isn't necessarily a problem. It's actually quite normal. A living product isn't built like a frozen document.

But it creates one simple consequence: the spec isn't the truth of the product.

It's a useful approximation at a given moment.

The truth is what's running.

And what's running is the code.

Code as the source of product truth

Production is reality.

Not the spec.

Not the PRD.

Not the Notion page.

Not the PM's memory.

Not the Slack conversation from three weeks ago.

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

Put that way, it can sound brutal. You might think it amounts to saying: "throw away all the documentation."

That's not the idea.

The right distinction isn't between "code" and "documentation."

The right distinction is between what explains and what describes.

You keep what explains.

You regenerate what describes.

Contexts must be preserved. They contain the discussions, the sources, the reasoning, the ideas that led to a choice. They're reusable building blocks.

Decisions must be preserved. When a company chooses a direction, you have to keep the why. Why this choice? Which alternatives were ruled out? Why does this decision replace an earlier one?

That's the role of Product Decision Records, or PDRs. I've written about this before: a PDR doesn't describe a feature, it traces a structuring product decision.

Some constraints must also remain accessible: contractual and regulatory constraints, external documents, specific commitments. Not everything can be inferred from the code.

But the documentation that describes product behavior should, as much as possible, be regenerated from the code.

Because the code is the truth of the implemented behavior.

What AI makes possible

Until now, this idea had an obvious limitation.

Code is code.

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

For a long time, you therefore needed an intermediate layer. 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 validation?"

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

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

A PM can ask: "Where is this rule implemented, and which cases aren't covered?"

And AI can go dig through the code, the Git history, the merge requests, the feature flags, the business contexts, then produce an understandable answer.

Not a magic answer.

A grounded answer.

A good product answer must show its evidence

That's the key point.

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

So you have to force AI to ground its answer.

When it asserts that a rule exists, it must say why.

Not just: "the product works this way."

But: "the product works this way because such-and-such function applies this rule, because such-and-such exception blocks this case, because such-and-such merge request introduced this behavior, because such-and-such test covers this scenario."

The evidence doesn't necessarily have to be at the center of the answer. For support or sales, it can sit at the bottom of the document. Not everyone needs to read the technical details.

But it must exist.

Its presence changes AI's behavior. It can no longer answer by plausibility alone. It has to tie its assertions to factual elements.

It's the same logic as in text analysis. If I ask an AI to analyze a corpus, I'd rather it give me, for each conclusion, the sentence or paragraph it relies on. That sharply limits hallucinations.

For a product question, it's 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 only shift the problem. You replace the PM's imperfect memory with a model's probabilistic memory.

That's not enough.

You also have to say what you don't know

A good product answer must not only answer.

It must also say where it gets stuck.

This is an essential directive.

AI must be able to write:

"I didn't find a test covering this case."

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

"I can't determine the exact behavior for this customer without access to their configuration."

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

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

It's uncomfortable, but it's valuable.

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

The goal isn't to make people believe AI knows everything.

The goal is to reduce the cost of research while increasing traceability.

Not every audience needs the same reading

A product question can concern several roles.

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

The CSM wants to understand usage and impact.

Sales want to know what they can promise, and what value to highlight.

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

Leadership may want to understand the strategic stakes.

You could therefore imagine a different answer for each audience.

But that isn't necessarily needed.

The same answer can be structured along several angles. A short part to answer the question. A support part. A usage part. A value part. A limits part. An evidence part.

Everyone reads what they need.

And sometimes it's actually useful for a salesperson to see a product limit, or for a CSM to understand the technical origin of a behavior. It depends on the company's culture. Some organizations prefer to limit information. Others mature by sharing it.

This isn't a purely technical question.

It's a question of culture.

The necessary building blocks

Technically, it isn't enough to plug an LLM into a Git repository and hope it all works.

Several tools are complementary.

RAG lets you retrieve the right fragments. It's often very effective at surfacing the relevant pieces in a large mass of documentation or in a big codebase.

But RAG isn't always enough. It retrieves. It doesn't necessarily travel.

A semantic graph can help explore nearby elements: related concepts, neighboring modules, connected rules, events that trigger other events.

Walking the filesystem also remains indispensable. Once you've identified a zone, you sometimes have to read the directory, open the neighboring files, understand the local structure. It's less elegant than a vector search, but often very effective.

Git adds another dimension: time.

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

Feature flags add yet another nuance. The code can contain several possible behaviors. The actual behavior then depends on the state of the flag.

If AI doesn't have access to that state, it has to answer conditionally: if the flag is on, then the behavior is this; otherwise, it's different.

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

This part matters. The product question isn't always about the code in the abstract. It's sometimes about the product as a specific customer experiences it.

The condition: code that speaks the business

There is, however, a basic condition.

The code must 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 don't carry the vocabulary of the domain, then AI will struggle.

But this isn't a new limitation.

A human developer will struggle too.

A technical PM will struggle too.

A team that wants to evolve the product will struggle too.

Code that doesn't represent the business isn't good code. It constantly imposes a translation between the business need and the software mechanics. Every change requires mentally rebuilding that link. Every debug becomes more expensive. Every rule becomes harder to find.

That's exactly why approaches like DDD have existed for a long time. The idea wasn't born with AI.

AI simply makes that requirement more visible.

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

Entities must carry the names of the business.

Actions must be readable.

Events must tell what happened.

Exceptions must express rules, not just technical errors.

Policies must make cascading reactions visible.

Modules must have a predictable structure.

An exception like CancelledItemNotEditable isn't just an error message. It's a business rule written in code.

That's the kind of code that becomes queryable.

Not because AI is magic.

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

From the one-off answer to regenerated documentation

Answering a Slack question is the first use case.

But it's 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.

Update a living article about a feature.

Generate a changelog.

Reconstruct a spec from the product's current state.

Produce more reliable commercial documentation about what can be promised or not.

The logic is always the same: don't maintain by hand artifacts that describe the real behavior if that behavior can be reconstructed from the source of truth.

Specs don't disappear entirely.

They change status.

Before production, they serve the dialogue.

They let you discuss, explore, frame, decide.

After production, they should no longer pretend to be the durable truth of the product.

They become regenerable.

It's not a religious rule

You obviously have to keep some pragmatism.

Not every company can apply this down to the millimeter.

Some have a heavy documentation legacy.

Some have difficult legacy code.

Some have strong regulatory constraints.

Some don't yet have a strong enough technical culture.

Some have poorly traced product decisions.

Some can't expose the same information to every role.

So it's not about saying: tomorrow morning, delete all your documentation.

That would be absurd.

It's about shifting the center of gravity.

Stop treating descriptive documentation as the source of truth.

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

Stop maintaining by hand artifacts that mechanically diverge.

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

More than a product method

Fundamentally, the product question is only a special case.

It reveals a broader transformation.

For a long time, the company's information system was made of databases, documentation bases, wikis, tickets, tables, folders, documents.

You searched.

You read.

You copied.

You updated.

You forgot.

With AI, you can start doing something else.

You can have a dialogue with the information system.

You can ask a question.

You can demand evidence.

You can explore neighboring ideas.

You can go back through the history.

You can detect a contradiction.

You can regenerate an artifact.

The product question is a good entry point because it's concrete. It costs time every day. It interrupts the work. It reveals the divergence between documentation and production.

But behind it, the subject runs deeper.

It's not only about helping support answer faster.

It's about making the company queryable from its real sources.

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

Further reading

Code Centric Product Decision Record: tracing the product choices that shape the company AI Wiki: why I built a knowledge base maintained by an AI