Craft
How to write a PRD teams actually read
A practical structure for product requirement docs that gets alignment in one review instead of five.
Start with the decision, not the feature
Most PRDs fail because they open with a solution. Engineers and designers then spend the first ten minutes reverse-engineering why the work matters. Open instead with the decision you need the reader to make and the evidence behind it.
One sentence is enough: the problem, who has it, how often, and what changes if you solve it.
The five sections worth keeping
Long templates get skimmed. These five sections carry almost all of the value in a product spec:
- Problem and evidence — what you observed, with numbers or quotes.
- Target outcome — the metric that should move, and by roughly how much.
- Scope — what is explicitly in, and what you are deliberately not doing.
- Open questions — the unknowns you want the review to resolve.
- Risks and rollout — what could break and how you will ship safely.
Write for the reviewer who has ninety seconds
Put the summary at the top, keep paragraphs to three lines, and link out to research rather than pasting it inline. If a reader can only skim the headings, they should still be able to challenge your reasoning.