The Product Loop

A PRD is a set of claims about why to build something and what “built” would mean, and most of a first draft’s claims are guesses until someone checks them against the people and the product. The Product Loop is how an idea becomes a stream that has been checked — framed, its assumptions named, and its premise attacked before a single card is written.

A product brief that reads as finished is not one that is right

A stream’s brief is written once and read by every planning session after it, none of which can ask its author what was meant. It can read as settled and still rest on a premise nobody tested — who actually has the problem, how they solve it today, what would count as solving it. So the Product Loop holds every brief to three rules: never assert why users need something you have not heard a user say, never carry an assumption as a fact, and never seed a card off a premise you have not tried to break.

Five phases, from an idea to a stream with its first cards

The loop runs on a stream, and its output is the stream’s PRD — one document of five fixed sections. A friction pass sits between the fourth phase and the fifth, before any card is seeded.

  1. Frame → OverviewFind or make the stream, then write the Overview: the problem this stream exists to solve, who has it, why it matters now, and the shape of the outcome — the product story, not the solution’s mechanics.revise_prd_section
  2. Current stateWrite down how the thing is done today — by users and by the product — and where it falls short, with the specifics that make the gap real. A guess about behaviour is an assumption, not a fact, and belongs in the next section.revise_prd_section
  3. AssumptionsName every load-bearing guess the stream rests on, and give each a falsifier — the observation, run or question that would prove it wrong — so a planner knows which premises are soft and a later card can close one by checking it.revise_prd_section
  4. Definition of DoneSay what “done” means for the whole stream, in outcomes rather than tasks: the observable results that, once true, mean it delivered what the Overview promised. A card’s own plan carries its tasks; this is the product bar the sum of the cards must clear.revise_prd_section
  5. The friction passBefore the stream reaches engineering, push back on it — hard — the way the Planning Loop attacks a plan: the idea itself, the load-bearing assumptions, the stage breakdown, and whether the shape is buildable at all. It is a discipline, not a gate; nothing blocks on it but the honesty of writing it down.
  6. Shape and seedLay the stream out in stages, ordered so the one that proves a risky assumption comes early, and seed the cards the near stages need — not every card the stream will ever hold. Each seeded card is a brief the Planning Loop plans when it is claimed.add_stage · create_card

The friction pass, before a stream earns its cards

A PRD that reads as finished is routinely one or two broken premises from sending a planning session down the wrong path, and a card seeded off a bad premise costs a whole plan to undo. So the loop guards itself against its own polish: in fresh context, it hunts the idea itself — is this worth building, now? — the assumption that would collapse the stream if it were false, the stage breakdown that hides a dependency, and the shape no plan could actually execute. It is the product-side counterpart of the Planning Loop’s adversarial pass, and, like it, it binds by being written down rather than by a status the server enforces: onMain ADR-141 is explicit that a PRD has no gate.

What a PRD carries

One document per stream, five fixed sections — Overview, Current state, Assumptions, Definition of Done, and Notes that accrue throughout. It carries the problem and the outcome, never the mechanism: no phases, no tasks, no number, no lease, no gate. It is the brief every one of the stream’s card plans reads, written human-first by a person through Claude or by hand, and it is never shown to a client.

Questions

Is a PRD a plan?

No. A PRD is product context — why to build something and what “built” would mean. It carries no phases and no tasks; a card’s plan carries those, written later when the card is claimed, with this PRD as its brief.

Who writes it, and does it gate a build?

A person does, through Claude over the MCP or by editing the sections by hand. It adds no new role and gates nothing: the friction pass that keeps it honest is a discipline the Standard writes down, not a status the server checks. Nothing in a PRD is ever shown to a client.

What is the friction pass for?

To break the premise before a card is seeded, which is the cheapest place to catch it — no plan has been written against it yet. It pushes back on the idea, the assumptions, the stages and the feasibility, the way the Planning Loop attacks a plan before anyone builds it.