Product Context Layer
The connective tissue between customer, business, and code has always been product's job. Here is what changes when it becomes infrastructure instead of a person.
An engineer opens a ticket, reads it twice, and still cannot tell why the feature has to work this way instead of the three other reasonable ways. The ticket describes the what. Nobody wrote down the why, because the why lived in a Slack thread from March, a customer call nobody recorded, and a tradeoff a VP made verbally in a hallway. The engineer picks a reasonable interpretation and ships it. It is wrong, not because the engineer was careless, but because the information that would have made it right was never in a place anyone could query.
That gap has a name in product management circles now: product context. A product context layer is a governed record of why a product is the way it is: the customer problem a decision answers, the business constraint that shaped it, and the tradeoff a team already made and does not intend to remake, kept current and attached to the part of the system it governs, so anyone or anything building the next piece can find it without asking around. The boundary was never the file format; it's whether the complete seven-property set is deliberately supplied, not any one habit alone. Versioning in git gets durable history. Review before merge gets an admission gate and provenance, if the reviewers actually have standing. A check for contradictions gets integrity. None of that supplies a queryable schema or selective retrieval on its own; those need building in too. Only when all seven are actually present, the file-backed shape this post's own linked definition describes assembling by hand, does a spec or roadmap become a product context layer. This is the shorthand version; the full requirement set, selective retrieval, a schema, concurrency, durable history, integrity constraints, provenance, and admission control, is laid out where the term was first defined precisely.
Where the idea comes from
Product management writing has circled this same job for decades without settling on one name for it. Ben Horowitz and David Weiden's essay "Good Product Manager, Bad Product Manager," now hosted by Andreessen Horowitz and still widely circulated decades later, draws the line at synthesis: a good PM knows the market, the customer, and the technology well enough to turn all three into one coherent story the rest of the company can build against; a bad PM has a list of excuses for why that story never got written down. Clayton Christensen's Jobs to Be Done framework makes the same point from the customer side: a feature only makes sense once you can state the job the customer hired it to do, and that job is exactly the kind of fact that can get stripped out when a rich spec gets reduced to a thin ticket. Melissa Perri's Escaping the Build Trap names what an organization defaults to when that synthesis doesn't happen: it measures itself on output, features shipped, tickets closed, velocity, and ships to the schedule instead of to the customer problem those outputs were supposed to solve. Perri's claim is about what gets measured. The reasoning-goes-unrecorded story is this post's addition to it, not hers.
None of these sources call it a product context layer. All of them are describing the same missing layer from a different angle: the connective tissue between why a customer needs something, why the business will fund it, and why the team is building it this particular way. What's new is not the idea. The need to externalize it was already real before any of this: the same need shows up in onboarding, cross-team alignment, and review, all older than AI agents. What changed is the scale and the latency it has to run at. When the only things reading it were other people, an occasional gap could be patched with a Slack message and a short wait. An interactive agent still can, up to a point. The constraint shows up on the work that doesn't run that way: unattended, many agents on many tasks in parallel with no one watching any single one. Waiting on a timely human answer at every fork erases the speed that kind of work exists to provide. Reasoning that isn't already written down somewhere those agents can read doesn't get asked about there. It gets guessed.
Why engineering teams specifically need this
Fred Brooks made the relevant distinction in "No Silver Bullet" back in 1986: a piece of software's essence is the conceptual construct itself, the data, the relationships among that data, the algorithms, and the functions that invoke them, and the hard part of building software is specifying, designing, and testing that construct. Accidental complexity is everything layered on top by the representation: the language, the tooling, the friction of expressing the construct in code. Every tooling advance since, better languages, better frameworks, and now agents that write the code outright, has attacked accidental complexity. Brooks himself named ways to attack the essential work too, rapid prototyping to pin down requirements and growing a system organically through use and testing rather than building it whole, and modern agents can help draft a plan or a spec the same way. None of that eliminates the specification and design work; it speeds it up and makes it better informed, and it still runs on inputs no tool supplies on its own: the customer problem, the business constraint, the decision already made about how this system should behave.
Product context is one of those inputs, not a stand-in for essential complexity itself. As accidental complexity keeps getting cheaper to remove, the essential work is what's left, and a product context layer supplies its inputs: the customer problem, the constraint, the decision already made. An engineering team that has it stops re-deriving those inputs from code never designed to hold them. A team without it still does the same design work, just blind, reconstructing inputs an agent or an engineer needed and never had.
What having it changes, and what not having it costs
| With a product context layer | Without one | |
|---|---|---|
| Onboarding | A new engineer or a new agent reads the decision attached to the code, not just the code | Onboarding runs through senior people's memory and availability, and it does not scale past their calendar |
| Agent defaults | An agent hits a fork and finds the decision that already resolved it | An agent hits the same fork with the task prompt, codebase, rules file, and conversation, none of which necessarily says which choice the team made, and picks the most probable answer instead |
| Cross-team alignment | Design, engineering, and support work from the same recorded reasoning | Each function reconstructs its own version of "why," and the versions quietly disagree |
| Decision durability | A superseded decision is marked superseded, so old reasoning cannot resurface as current | Old Slack threads and stale docs get treated as current, because nothing marks them otherwise |
| Review load | Reviewers check the work against a stated decision | Reviewers have to reconstruct the decision themselves before they can check anything against it |
The pattern across every row is the same. Nothing about not having a product context layer stops work from happening. It just moves the cost from being written down once to being reconstructed, imperfectly, by every person and every agent who touches that part of the system afterward.
How teams actually move faster with one
The acceleration is not from deciding faster. It's from not re-deriving the same decision from scratch every time someone downstream needs it. A team without a context layer pays a small, recurring cost every time someone has to rediscover a decision before they can safely build on it, and that cost compounds with every additional person and every additional agent who touches the same part of the system blind. Nobody puts a line item on it, because it never arrives as one bill; it arrives as a steady background rate of rework spread across every team that builds on that part of the system afterward. A team with a context layer still pays a real cost: capturing the decision once, and keeping it current as it changes or gets superseded. What changes is that the cost is paid once per decision instead of once per person who later needs it, and it is a maintenance cost you can see, not a tax nobody can find on the books.
Product management is the glue job
Strip away the job titles and the org charts, and what product management does, in Horowitz and Weiden's essay and in every "voice of the customer" tradition since, is sit at the point where customer need, business reality, and engineering constraint have to be reconciled into one direction. That is a synthesis job, not a documentation job, and it has never had a natural home. It happened in meetings, in one person's judgment, in a PRD that summarized a hundred conversations nobody else was in. The glue was real. It just was not visible or queryable by anything except the person holding it.
A product context layer does not replace that synthesis. It is what the synthesis looks like once it stops living only in a person's head and starts living somewhere every function, and every agent, can read from. The glue job does not go away. It gets a place to put the glue.
Engineering is accelerating. The glue has to keep up.
We've written elsewhere about the personal side of this, the judgment gap opening up for individual product managers as coding agents compress build time on the routine work that's actually fast now. This is the systemic side of the same shift. As routine product work, the standard flows and CRUD screens, not the novel architecture, keeps getting faster to ship with an agent, the bottleneck stops being how fast code gets written and becomes how fast the reasoning behind it can reach every engineer and every agent working in parallel, at the moment each of them needs it. A person holding that reasoning in meetings does not scale to that many simultaneous consumers. A layer built to hold it and serve it on demand does.
That's the gap Brief is built to close: it keeps the decisions and the reasoning behind them current and attached to the part of the system each one governs, and surfaces the right piece to an engineer or an agent at the moment they're about to build against it. Not a faster meeting. A faster path from a decision made once to that decision being available everywhere it applies.
None of that writing was ever wrong about what the job is. What changes is whether the job has to move at the speed of a person's calendar, or at the speed of everything now building on top of it?
Frequently asked questions
What is a product context layer? A governed record of the reasoning behind a product's decisions, not just the decisions themselves, kept current and attached to the part of the system it governs. It answers why a choice was made a particular way. A spec or roadmap becomes one only when it deliberately supplies the complete seven-property set below, not through versioning or review habits alone, which cover some of the seven but not a schema or selective retrieval on their own. The full requirement set, selective retrieval, a schema, concurrency, durable history, integrity, provenance, and admission control, lives where the term was first defined precisely.
How is product context different from a spec or a roadmap? Not by file format. A spec or roadmap becomes one only if it deliberately carries the complete seven-property set, selective retrieval, a schema, concurrency, durable history, integrity, provenance, and admission control, not just the two or three that versioning and review habits happen to cover.
Why do AI coding agents need product context specifically? An interactive agent can pause and ask a person a question. The constraint shows up on work that doesn't run that way: unattended, many agents on many tasks in parallel with no one watching any single one, where waiting on a timely human answer at every fork erases the speed that mode exists to provide. If the reasoning behind a decision was never written down somewhere those agents can read, they proceed without it and guess.
How does a product context layer help product managers, not just engineers? It takes the synthesis a PM already does across functions and gives it a place to live besides that PM's memory and the meetings where it gets discussed. The judgment does not change. What changes is whether an engineer or an agent building against that judgment has to interrupt someone to get it, or can just look it up.
← Back to Blog