A documentation that is always behind

We have all lived through it: a bug appears, or a functional change needs to be handled. The first reflex is to consult the documentation. And, more often than not, it is no longer up to date.

In reality, we almost know in advance that it won't be. The pattern is familiar: documentation is produced, handed over with the specification, and then development begins. Along the way, questions come up, trade-offs are made, certain points evolve, and developers sometimes make decisions without systematically coming back to the product manager. This is normal. Otherwise, work would move at the pace of constant validation. The result, however, is always the same: documentation and code end up drifting apart.

This divergence also comes down to a very simple constraint. With every change, however minor, no one really has the time to go back and hunt for the right specification, the right mockup, the right support document, or the right changelog in order to update everything. We work around a living product, one that evolves continuously. In that context, maintaining all the artifacts by hand quickly becomes too costly relative to the time available.

The more time passes, the worse the problem gets. Today, a feature is no longer designed once and for all: it is adjusted, enriched, corrected, sometimes over months or years. Under those conditions, it is unrealistic to hope to keep the initial specification, the project discussions, the changelog, the support documentation, the sales documentation, and the mockups perfectly synchronized.

Code as the source of truth

The true deliverable, ultimately, is the code. It may not be the official phrasing, but it is the code that describes the real state of the product. Everything else merely tries to keep up with it. In that respect, the expression "Code is Law" remains particularly apt: https://framablog.org/2010/05/22/code-is-law-lessig/

For a long time, this situation was unavoidable. Natural-language documentation was the least bad solution, not least because most product managers do not work directly in the code. An intermediate layer was therefore needed—understandable by everyone, usable in meetings, shareable with the teams, and workable without any particular technical skill.

What AI changes

AI now changes this equation. When the code is clean and documented enough, it becomes possible to use it as a workable source for rebuilding or updating other deliverables. You can, for instance, start from the real code to update support documentation after a release, generate a more reliable changelog, or reconstruct a functional specification from the current state of the product rather than from an old document.

Code is no longer merely the final deliverable: it becomes the central element, the source of truth around which the product's other artifacts gravitate and are rebuilt, in a genuinely code centric logic.

The question of technical literacy

But this raises another question: how can a non-technical product manager take advantage of this possibility?

Today's tools are powerful, but they cannot be used without discernment. They can help you produce quickly, automate certain tasks, and generate useful building blocks. However, as soon as you touch architecture, overall coherence, or maintainability, their limits appear quickly. Without a minimum of technical literacy, the risk is to pile up small tools that are effective locally but poorly connected to one another. You save time here and there, then lose it again later moving data around, dealing with inconsistencies, or maintaining a whole that has become hard to understand.

The challenge, then, is not only to produce faster. It is to produce within a coherent framework. It is that coherence that makes the difference between an accumulation of tools and a genuine working system.

From this point of view, there is probably already a capability gap between PMs from a technical background and those who are not. Not because the former are intrinsically better than the latter, but because they now have an additional lever: they can act more directly on the very material of the product—that is, the code—and use it as a basis to generate, check, or challenge other artifacts.

One could object that SaaS products will increasingly embed agents capable of automating these tasks. That is likely, and it will be real progress. But I don't think it will be enough to erase the difference. Most of these tools will remain specialized.

That is precisely where the limit appears. A tool like Zendesk will probably help produce better support documentation. A tool like Figma will remain excellent for designing screens. But neither, on its own, has a complete view of the real product as it exists in the code, as it evolves in the merge requests, and as it must be understood in its business context.

Today, with the right tools, I can for example cross several levels of information: the source code, the history of changes, the merge requests, and the business rules I have accumulated as a product manager. This makes it possible not only to generate more accurate documentation, but also to challenge what already exists.

The same logic applies to design. Today, you draw an interface in Figma, then it has to be developed. But if I am able to rebuild a design system from the real code, keep it up to date as the repository evolves, and add the team's development conventions to it, then the mockup changes status. It is no longer merely a representation: it can start to become a first working basis for front-end developers.

In other words, the boundary between design, implementation, and documentation is starting to shrink. This is not only a matter of productivity. It is a deeper transformation: code is no longer simply the endpoint of the work, it also becomes the raw material from which the rest can be rebuilt.

What MCP will change

I don't claim that this model is already settled. In a few months, it may be partly outdated. MCP, in particular, could still shift the balance. One can imagine a future ecosystem in which each SaaS would have its own layer of agents, able to talk to other systems. Figma could, for instance, pull context from a GitLab repository, read recent changes, understand the relevant merge requests, and better align design with the reality of the product. We are not entirely there yet, but the direction is becoming visible.

That is why MCP seems important to me. Just as APIs became indispensable when SaaS products stopped living in isolation, MCPs could become essential as agents become widespread. Each tool will keep its specialty, but the real value will come from its ability to talk to the others, to pull context, and to act within an ecosystem larger than its own perimeter.

The best attitude, at this stage, is probably to experiment seriously. Not to follow a trend, but to understand what already, concretely, makes it possible to create value. Because the change under way is not only technological. It touches the very nature of the product's deliverables, their source of truth, and the product manager's place in producing them.

Further reading

Adding session memory, like OpenClaw In 8 days, I understood that the Product Manager job was about to change completely Quality belongs to those who ship The product question should start from the source code