Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
This article is the theoretical development of the example presented in the article One file, a few directives, and Claude does the rest — how I structured 500 emails effortlessly Developed in this article From the Single File to a System of Contexts: Why an LLM's Memory Won't Fit in One Document
Product organizations already know how to produce documents. They know how to write PRDs, frame briefs, feed roadmaps, phrase tickets, document decisions and prepare prioritization reviews. In a mature product company, the problem is therefore not that nothing gets written.
The problem is that much of what gets written doesn't truly capitalize on the reasoning.
A PRD responds to an opportunity. It explains what we want to do, for whom, why, why now, on what assumptions, with what risks, what expected impacts and what constraints. It is useful. It can even be essential to align a team, a product committee, a leadership group or a go-to-market organization.
But once the decision is made, much of what made that PRD possible gets scattered. Customer feedback stays in transcripts. Sales objections stay in the heads of the sales team. Adoption constraints stay with the CSMs. Trade-offs stay in a meeting report. Weak signals stay in support. The deeper reasons for the decision stay in the PM's memory.
Six months later, the organization starts over almost from scratch.
It digs up documents, asks again for explanations, reconstructs arguments, rereads notes, re-interviews the same people, or decides with an impoverished version of the context. The cost is not only documentary. It is strategic: the next decisions are not only slower, but also worse, because they don't fully benefit from the context the company has already accumulated.
The point, then, is not to document the product better. The point is to build a system that lowers the cost of the next decisions and improves their quality by mobilizing all the available context: customer feedback, past trade-offs, converging signals, domain knowledge, reliable sources, sales objections, adoption constraints and examples drawn from other segments or situations.
This capability becomes a competitive advantage.
The PM as context architect doesn't stand out because they talk to customers. They stand out because they turn customer knowledge into a reusable organizational asset: captured, structured, connected, shared and fed back into product and go-to-market decisions.
In a market where technology is more accessible, advantage no longer comes only from what you can build. It comes from the quality of the context that guides what you choose to build.
Why this topic is becoming strategic now
For a long time, access to certain technologies could create a direct competitive advantage. A company able to fund expensive infrastructure, a high-performance database or complex systems could move faster than its competitors, handle more volume or offer capabilities others didn't have.
That advantage was also tied to upfront capital. Sometimes you had to lay out a large sum before you had even validated your market or acquired enough customers. The cost of accessing technology created a barrier.
That world is gone. The technical building blocks are far more accessible. Cloud, APIs, SaaS, AI… : much of modern infrastructure is consumed on demand. You pay gradually, based on usage, instead of having to massively fund capacity before validating the market.
The consequence is simple: access to technology is less often the durable differentiator. Two competitors can draw on the same clouds, the same AI models…
Producing something is no longer enough. Producing fast isn't always enough anymore either.
The difference lies in the relevance of what gets built.
And that relevance depends on understanding the customer's context: the real stakes, the economic constraints, the regulation, the evidentiary obligations, the company culture, the alternatives, the organizational habits, the actual distribution of responsibilities, the hidden costs, the objectives, the fears and the things left unsaid.
Public sources provide a common baseline. Everyone can read the same white papers, the same web pages, the same reports and the same reference content. What is far less copyable are the private conversations, the transcripts, the objections, the everyday stories, the internal constraints, the adoption frictions and the trade-offs customers actually live through.
Customer knowledge then becomes a strategic asset — provided it doesn't remain raw material.
A conversation, a verbatim quote or a customer signal don't automatically become context. To be reusable, they must be transformed into clear ideas that are sourced and connected: an objection, a stake, a constraint, a piece of evidence, an alternative, a trade-off. It is this structuring work that moves customer knowledge from raw material to organizational asset.
The problem: the PRD is often an expense, not capital
The PRD is a good illustration of the problem.
In many organizations, it serves to make a decision or launch a topic. It gathers enough context to respond to a specific opportunity. Then it becomes a local reference document, tied to a project, an initiative, a period, a team.
But the underlying reasoning is not always capitalized on.
Take a PRD that justifies a new financial reporting capability. It may contain a clear summary: problem, target, solution, dependencies, risks. But what made it possible to arrive at that summary is often far richer.
The context-based approach consists of extracting from these documents and conversations reusable units of knowledge: atomic notes, thematic notes, glossaries, links (a knowledge network), evidence, examples and trade-offs. The PRD is no longer the only place where the reasoning lives. It becomes a visible output of a deeper body of knowledge capital.
An atomic note is a note centered on a single unit of thought: a concept, a claim, a relationship between two ideas or a precise question.
It isn't necessarily short. It is atomic because it has a single conceptual center of gravity: everything it contains serves the same idea.
For an organization, its value is very concrete: it can be understood without reopening the original source, connected to other notes, reused across several decisions, and enriched over time with new examples, sources or contexts. An atomic note is therefore neither a quote, nor an excerpt, nor a document summary. It is a reusable building block of reasoning.
This logic changes the economics of product work.
Without capitalized context, each PRD is a local effort. With structured context, each PRD enriches the next one. Knowledge doesn't start over from scratch. It grows denser.
What context actually is
Context is not a document management system.
A document management system stores documents. A product context surfaces, stabilizes and connects elementary ideas drawn from several sources: customer feedback, transcripts, sales calls, support tickets, CS notes, past decisions, competitive analyses, usage data, reliable sources and domain knowledge.
Context is not a warehouse. It is a system of interpretation.
You can read it on three levels:
- Raw materials: interviews, tickets, calls, verbatim quotes, usage data, sources, decisions.
- Units of capitalization: atomic notes, thematic notes, glossaries, evidence, trade-offs.
- Business uses: PRD, roadmap, positioning, sales narrative, onboarding, strategic analysis.
A document management system mostly preserves the first level. Context creates the passage between all three.
Context doesn't add a documentary layer. It transforms scattered materials into reusable building blocks of reasoning.
In a classic document management system, an idea can stay trapped inside a long document. We vaguely know that a topic has already been studied, but no one knows where, with what conclusion, based on what evidence, or under what conditions that conclusion could be reused.
In a context system, the reasoning is broken down into connected building blocks. An atomic note stabilizes a standalone idea. A thematic note assembles several building blocks around an angle or a tension. A glossary clarifies terms so that people don't use the same words with different meanings.
The format matters less than the principle: atomicity, source, link, reuse.
An atomic idea can feed a PRD today, a roadmap trade-off tomorrow, a sales narrative in three months, an onboarding in six months or a strategic article later on. It can be reinforced by a new source, nuanced by a new segment, contradicted by an edge case or connected to a later decision.
That is why the context-based approach doesn't ask you to document more. It asks you to capitalize better.
AI sharpens this point. For an executive, the issue isn't understanding, in technical terms, concepts like RAG. The issue is giving AI access to the right internal knowledge building blocks so it can retrieve them, place them back in the right context and recombine them into a decision, a brief, a positioning or an analysis.
RAG makes it possible to retrieve knowledge by proximity of ideas, not just by keywords.
The benefit is simple: even if teams don't use the same vocabulary, AI can retrieve the notes, evidence or decisions that speak to nearby ideas. RAG connects ideas more than words.
An AI plugged into a heap of documents produces fragile summaries. An AI plugged into structured context can help the organization retrieve the right signals, the right trade-offs, the right examples and the right evidence.
The quality of the AI then depends on the quality of the context the company has built.
How context improves decisions
The context-based approach doesn't guarantee that a decision will be good. But it raises the odds that it will be made with material that is more complete, more connected and more robust.
It improves decisions along four dimensions.
1. It lowers the cost of rediscovery. The organization doesn't have to reconstruct the same arguments, the same constraints or the same evidence every time.
2. It improves the quality of interpretation. A current request can be compared with past signals, comparable situations, earlier decisions, sales objections and adoption constraints already observed.
3. It makes blind spots more visible. A PM can miss a subtlety. A team can see mostly through its own lens. But context that aggregates the input of PM, PMM, Sales, CS, Support, customers and external sources raises the odds of spotting what a single person wouldn't have seen.
4. It makes trade-offs more defensible. A decision is no longer carried solely by an intuition or by one person's memory. It can be tied to evidence, to converging signals, to segment stakes and to explicit strategic choices.
Evidence isn't mathematical certainty. It is built through convergence.
Context doesn't just help you decide faster. It helps you decide with a better memory, more evidence, more nuance and fewer blind spots.
The mechanics: capture, structure, connect, share, feed back
The PM as context architect is not a documentalist. Nor are they merely an interviewer, a prioritizer or a PRD writer.
Their role is to turn scattered knowledge into an organizational asset.
This transformation comes down to five movements. It is the minimal operating model of an organization that wants to make context a form of capital.
Capture. Context feeds on interviews, transcripts, sales calls, support feedback, CS exchanges, domain monitoring, competitive monitoring, reliable sources, usage data, past decisions and weak signals. Every function can capture customer information, but they don't analyze it through the same lens.
Structure. A request becomes a signal. A signal is connected to a situation. A situation reveals a stake. A stake is tied to a segment, a strategy, a constraint, a piece of evidence or an alternative. Structuring doesn't mean tidying things up neatly. It means making information thinkable and actionable.
Connect. A useful context connects objects that would otherwise stay separate: a sales objection and a positioning limitation, an adoption friction and a cultural constraint, a feature request and a regulatory stake, a support ticket and a gap in product understanding, a competitive alternative and a market category.
Share. Customer context can't stay in the PM's head. It has to flow toward Product Marketing, Sales, CS, Support, leadership, design and engineering. But it has to flow without being impoverished. A summary is useful, but the raw material must remain accessible when reinterpretation is needed.
Feed back. Context has value only if it comes back into decisions: roadmap, positioning, category, messaging, sales narrative, onboarding, service, content, pricing, packaging, strategic trade-offs.
This mechanic gives a concrete direction. It's not about building a great product library. It's about building a loop that turns what the company learns into better future decisions.
In practice, then, an organization can start with a simple question: for each important decision, which building blocks of context were captured, structured, connected, shared and fed back? If the answer is fuzzy, the system still relies too much on individuals and not enough on collective capital.
What this changes for go-to-market
Customer context isn't just a product asset. It's a go-to-market asset.
The same building block of context can be reused by several functions, but not to produce the same deliverable.
A recurring regulatory stake can feed a roadmap decision on the Product side, a differentiation message on the Product Marketing side, a proof of value on the Sales side, an adoption journey on the CSM side and reassurance content on the marketing side. The value doesn't come from copying the same information everywhere. It comes from the fact that the organization has common capital that each function can recombine to suit its use.
This is an important shift. Without shared context, each function rebuilds its own version of the customer: the PM sees a product problem, the PMM sees a perception problem, the Sales sees an objection, the CSM sees an adoption friction. These readings are all useful, but they stay weak if they don't connect.
With capitalized context, these lenses enrich the same memory. Product understands better what it should build. Product Marketing understands better how to make the value legible. Sales understands better how to make that value resonate in a concrete situation. The CSM understands better how the context evolves after the purchase.
Context then becomes a shared infrastructure for decisions and storytelling: it feeds the roadmap, the positioning, the sales narrative, onboarding, content, pricing, packaging and strategic trade-offs.
What this changes for the customer
Customer knowledge isn't only there to sell better or prioritize better. It can also be returned to the customer as a capability.
We can distinguish three flows:
- knowledge about customers: their segments, constraints, behaviors, obligations, organizations;
- knowledge from customers: their stories, objections, uses, workarounds, frustrations, trade-offs;
- knowledge for customers: what the product gives back to them to make them more capable.
This third dimension is often underestimated.
A regulatory audit module, for example, doesn't just tick a functional box. If it helps the customer understand what they must do, automate part of the work, produce evidence and feel covered by a reliable knowledge base, it makes them more at ease, more productive and more competent.
A good product doesn't just carry out a task. It improves the customer's ability to deal with their context.
Don't build better cameras — build better photographers. — Kathy Sierra, Badass: Making Users Awesome
What an organization must change
The practical question, then, is: what must an organization change if it wants to operate through context?
It must first stop treating the PRD as the main home of product reasoning. The PRD stays useful, but it should become an output of a deeper knowledge system.
It must then organize its knowledge materials around what genuinely informs decisions: stakes, situations, evidence, trade-offs, segments concerned and past decisions.
It must make the raw sources accessible when they are needed: transcripts, verbatim quotes, sales calls, support tickets, CS feedback. Summaries are useful, but they must not remove the possibility of reinterpreting.
It must also create reusable building blocks: atomic notes, thematic notes, glossaries, link maps, bundles of evidence. These building blocks must be able to feed several deliverables: PRD, roadmap, positioning, sales narrative, onboarding, strategic analysis.
Finally, it must put in place a loop between functions. PM, PMM, Sales, CS and Support must not each own a different version of the customer. They must contribute to a shared memory, while keeping their own lenses.
The expected benefit isn't only documentary. It is operational and strategic:
- faster decisions;
- more robust decisions;
- less rediscovery;
- better onboarding of PMs, PMMs and leaders;
- better coherence between product, marketing and sales;
- better ability to detect segment stakes;
- better exploitation of non-public customer knowledge;
- better use of AI, because internal knowledge is better structured.
Context then becomes capital.
Conclusion: context is the asset, the PRD is an output
The backlog stays useful. The PRD stays useful. The brief stays useful. The roadmap stays useful. None of these artifacts disappear.
But they should not be the center of the system.
They should be the visible outputs of a deeper body of knowledge capital: a living, structured, queryable and reusable product context.
In an environment where technology is more accessible, where competitors can draw on the same building blocks, where customers compare faster and where alternatives keep multiplying, the difference lies in the ability to understand finely what creates value for a given segment.
This understanding can't stay in the heads of a few people. It must become an organizational asset.
The PM as context architect is the one who makes this transformation possible. They capture the signals, trace them back to the stakes, preserve the trade-offs, structure the ideas, connect the evidence, make contradictions visible, feed the positioning, inform the sales narratives, nourish the roadmap and build a memory the organization can reuse.
This role becomes all the more strategic as AI makes producing artifacts easier. If everyone can generate briefs, tickets, summaries or message variants faster, the difference won't come from the volume of artifacts produced. It will come from the quality of the context those artifacts rest on.
A product organization that knows how to turn its private conversations, its trade-offs and its converging signals into reusable memory possesses something its competitors cannot copy overnight.
It doesn't just document its past.
It builds its future ability to decide.
Further reading
In software, the edge will no longer be technology. It will be understanding the context. Why a single classification isn't enough to structure customer feedback AI Wiki: why I built a knowledge base maintained by an AI The second brain is a dead end for product management What Is an Atomic Note? What Is a Glossary Entry? What Is a Thematic Note?