What to include in a PRD — and what to leave out

Ask ten PMs what goes in a PRD and you'll get ten section lists. The more useful question is the boundary: what belongs, and what quietly creeps in that shouldn't.

What belongs

• The problem and who has it — the anchor for every other decision.
• Goals and success metrics — specific, measurable targets.
• Functional requirements — what the system must do, ideally as user stories with acceptance criteria.
• Non-functional requirements that matter to the user — performance, reliability, accessibility expectations.
• Scope — what's in, and explicitly what's out.
• Risks and open questions — named, not hidden.

What doesn't belong

The thing that creeps in and shouldn't: implementation. Database schemas, API designs, framework choices, architecture diagrams — these are solution design, and they belong in the technical spec written from the PRD, not in the PRD itself.

There are two reasons to hold this line. First, it over-constrains engineering: when a PM specifies how, they pre-empt the people best placed to decide it, often suboptimally. Second, it ages badly — the "what" (users still need to reset passwords) stays true far longer than the "how" (which service, which library), so a PRD stuffed with implementation goes stale fast.

The test

When you're unsure whether a line belongs, ask: does this describe what the user needs or how we'll build it? "Resets must expire after 60 minutes" is a requirement (a what — it's a user-facing security property). "Store the token in Redis with a TTL" is implementation (a how). The first belongs in the PRD; the second belongs in the spec.

Keeping the boundary clean is also what makes the PRD→spec handoff work: the spec's job is to answer the hows that the PRD deliberately left open.