PRD Writing

Parent: Writing and Documentation · researched 2026-05-29T19:03:48.361Z· 6 sources · 10 concepts · skill prd-writing

A Product Requirements Document (PRD) is a PM-owned artifact that defines what a product team will build and why, before engineering proposes how. PRDs sit upstream of RFCs, design docs, and implement

Overview

A Product Requirements Document (PRD) is a PM-owned artifact that defines what a product team will build and why, before engineering proposes how. PRDs sit upstream of RFCs, design docs, and implementation specs. [source]
A PRD captures validated decisions. It does not perform validation. Validation happens through customer interviews, prototypes, user testing, and data analysis - the PRD records the conclusions. [source]

1. Problem-first structure (Lenny's hierarchy)

A modern PRD opens with the problem, not the solution. Sections proceed in this order: [source]
Problem - what user/business pain are we solving, with evidence [source]
Users - who is affected, segment size, current workarounds [source]
Goals - desired outcomes and what success looks like [source]
Proposed solution - at a high level (often a prototype link) [source]
Success metrics - measurable definition of done [source]
Open questions / risks - what's unresolved [source]
Non-goals - what we are explicitly NOT doing [source]
Rollout / milestones - MVP → v1 → roadmap [source]

2. The Cagan four-section minimum

Marty Cagan's classic PRD structure: Purpose, Features, Release Criteria, Rough Timing. [source]

3. MVP vs v1 vs roadmap scoping discipline

MVP - minimum viable: smallest scope that lets us learn whether the proposed solution works. [source]
v1 (GA) - broadly shippable: meets release criteria, addresses the core user need. [source]
Roadmap (vNext) - follow-on work that the PRD acknowledges but does not commit to. [source]
Anti-pattern: Writing one undifferentiated feature list and labeling it "the PRD." Always tag each feature with its scope. [source]

4. Shape Up "pitch" as a fixed-appetite alternative

Basecamp's Shape Up framework replaces the PRD with a pitch: problem, appetite (2 or 6 weeks of fixed budget), solution sketch (fat marker, not Figma), rabbit holes (risks to bound), and no-gos (explicit exclusions). [source]
Key inversion: In Shape Up, scope is the variable; time is fixed. [source]

5. Non-goals as a first-class section

Engineers and reviewers consistently raise questions like "what about X?" A Non-Goals section answers these preemptively: [source]
> - Mobile app support - desktop only [source]
> - Bulk import - single-record only [source]
> - Real-time sync - daily batch acceptable [source]

6. Success metrics: leading vs lagging

Leading indicators - observable within 1–4 weeks (adoption %, feature engagement, task completion rate) [source]
Lagging indicators - observable in 1–2 quarters (retention, revenue, NPS, churn) [source]
Always include at least one leading indicator that the team can act on during the first month post-launch. [source]

7. PRD is not RFC, not spec, not plan

PRD (this skill) - PM-owned. WHAT to build, for WHOM, WHY now. [source]
RFC / Design doc - engineering-owned. HOW we propose to build it. [source]
Spec - engineering-owned. The contract. API shapes, behavior rules. [source]
Plan / Task list - engineering-owned. Sequenced units of work. [source]

8. The "designed-by-committee" failure mode

If a PRD accumulates feedback from N stakeholders and the author tries to honor every comment, the doc becomes incoherent. The PM is the author, not a scribe. [source]
Healthy pattern: collect feedback, summarize disagreements explicitly, make a call, and record the call with one-sentence rationale. [source]

Anti-Patterns

Solution-first opening - leading with "we will build X" before establishing why. [source]
Designed-by-committee text - incorporating every comment without making a call. [source]
PRD as discovery substitute - writing a 12-page PRD to "figure out" what users want. [source]
Spec-creep - PRD drifts into API shapes or schema choices. [source]
No non-goals - every reviewer asks "what about X?" [source]
Lagging-metric-only success - no signal during the launch window. [source]
Stale doc - PRD written once and never updated. [source]

References

Marty Cagan, "Revisiting the Product Spec," Silicon Valley Product Group [source]
Lenny Rachitsky, "Examples and templates of 1-Pagers and PRDs" - Lenny's Newsletter [source]
Ryan Singer, "Write the Pitch," Shape Up (Basecamp) [source]

Children

Problem-first structure (Lenny) (frontier)
Cagan four-section minimum (frontier)
MVP vs v1 vs roadmap scoping (frontier)
Shape Up pitch (Basecamp) (frontier)
Wireframes vs prose (frontier)
Leading vs lagging metrics (frontier)
Stakeholder sign-off pattern (frontier)
Non-goals as first-class section (frontier)
Designed-by-committee anti-pattern (frontier)

Frontier under this node: Cagan four-section minimum, Designed-by-committee anti-pattern, Leading vs lagging metrics, MVP vs v1 vs roadmap scoping, Non-goals as first-class section, Problem-first structure (Lenny), Shape Up pitch (Basecamp), Stakeholder sign-off pattern, Wireframes vs prose

← the whole tree · 3D view· how to read this page