How to Write a PRD
A step-by-step approach to specs that align teams without over-specifying.
Start with the problem, not the feature list. A PRD should make a stranger understand why this work matters now — and what "done" looks like.
PRD structure that scales
- 1
Problem & opportunity
Who is affected, what pain exists, and why now. One paragraph max.
- 2
Goals & non-goals
Explicit scope boundaries prevent scope creep. "Non-goals" are as important as goals.
- 3
Success metrics
How you will know this worked. Prefer outcomes over output.
- 4
User scenarios
A few concrete flows — not every edge case. Enough for design and eng to empathize.
- 5
Requirements
Functional needs at the right altitude. Link to designs and technical notes separately.
- 6
Open questions & decisions
What is still unknown? What is already decided? Link both.
Before sharing with engineering
- ✓ Problem statement does not mention solution yet
- ✓ At least one metric or acceptance signal is defined
- ✓ Non-goals are listed
- ✓ Linked decisions are current, not contradicted in the spec
- ✓ Open questions have owners