How to Write a PRD (That Survives Review)

Most guides on how to write a PRD hand you a list of sections and call it finished. Problem, goals, user stories, requirements, metrics. Fill the boxes, ship the doc.

That gets you a document. It doesn't get you a good one.

Here's the part nobody teaches: the test of a PRD isn't whether it's written. It's whether it survives review. Whether a senior PM or a lead engineer can read it cold and not find the gap that sends it back a sprint later. Most of us learned to write specs. Almost none of us were taught to red-team one, so the first real review of your draft is usually someone else's, in a meeting, when it's already too late to be cheap.

So this guide does two jobs at once. It walks the sections and the steps. And next to each one, it names the check that section has to pass before a reviewer catches what you left out. Write for the review, and the review stops being the thing that blocks you.

If you want the plain definition first: a PRD is the document that says what you're building, who it's for, and why, before anyone writes the code. Otherwise, let's write one.

How to write a PRD, step by step

To write a PRD, work in this order: frame the problem and who has it, set one measurable goal, draw the scope line and name what's out, write user stories with testable acceptance criteria, cover the non-functional requirements and edge cases, then plan the rollout and the metrics. Review each section against the question a reviewer would ask before it reaches engineering.

Seven steps. Each one is a section of the finished doc, and each one has a failure mode a reviewer will catch if you skip it.

1. Frame the problem, not the feature

Open with the problem and the person who has it, not the solution you already fell for. "Users can't reset their password without emailing support" is a problem. "Add a password-reset flow" is a solution wearing a problem's clothes.

What goes wrong: you describe the feature so well that nobody notices you never proved the problem was worth solving. The reviewer's first question is "who asked for this, and how do you know?" If the honest answer is "a VP mentioned it once," say so, because that changes how much the team should bet on it. Cite the support tickets, the churn interview, the number. Thin problem framing is the single most common reason a PRD reads clean and still gets bounced.

2. Set one goal you can measure

Pick a goal that can fail. A real metric has a number and a date attached: "cut password-reset support tickets 40% within one quarter of launch." If the goal can't come out false, it isn't a goal.

What goes wrong: success criteria that read like a mood. "Improve engagement." "Delight users." "Drive adoption." A reviewer reads those and knows the launch has no scoreboard, which means nobody will be able to tell six weeks later whether the thing worked. One sharp metric beats four soft ones.

3. Map the users and the journey

Name who this is for and walk their actual path, step by step, to the moment the product helps. Where does the journey start today? Where does it break? Ground the persona in a real behavior, not a demographic.

What goes wrong: the cardboard persona. "Sarah, 32, a busy professional who values efficiency." No decision in the whole document depends on Sarah existing. A reviewer spots that instantly, because a persona that changes nothing is decoration. If swapping the persona out wouldn't change a single requirement, you haven't mapped a user. You've filled a slot.

4. Draw the scope line, and the cut list

Two lists. What's in, and what's explicitly out for this release. Then go one further and rank the in-scope items by what you'd cut first if the date moved up two weeks, which is the honest version of MoSCoW prioritization.

What goes wrong: no "out of scope" section, so scope creep has nothing to push against. Every "could we also..." in the next standup lands as a yes, because the document never said no to anything. The out-of-scope list isn't where you admit weakness. It's where you protect the launch.

5. Write requirements with testable acceptance criteria

For each requirement, write how QA would prove it's done. "The user can reset their password" becomes a set of conditions someone can check off: valid email sends a link within 60 seconds, expired links show a specific error, the same flow works on mobile web. If you can't test it, you can't ship it with confidence. More on this in testable acceptance criteria.

What goes wrong: "the system should be fast." Fast how, measured where, for whom? Untestable acceptance criteria are the requirements that feel done on the page and fall apart the moment an engineer asks "what exactly am I building?" A reviewer reads "should be intuitive" and circles it, every time.

6. Cover the non-functional requirements and the edge cases

The happy path is the easy 80%. The review lives in the other 20%: performance budgets, security, accessibility, the empty state, the error state, what happens offline, what happens when the API the feature depends on is down. Walk the non-functional requirements checklist and write down the ones that apply.

What goes wrong: a PRD where the main flow is airtight and the edge cases are simply absent. Not wrong. Absent. The reviewer who has shipped before knows the edge cases are where the launch actually bleeds, so a doc that never mentions them reads as half-finished no matter how polished the happy path looks.

7. Plan the rollout, the metrics, and the open questions

How does this reach users: all at once, behind a flag, to 5% first? How will you watch it after launch, and what number tells you to roll back? Then add the section most people delete: a visible list of open questions you haven't resolved yet.

What goes wrong: pretending you have no unknowns. A PRD with zero open questions isn't finished, it's hiding. Every reviewer has been burned by the confident-sounding spec that quietly buried its biggest risk, so a visible "open questions" list reads as a strength, not a gap. It tells the room you know where the document is thin.

Write it so it survives review

This is the part the other guides skip, and it's the whole point.

A PRD review has one job most people get backwards. It's supposed to hunt for what's missing, not polish what's already there. Proofreading finds the typo in the sentence you wrote. A review finds the acceptance criterion you never wrote, the edge case nobody mapped, the metric that can't fail. You can't proofread a gap. The only way to catch one reliably is to read the draft against a fixed list of things a good PRD must answer, the same list every time.

So before you hand the doc to anyone, run that read yourself. The standing version you can work through by hand is the PRD review checklist, and the habit of doing it on your own drafts is how to critique your own PRD.

There's an AI angle here, and by default it cuts the wrong way. Ask a general assistant to "review my PRD" and it'll mostly agree with you. Helpful defaults to agreeable: you get twenty suggestions of equal weight, no position on which one sinks the launch, no severity. That reads like a review and isn't one, because a review takes a position and ranks the damage. That's the reason Thinkr's Critique runs eleven named passes instead of a single freeform read, returns each finding as a blocker, major, or minor, and lands a suggested rewrite on the line it concerns. Whether you use a tool or a colleague, the standard is the same: did anything get checked that you can name, or did a friendly paragraph just tell you it looked good?

The mistakes that send a PRD back

Most rejected PRDs fail the same handful of ways: a problem nobody validated, a metric that can't fail, a generic persona, requirements you can't test, and edge cases left blank. If you've ever watched a spec read smooth in the doc and still let a blocker through to the launch meeting, it was almost certainly one of these. The longer version, with the check that catches each, is in common PRD mistakes.

When the blank page is the blocker

If structure is what you're missing, a template gives you the sections with the review check built into each, so the gaps are harder to leave in. If the writing itself is the wall, generate a first draft from your own product context with PRD generation, then run the seven checks above on what it gives you. A generated draft is a starting point, not a finished spec. The review is still yours.

Frequently asked questions

What sections should a PRD include?

The problem and who has it, a measurable goal, target users and their journey, scope (with what is explicitly out), requirements with testable acceptance criteria, non-functional requirements and edge cases, and a rollout plan with success metrics. Lean teams compress this to a one-pager; the sections stay, the word count drops.

How long should a PRD be?

As short as it can be while still answering every question a reviewer would ask. A small feature fits on a page; a complex initiative might run several. A two-page PRD that survives review beats a ten-page one that hides its gaps in volume.

What is the difference between a PRD and a BRD?

A BRD states what the business wants and why, in business terms. A PRD translates that into what the product must do for users: features, flows, requirements, and acceptance criteria. The BRD sets the objective; the PRD defines the product that meets it. Plenty of teams now fold both into one lean document.

How do you know when a PRD is finished?

When it survives review. Not when every section is filled, but when a senior PM or an engineer can read it and not find a gap that blocks the build: no vague metric, no missing edge case, no untestable requirement. If you can't run that review with a colleague yet, run it against a checklist first.

The one-line version

Write the sections, then attack them. A PRD is finished when someone who wants to find a hole in it can't. Get there on your own draft, in private, and the review meeting turns from the place your spec gets sent back into the place it gets approved.