PRD Template (With the Review Checks Built In)

A PRD template saves you from the worst first-draft failure: forgetting a whole section. That's the easy mistake, and it's the only one most templates protect against. They hand you empty headings and trust you to fill them well.

This one does more. Every section carries its review check beside it, the question a senior reviewer or an 11-pass critique would ask of that section. Answer the checks honestly and you've pre-empted most of the feedback that sends a spec back a sprint later.

Copy it, paste it into your doc tool, and write.

The PRD template (copy this)

# PRD: [Feature or product name]
Author · Date · Status (draft / in review / approved)

## 1. Problem
What's broken, for whom, and how we know it matters (data, tickets, interviews).
> Review check: Could a smart colleague disagree this is worth solving? If they
> can't even see the problem without the solution attached, reframe it.

## 2. Goal & success metrics
The one number that tells us this worked: a baseline, a target, and a date.
> Review check: Can this metric come out false in public? "Increase engagement"
> can't. If it can't fail, it isn't a metric yet.

## 3. Target users
Who this is for, grounded in a real behavior, and the job they're hiring it for.
> Review check: If you swapped this persona for another, would any requirement
> below change? If not, the persona is decoration. Cut or sharpen it.

## 4. Scope
In scope: …
Out of scope (explicitly, with the reason): …
> Review check: Is there an "out" list at all? Without one, every "could we
> also…" lands as a yes and the release drifts.

## 5. User stories & requirements
As a [user], I want [capability], so that [outcome].
Each requirement gets acceptance criteria a tester could run.
> Review check: Could QA verify each line as written? "Should be fast" can't be
> tested. "p95 under 500ms at 1k concurrent users" can.

## 6. Non-functional requirements
Performance, security, accessibility, plus the error, empty, and offline states.
> Review check: Is the unhappy path written down, or only the happy one? The
> week-one bugs live in the states you didn't spec.

## 7. Rollout & measurement
How it ships (flag, percentage, all at once), how we watch it, the rollback trigger.
> Review check: What specific number tells you to roll this back?

## 8. Open questions
What's unresolved, who owns it, and when you need the answer.
> Review check: A PRD with zero open questions isn't finished. It's hiding them.

How to fill it in

Work top to bottom, but expect to loop. The problem and the metric set up everything below them, so if you find yourself writing requirements that don't trace back to the goal, the goal is probably wrong, not the requirements.

Two sections do most of the damage when rushed. Section 5 is where vague language hides: write the acceptance criteria the way QA will test them, in the testable form covered here, and the ambiguity has nowhere to live. Section 6 is the one people skip entirely, and it's where estimates blow up. Walk the non-functional requirements checklist and write down the attributes that actually apply to your feature, not all of them.

One-pager or full PRD?

Match the template to the risk. A small feature on a well-understood surface fits on one page: trim each section to a line or two and keep the review checks. A new system, a billing change, or anything touching three teams needs the full version, because the cost of a missing edge case scales with how many people are building against the doc.

The sections don't change between the two. The depth does. Don't pad a one-pager to look thorough, and don't compress a risky initiative to look lean. Both fail the same way, by hiding a gap.

A template gets you a complete draft, not a good one

Here's the limit worth naming. A template protects you from the structural failure, the missing section. It does nothing about the judgment failures, and those are the expensive ones. You can fill all eight sections, leave no heading blank, and still ship a metric that can't fail, a requirement nobody can test, and an edge case you never imagined. The document looks done. It isn't.

That gap is exactly what a review is for, and it's why the review checks live inside this template instead of in a separate doc you'd never open. Run them on your own draft before anyone else does. The standing version is the PRD review checklist, the qualities you're aiming for are in what makes a good PRD, and the full walk-through of writing one this way is how to write a PRD.

If you'd rather not start from an empty template at all, PRD generation drafts the sections from your product context, and Critique runs the eleven checks on whatever you've got. Either way, the template is where the standard starts, not where it ends.

Frequently asked questions

What sections should a PRD template include?

The problem and who has it, the goal and success metrics, target users, scope (with what's explicitly out), requirements with testable acceptance criteria, non-functional requirements, a rollout plan, and open questions. Those eight cover what a reviewer checks for.

Is a one-page PRD enough?

For a small, well-understood feature, yes: a one-pager answers the same questions in less space. For a complex or cross-team initiative, you need room for requirements, edge cases, and dependencies. The sections stay the same; the depth scales with the risk of getting it wrong.

Is a PRD template enough to write a good PRD?

No. A template stops you forgetting a section, the easy failure. It can't catch the judgment failures: a metric that can't fail, an untestable requirement, an edge case left blank. Those survive a template and only get caught in review.

Should I use a PRD template or write from scratch?

Use a template. It saves you from forgetting a section and gives a newer PM a scaffold to think against. A blank page mostly produces an inconsistent, gap-prone doc. The template is the floor, not the ceiling.

Copy it, then attack it

Paste the template, fill the eight sections, then read it back as if you were the engineer who has to build it and the stakeholder who has to fund it. The checks are already in the margin. The only question left is whether you answered them honestly.