Skeleton · PRD
Product Requirements Document
📋 Template · 🎯 v1 features · 2-page max · 8 sections
A PRD that engineers want to read. Two pages, eight sections, no waffling. Skip anything you can't fill in — that signals the work isn't yet done.
The skeleton
PRD: [Feature name]
Author: [Name] · Reviewers: [Eng lead / Design lead] · Date: [YYYY-MM-DD] · Status: Draft / In Review / Approved
Linear / Jira: [Epic link] · Figma: [Design link] · Slack: #channel-name
1 · WHY (1 paragraph)
What problem does this solve, for whom, with what evidence?
- Customer signal: [specific data — interviews, ticket count, retention drop, etc.]
- Business signal: [revenue lift / cost reduction / strategic moat]
- Why now: [what changed externally or internally to make this the priority]
2 · USER & STORY (3 user stories, max)
Primary user: [persona, role, context]
User story 1: As a [user], I want to [do X] so that [outcome].
User story 2: ...
User story 3: ...
3 · SUCCESS METRIC (one north-star)
Primary metric: [clear, measurable]
Target: [number or range]
Window: [time period to measure]
Counter-metric (what should NOT degrade): [retention / latency / NPS]
4 · IN SCOPE (bulleted list)
- [Functional requirement 1]
- [Functional requirement 2]
- [Functional requirement 3]
- [Non-functional: performance / a11y / security]
5 · OUT OF SCOPE (bulleted list)
- [Tempting feature we are explicitly NOT building in v1]
- [Edge case we won't handle until v1.1]
- [Integration we're deferring]
6 · DESIGN (link or embed)
- Figma flow: [link]
- Key screens: [list with one-line descriptions]
- Edge cases: [empty state, error state, loading state]
7 · ROLLOUT (3 phases)
- Phase 1 — Internal (week of [date]): [scope, who tests]
- Phase 2 — Beta (week of [date]): [user count, feedback channel]
- Phase 3 — GA (week of [date]): [launch comms, who owns]
Feature flag: [name]
Kill switch: [yes / no, where it lives]
8 · RISKS & OPEN QUESTIONS
- Risk 1: [description] · Mitigation: [...]
- Risk 2: [description] · Mitigation: [...]
- Open question 1: [needs decision before implementation]
- Open question 2: [needs decision before launch]
APPENDIX (optional)
- Customer interview notes
- Competitive teardown
- Earlier proposals that were rejected (and why)
The "what NOT" rule. A PRD without a Section 5 (out of scope) is a wishlist, not a spec. Forcing yourself to articulate what you're NOT building is the most useful step.
Sizing the PRD
- v1 features: 2 pages max. Anything longer means scope is too big.
- Bug fix: a 3-line ticket, not a PRD.
- New product line / surface: a longer doc with vision, scope, milestones — call it a "Product Brief" or "Initiative Doc", not a PRD.
Related skeletons