PRD Writing
Parent: Writing and Documentation · Published reference · snapshot 2026-09-08 · skill technical-writing-craft/references/prd-writing.md
↓ Facts as markdownall context files
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
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#overview]
- 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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#overview]
1. Problem-first structure (Lenny's hierarchy)
- A modern PRD opens with the problem, not the solution. Sections proceed in this order: [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Problem - what user/business pain are we solving, with evidence [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Users - who is affected, segment size, current workarounds [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Goals - desired outcomes and what success looks like [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Proposed solution - at a high level (often a prototype link) [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Success metrics - measurable definition of done [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Open questions / risks - what's unresolved [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Non-goals - what we are explicitly NOT doing [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
- Rollout / milestones - MVP → v1 → roadmap [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#1-problem-first-structure-lennys-hierarchy]
2. The Cagan four-section minimum
- Marty Cagan's classic PRD structure: Purpose, Features, Release Criteria, Rough Timing. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#2-the-cagan-four-section-minimum]
3. MVP vs v1 vs roadmap scoping discipline
- MVP - minimum viable: smallest scope that lets us learn whether the proposed solution works. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#3-mvp-vs-v1-vs-roadmap-scoping-discipline]
- v1 (GA) - broadly shippable: meets release criteria, addresses the core user need. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#3-mvp-vs-v1-vs-roadmap-scoping-discipline]
- Roadmap (vNext) - follow-on work that the PRD acknowledges but does not commit to. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#3-mvp-vs-v1-vs-roadmap-scoping-discipline]
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). [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#4-shape-up-pitch-as-a-fixed-appetite-alternative]
- Key inversion: In Shape Up, scope is the variable; time is fixed. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#4-shape-up-pitch-as-a-fixed-appetite-alternative]
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: [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#5-non-goals-as-a-first-class-section]
- > Non-goals (v1): > - Mobile app support - desktop only > - Bulk import - single-record only > - Real-time sync - daily batch acceptable [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#5-non-goals-as-a-first-class-section]
6. Success metrics: leading vs lagging
- Leading indicators - observable within 1–4 weeks (adoption %, feature engagement, task completion rate) [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#6-success-metrics-leading-vs-lagging]
- Lagging indicators - observable in 1–2 quarters (retention, revenue, NPS, churn) [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#6-success-metrics-leading-vs-lagging]
7. PRD is not RFC, not spec, not plan
- PRD (this skill) - PM-owned. WHAT to build, for WHOM, WHY now. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#7-prd-is-not-rfc-not-spec-not-plan]
- RFC / Design doc - engineering-owned. HOW we propose to build it. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#7-prd-is-not-rfc-not-spec-not-plan]
- Spec - engineering-owned. The contract. API shapes, behavior rules. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#7-prd-is-not-rfc-not-spec-not-plan]
- Plan / Task list - engineering-owned. Sequenced units of work. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#7-prd-is-not-rfc-not-spec-not-plan]
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. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#8-the-designed-by-committee-failure-mode]
- Healthy pattern: collect feedback, summarize disagreements explicitly, make a call, and record the call with one-sentence rationale. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#8-the-designed-by-committee-failure-mode]
Anti-Patterns
- Solution-first opening - leading with "we will build X" before establishing why. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- Designed-by-committee text - incorporating every comment without making a call. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- PRD as discovery substitute - writing a 12-page PRD to "figure out" what users want. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- Spec-creep - PRD drifts into API shapes or schema choices. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- No non-goals - every reviewer asks "what about X?" [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- Lagging-metric-only success - no signal during the launch window. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
- Stale doc - PRD written once and never updated. [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#anti-patterns]
References
- Marty Cagan, "Revisiting the Product Spec," Silicon Valley Product Group [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#references]
- Lenny Rachitsky, "Examples and templates of 1-Pagers and PRDs" - Lenny's Newsletter [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#references]
- Ryan Singer, "Write the Pitch," Shape Up (Basecamp) [archived source: https://llms-explorer.com/sources/mdb-context-hub/prd-writing/#references]
Where this helps
- Writing the artifact that hands off from product discovery (interviews, prototypes, data) into engineering planning, when the team needs a single document that captures WHAT and WHY before HOW. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Deciding how to scope a feature into MVP, v1, and roadmap tiers so engineering isn't asked to build an undifferentiated feature list. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Choosing between a traditional PRD and a Shape Up-style pitch when a team's constraint is fixed engineering capacity rather than fixed scope. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Resolving a PRD review cycle where every stakeholder's comment is getting incorporated verbatim and the document is losing coherence. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
How to apply this
- Open with the problem and evidence for it before describing any proposed solution, and treat the PRD as recording validated decisions rather than performing the validation itself. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Tag every feature explicitly with its scope tier (MVP, v1, roadmap) instead of writing one undifferentiated list, so engineering knows what's committed versus acknowledged. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Write an explicit Non-Goals section addressing the "what about X?" questions reviewers will otherwise raise individually and repeatedly. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Include at least one leading indicator alongside lagging metrics, so the team has a signal to act on within the first month post-launch instead of waiting a quarter or two for lagging data. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Common mistakes
- Leading with the solution ("we will build X") before establishing the problem and evidence for it. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Letting the document become designed-by-committee — incorporating every stakeholder comment without the PM making and recording an explicit call. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Using a lengthy PRD as a substitute for discovery, trying to "figure out" what users want inside the document instead of through interviews and testing beforehand. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Letting the PRD drift into spec-creep — specifying API shapes or schema choices that belong in engineering-owned RFCs and specs, not the PM-owned PRD. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Known issues
- A PRD is only as good as the validation that preceded it; a well-structured PRD built on unvalidated assumptions still produces the wrong product, just with clearer documentation of the wrong call. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- The MVP/v1/roadmap scoping discipline requires ongoing enforcement — a PRD written cleanly at the start can still accumulate an undifferentiated feature list as stakeholders add requests during review. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- PRDs written once and never updated go stale as scope and learnings evolve during implementation, undermining their value as the canonical WHAT/WHY reference. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- The PRD/RFC/spec/plan boundary depends on organizational discipline to hold; without it, PMs and engineers end up duplicating or contradicting decisions across documents that were supposed to have distinct scopes. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
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