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 organisations already know how to produce documents. They know how to write PRDs, frame briefs, feed roadmaps, phrase tickets, document decisions and prepare prioritisation reviews. In a mature product company, the problem is not that nothing gets written.

The problem is that much of what gets written doesn't really bank the reasoning.

A PRD answers an opportunity. It explains what you want to do, for whom, why, why now, on what assumptions, with what risks, what expected impact and what constraints. It is useful. It can even be indispensable for aligning a team, a product committee, a leadership group or a go-to-market organisation.

But once the decision is made, much of what made that PRD possible scatters. Customer feedback stays in transcripts. Sales objections stay in the heads of the sales team. Adoption constraints stay with the CSMs. The calls that were made stay in a set of minutes. Weak signals stay in support. The deeper reasons behind the decision stay in the PM's memory.

Six months on, the organisation starts again almost from scratch.

It digs out documents, asks for explanations again, rebuilds arguments, rereads notes, goes back to the same people, or decides on a thinner version of the context. The cost is not only a documentation cost. It is strategic: the next decisions are slower, but also worse, because they don't draw fully on the context the company has already accumulated.

So the point 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 putting all the available context to work: customer feedback, past calls, converging signals, domain knowledge, reliable sources, sales objections, adoption constraints and examples drawn from other segments or situations.

That ability becomes a competitive advantage.

What sets the Context architect PM apart is not that they talk to customers. It is that they turn customer knowledge into a reusable organisational asset: captured, structured, connected, shared and fed back into product and go-to-market decisions.

In a market where technology is more open to everyone, the 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 becomes 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 rivals, handle more volume, or offer capabilities others didn't have.

That advantage was also tied to upfront capital. Sometimes you had to put down a large sum before you had even validated your market or won enough customers. The cost of getting to the technology created a barrier.

That world is gone. The technical building blocks are far more open. Cloud, APIs, SaaS, AI: much of modern infrastructure is now bought as you use it. You pay gradually, in line with usage, instead of having to fund capacity heavily before the market is validated.

The consequence is simple: access to technology is much less often the lasting differentiator. Two competitors can draw on the same clouds, the same AI models…

Building something is no longer enough. Building fast is often no longer enough either.

The difference lies in how relevant the thing you build actually is.

And that relevance depends on understanding the customer's context: the real stakes, the economic constraints, the regulation, the evidence they are obliged to produce, the company culture, the alternatives, the organisational habits, how responsibility is actually spread, the hidden costs, the objectives, the fears and the unsaid.

Public sources give everyone a common base. Anyone can read the same white papers, the same web pages, the same reports and the same reference material. What is far harder to copy is the private conversations, the transcripts, the objections, the day-to-day accounts, the internal constraints, the friction around adoption and the calls customers have actually had to make.

Customer knowledge then becomes a strategic asset — provided it doesn't stay raw.

A conversation, a verbatim quote or a customer signal doesn't automatically become context. To be reusable, they have to be turned into clear ideas, sourced and connected: an objection, a stake, a constraint, a piece of evidence, an alternative, a call. It is that structuring work that moves customer knowledge from raw input to organisational asset.

The problem: the PRD is often an expense, not capital

The PRD is a good illustration of the problem.

In many organisations, it exists to make a decision or to get a subject moving. It pulls together enough context to answer one specific opportunity. Then it becomes a local reference document, tied to a project, an initiative, a period, a team.

But the reasoning underneath is not always banked.

Take a PRD justifying a new financial reporting capability. It may contain a clear synthesis: problem, target, solution, dependencies, risks. But what made that synthesis possible is usually far richer.

The Context approach means pulling reusable units of knowledge out of those documents and conversations: atomic notes, thematic notes, glossaries, links (a knowledge network), evidence, examples and past calls. The PRD is no longer the only place the reasoning exists. It becomes one visible output of a deeper body of knowledge capital.

This logic changes the economics of product work.

Without banked context, each PRD is a one-off local effort. With structured context, each PRD enriches the next one. Knowledge doesn't restart from zero. It thickens.

What a Context actually is

A Context is not a document system.

A document system stores documents. A product Context surfaces, stabilises and connects the elementary ideas coming from several sources: customer feedback, transcripts, sales calls, support tickets, CS notes, past decisions, competitive analysis, usage data, reliable sources and domain knowledge.

A Context is not a warehouse. It is a system for making sense of things.

You can read it on three levels:

1. The raw inputs: interviews, tickets, calls, verbatim quotes, usage data, sources, decisions.
2. The units you bank: atomic notes, thematic notes, glossaries, evidence, past calls.
3. The business uses: PRD, roadmap, positioning, sales narrative, onboarding, strategic analysis.

The document system mostly preserves the first level. The Context creates the passage between all three.

In a classic document system, an idea can stay trapped inside a long document. You vaguely know a subject has already been looked at, but nobody knows where, with what conclusion, 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 stabilises a self-contained idea. A thematic note assembles several blocks around an angle or a tension. A glossary makes the terms clear, so 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 call 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, qualified by a new segment, contradicted by an edge case or connected to a later decision.

That is why the Context approach doesn't ask you to document more. It asks you to bank better.

AI sharpens the point. For a leader, the subject isn't understanding concepts like RAG at a technical level. The subject is giving AI access to the right internal building blocks of knowledge, so it can find them, put them back in the right context and recombine them into a decision, a brief, a positioning or an analysis.

An AI plugged into a heap of documents produces fragile syntheses. An AI plugged into a structured Context can help the organisation find the right signals, the right past calls, 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 approach doesn't guarantee a decision will be good. But it raises the odds that it is taken on fuller, better connected and sturdier material.

It improves decisions along four dimensions.

1. It lowers the cost of rediscovery. The organisation doesn't have to rebuild the same arguments, the same constraints or the same evidence every time.

2. It improves how things are read. 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 tends to see mainly through its own lens. But a Context that aggregates input from PM, PMM, Sales, CS, Support, customers and outside sources raises the chances of spotting what one person alone would have missed.

4. It makes the calls easier to defend. A decision no longer rests only on intuition or on one person's memory. It can be connected to evidence, to converging signals, to segment stakes and to explicit strategic choices.

Evidence is not mathematical certainty. It is built by convergence.

The mechanics: capture, structure, connect, share, feed back

The Context architect PM is not a records keeper. Nor are they only an interviewer, a prioritiser or a writer of PRDs.

Their role is to turn scattered knowledge into an organisational asset.

That transformation comes down to five moves. This is the minimum operating method for an organisation that wants to make Context into capital.

Capture. The Context feeds on interviews, transcripts, sales calls, support feedback, CS exchanges, domain watch, competitive intelligence, reliable sources, usage data, past decisions and weak signals. Every function can capture customer information, but they don't analyse 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 attached to a segment, a strategy, a constraint, a piece of evidence or an alternative. Structuring doesn't mean filing things away neatly. It means making the information thinkable and actionable.

Connect. A useful Context connects objects that would otherwise stay apart: a sales objection and a limit in the positioning, friction in adoption and a cultural constraint, a feature request and a regulatory stake, a support ticket and a debt in product understanding, a competing alternative and a market category.

Share. Customer context can't stay in the PM's head. It has to travel to Product Marketing, Sales, CS, Support, leadership, design and engineering. But it has to travel without being thinned out. A synthesis is useful, but the raw material has to stay reachable when it needs reinterpreting.

Feed it back. Context is only worth something if it comes back into decisions: roadmap, positioning, category, messaging, sales narrative, onboarding, service, content, pricing, packaging, strategic calls.

These mechanics give a concrete direction. It isn't about building a great product library. It's about building a loop that turns what the company learns into better future decisions.

In practice, an organisation can start with a simple question: for each important decision, which Context building blocks were captured, structured, connected, shared and fed back? If the answer is vague, the system still rests too much on individuals and not enough on shared capital.

What this changes for go-to-market

Customer context is not only a product asset. It is a go-to-market asset.

The same Context building block 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, 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 organisation holding shared capital that each function can recombine for its own use.

That is a significant 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, Sales sees an objection, the CSM sees friction in adoption. All these readings are useful, but they stay weak if they never connect.

With banked Context, those lenses enrich the same memory. Product understands better what it has to build. Product Marketing understands better how to make the value legible. Sales understands better how to make that value land in a concrete situation. The CSM understands better how the context shifts after purchase.

Context then becomes shared infrastructure for decisions and for the story told: it feeds the roadmap, the positioning, the sales narrative, onboarding, content, pricing, packaging and strategic calls.

What this changes for the customer

Customer knowledge isn't only there to sell better or prioritise better. It can also be handed back to the customer as capability.

There are three flows to distinguish:

• knowledge about customers: their segments, constraints, behaviours, obligations, organisations;
• knowledge coming from customers: their accounts, objections, uses, workarounds, frustrations, calls;
• knowledge for customers: what the product gives back to make them more capable.

That third dimension is often underrated.

A regulatory audit module, for example, isn't only there to tick a functional box. If it helps the customer understand what they have to do, automate part of the work, produce evidence and feel covered by a reliable knowledge base, it makes them calmer, more productive and more competent.

A good product doesn't stop at carrying out a task. It improves the customer's capability to deal with their own context.

Don't build better cameras; build better photographers. — Kathy Sierra, Badass: Making Users Awesome

What an organisation has to change

So the practical question is: what does an organisation have to change if it wants to run on Context?

First, it has to stop treating the PRD as the main home of product reasoning. The PRD stays useful, but it has to become an output of a deeper knowledge system.

Then it has to organise its knowledge material around what really informs decisions: stakes, situations, evidence, past calls, the segments concerned and earlier decisions.

It has to keep the raw sources reachable when they're needed: transcripts, verbatim quotes, sales calls, support tickets, CS feedback. Syntheses are useful, but they must not remove the ability to reinterpret.

It also has to create reusable building blocks: atomic notes, thematic notes, glossaries, link maps, bodies of evidence. Those blocks have to be able to feed several deliverables: PRD, roadmap, positioning, sales narrative, onboarding, strategic analysis.

Finally, it has to set up a loop between functions. PM, PMM, Sales, CS and Support must not each hold a different version of the customer. They have to contribute to a shared memory, while keeping their own lenses.

The expected benefit isn't only about documentation. It is operational and strategic:

• faster decisions;
• sturdier decisions;
• less rediscovery;
• better onboarding for PMs, PMMs and leaders;
• better coherence between product, marketing and sales;
• a better ability to spot segment stakes;
• better use of non-public customer knowledge;
• better use of AI, because internal knowledge is better structured.

Context then becomes capital.

Conclusion: the 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 artefacts disappears.

But they shouldn't be the centre of the system.

They should be the visible outputs of deeper knowledge capital: a living product Context, structured, queryable and reusable.

In an environment where technology is more open, 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 precisely what creates value for a given segment.

That understanding can't stay in the heads of a few people. It has to become an organisational asset.

The Context architect PM is the one who makes that shift possible. They capture the signals, trace them back to the stakes, keep the calls that were made, structure the ideas, connect the evidence, make the contradictions visible, feed the positioning, inform the sales narratives, nourish the roadmap and build a memory the organisation can reuse.

The role becomes all the more strategic as AI makes producing artefacts easier. If everyone can generate briefs, tickets, syntheses or message variants faster, the difference won't come from the volume of artefacts produced. It will come from the quality of the Context those artefacts rest on.

A product organisation that can turn its private conversations, its past calls and its converging signals into reusable memory holds something its competitors cannot copy overnight.

It isn't only documenting its past.

It is building its future ability to decide.