PRD Writing

PRD Writing

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.

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.

Core Concepts

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

A modern PRD opens with the problem, not the solution. Sections proceed in this order:

1. Problem — what user/business pain are we solving, with evidence
2. Users — who is affected, segment size, current workarounds
3. Goals — desired outcomes and what success looks like
4. Proposed solution — at a high level (often a prototype link)
5. Success metrics — measurable definition of done
6. Open questions / risks — what’s unresolved
7. Non-goals — what we are explicitly NOT doing
8. Rollout / milestones — MVP → v1 → roadmap

2. The Cagan four-section minimum

Marty Cagan’s classic PRD structure: Purpose, Features, Release Criteria, Rough Timing.

3. MVP vs v1 vs roadmap scoping discipline

• MVP — minimum viable: smallest scope that lets us learn whether the proposed solution works.
• v1 (GA) — broadly shippable: meets release criteria, addresses the core user need.
• Roadmap (vNext) — follow-on work that the PRD acknowledges but does not commit to.

Anti-pattern: Writing one undifferentiated feature list and labeling it “the PRD.” Always tag each feature with its scope.

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).

Key inversion: In Shape Up, scope is the variable; time is fixed.

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:

Non-goals (v1):

• Mobile app support — desktop only
• Bulk import — single-record only
• Real-time sync — daily batch acceptable

6. Success metrics: leading vs lagging

• Leading indicators — observable within 1–4 weeks (adoption %, feature engagement, task completion rate)
• Lagging indicators — observable in 1–2 quarters (retention, revenue, NPS, churn)

Always include at least one leading indicator that the team can act on during the first month post-launch.

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

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

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.

Healthy pattern: collect feedback, summarize disagreements explicitly, make a call, and record the call with one-sentence rationale.

Templates

Modern PRD skeleton (Cagan + Lenny hybrid)

# [Feature Name] — PRD

**Owner:** [PM name] · **Status:** Draft / In Review / Approved
**Last updated:** YYYY-MM-DD · **Target ship:** Quarter/Year

## TL;DR (3 sentences max)
[One sentence: the problem. One: the solution. One: the metric of success.]

## Problem
[User pain or business gap, with evidence: support volume, NPS verbatims,
analytics, sales-loss reasons.]

## Users
- Primary segment: [who, how many, current workaround]
- Secondary segment: [who, how many]
- Out of scope: [explicit segments NOT served by v1]

## Goals
## Non-goals (v1)
## Proposed solution
## Behavior (prose section, for non-UI logic)
## Success metrics
## Rollout

## Release criteria (Cagan)
- Performance: [SLO]
- Accessibility: [WCAG level]
- Security: [review completed]

## Risks and open questions
## Decisions log
## Sign-off
- [ ] Product (name, date)
- [ ] Engineering (name, date)
- [ ] Design (name, date)

Shape Up pitch skeleton

# Pitch: [Feature]

## Problem
## Appetite
[Small batch (2 weeks) | Big batch (6 weeks)]

## Solution
[Fat-marker sketch. Not high-fidelity.]

## Rabbit holes
## No-gos

Anti-Patterns

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

References

1. Marty Cagan, “Revisiting the Product Spec,” Silicon Valley Product Group
2. Lenny Rachitsky, “Examples and templates of 1-Pagers and PRDs” — Lenny’s Newsletter
3. Ryan Singer, “Write the Pitch,” Shape Up (Basecamp)