PRD Structure
The canonical sections every Product Requirements Document should contain.
Why
A PRD is the contract between what product wants and what engineering builds. Without a shared structure, every PM invents their own sections, and engineers spend the first hour of every review figuring out where the acceptance criteria are hiding. A fixed structure — problem, users, requirements, success metrics, out-of-scope — means a reader can scan any PRD in 5 minutes and know what's being built and why. The structure also forces the PM to answer the hard questions (what's NOT in scope?) before engineering starts.
When
Before any engineering work on a feature ≥1 sprint. Takes 2-4 hours to write well. Skip for bug fixes and trivial tweaks.
How
1. Problem statement — 2-3 sentences: who suffers, how, and what's the cost of not solving 2. Target users — which segment, with a one-line persona reference 3. Requirements — numbered list, each with a clear "done looks like" 4. Success metrics — how we'll measure this worked (e.g. "signup conversion +2pp") 5. Out of scope — explicitly list what we're NOT building (this section is the most valuable) 6. Open questions — unresolved items that need a decision before build 7. Timeline — target dates for design freeze, build complete, launch 8. Review with eng + design + QA leads; capture sign-off in the doc
Example
# PRD: One-click release notes from git commits ## Problem Release managers spend 2h/release hand-writing notes from commit logs, and 30% of releases ship notes that omit a security fix. ## Target users Platform engineers at teams of 10-100 using GitHub + conventional commits. ## Requirements 1. Given a tag range, generate a markdown summary grouped by commit type - Done = output matches the team's existing template for 95% of releases 2. Auto-detect security-related commits and flag them in a "Security" section ## Success metrics - Time-to-generate < 30s for a 200-commit range - 80% of teams adopt within 1 month of rollout ## Out of scope - Multi-repo release notes (v2) - Slack integration (v2) ## Open questions - Should we support gitlab? (decision needed by 03-20)
Common Problems
- ⚠Skipping the Out-of-scope section — without it, scope creep is inevitable because every stakeholder assumes their ask is included.
- ⚠Writing requirements as capabilities ('the system shall...') instead of testable behaviors — engineers can't estimate what they can't test.
Best Practices
- ✓Keep the PRD to 2 pages — if it's longer, the feature is too big and should be split into multiple PRDs.
- ✓Link the PRD to the validated idea doc and the ADRs it depends on, so the full chain from idea → decision → spec is traceable.
- ✓Date and version every PRD; when scope changes mid-build, create a new version rather than silently editing.