How to write a PRD that gets built

What separates a PRD that gets built from one that gets filed?

A PRD gets built when a named person can approve its scope in one sitting and an engineer can start on requirement one without booking a follow-up meeting. Everything else is formatting. The PRD template gives you eight sections and a worked example line for each; this page covers the decisions you make before any of those sections are worth filling in, and the order those decisions have to arrive in.

The failure pattern is consistent enough to predict. A draft comes back with comments on the requirements section, the PM rewrites the requirements, the draft comes back again, and three rounds later the real objection finally surfaces: nobody ever agreed the problem was worth solving. Requirements are the cheapest part of a PRD to argue about and the most expensive part to rewrite, which is exactly why they are the wrong place to start.

What order do you actually make the decisions in?

Four passes, and you do not start one until the pass before it holds.

Pass one, evidence. Write down what you know about the problem and how you know it. A ticket count from a query you can re-run. A drop-off percentage from a funnel someone else can open. A sentence a real customer said, quoted rather than paraphrased. If every line traces back to a conversation in a meeting instead of to a number or a quote, stop writing and go get one.

Pass two, scope. Decide what is in and what is out, and write the out list first. A non-goals section written after the requirements is a tidy-up of choices you already made by accident. Written before them, it is the decision itself. This is the pass the approver signs, and the only pass where changing your mind costs nothing.

Pass three, requirements. Now write what the thing has to do, as outcomes someone can build toward. Number them, because in two weeks an engineer will need to say "requirement four is not buildable in this sprint" and you want that sentence to be possible to say precisely.

Pass four, the cut line. State what ships and what gets deferred if the estimate comes back bigger than the calendar allows. A PRD with no pre-agreed cut line hands that call to whoever is under the most pressure in the final week, which is the worst available moment and the worst available decision maker.

How specific does the problem statement have to be?

Specific enough that a reasonable colleague could disagree with it using a different number.

"Onboarding is confusing" cannot be disagreed with, so it cannot be agreed with either. It gets nodded at. A statement in the shape of "roughly two in five trial accounts never reach the second setup step, and the median gap between step one and abandonment is under ten minutes" can be challenged on the segment, the date range, or what counts as abandonment. Every one of those challenges is useful, and every one of them arrives before anyone has written code.

The number does not have to be perfect. It has to be checkable. A funnel figure will not tell you why people stop, and it will not prove that fixing the step changes the outcome. It still tells you where to point the interview, and pointing the interview is the whole job of the evidence pass.

What does a requirement look like when it is written as an outcome?

The GOV.UK Service Manual makes the distinction plainly for user stories: describe the need, not the solution you have in mind for it. The same discipline decides whether a PRD requirement is useful. "A user reaches their current invoice from the dashboard in one action" states a result anyone can verify. "Add an Invoice button to the top navigation" states an interface decision, which removes the option of a better answer before the people best placed to find one have read the ticket.

There is a real limit to that rule. Some requirements genuinely are interface decisions, because the interface is the product decision: a legally required consent screen, a confirmation step before a destructive action, a specific accessibility behaviour. Write those as the constraint they are, and say why the constraint exists, so nobody spends a sprint negotiating with a rule that was never negotiable.

When is a PRD the wrong document?

Three situations, and all three are common.

• The problem is not validated yet. Run a discovery interview first, because a detailed PRD built on an unvalidated assumption is a well organised guess.
• Nobody has agreed to fund the work. A one-pager is built to get a decision; a PRD is built to scope one that has already been made.
• The work spans several quarters and many features. That question belongs on a product roadmap, and compressing it into a PRD produces a document too long to read and too vague to build from.

What does the review conversation actually test?

Not whether the document is complete. Whether the author can defend it under pressure without either caving or digging in.

Give reviewers something specific enough to attack. When an engineer says the second-largest requirement carries a dependency you did not know about, the PRD worked. When a sceptical reader says the churn you are solving is concentrated in a segment you are not targeting, the PRD worked. A draft that produces only spelling corrections and a thumbs-up has usually failed at being specific, not succeeded at being right.

Three readers earn their time: an engineer who will build it, a designer who will shape it, and one person who doubts the problem exists. Most teams get the first two and skip the third, then meet the third reader's objection a month later in the form of a shipped feature nobody uses.

What a PRD cannot fix

A PRD cannot decide strategy. If the underlying question is which bet the team should be making at all, the document will keep collecting stakeholder requests and calling the pile a scope, because there is no criterion inside it for saying no. That is a Product Strategy problem, not a documentation problem, and writing a better PRD on top of an undecided strategy just produces a more legible version of the same confusion.

It also cannot substitute for an owner. A named decision maker who can say the scope is final, even if that person is you, is what turns a living document everyone edits mid-build into a plan. Without one, scope creep is not a risk; it is the default.

Where this fits in the wider product process

Writing the document is the visible part of a loop that starts with finding a problem worth solving and ends with reading the metric after launch. Builders Camp's Product Manager Foundations bootcamp runs that whole loop across 2 weeks and 4 live sessions, from problem discovery and opportunity sizing through prioritisation, roadmapping, and post-launch measurement, with the same artefacts you would produce at work. Its practical challenge asks you to take one real problem from a blank page to a problem statement, a research summary, a PRD, a metrics framework, and a growth plan, which is the sequence this page describes, run end to end on something you care about.

If your bottleneck is the strategy sitting above the document rather than the document itself, Product Strategy covers choosing where to compete and sequencing bets you can defend. If you are earlier than that and want the ordered path rather than a single bootcamp, the Product Management Starter Track bundles the foundations, discovery, and communication skills in sequence.

See the Product Manager Foundations bootcamp

One last thing worth stealing from teams who do this well: keep the rejected scope. A short list of what you decided not to build, and why, saves the next PM from re-litigating a decision you already made with evidence they no longer have.