Most PRDs suck.
They're either 15 pages of detail that nobody reads, or they're so vague that engineering has to guess what you actually want. Both fail at the fundamental purpose of a PRD: creating alignment so the team can build the right thing.
I've written both kinds. The 15-pagers that were obsolete by the time I finished writing them. The one-pagers that raised more questions than they answered. Eventually, I figured out what actually works.
The Purpose of a PRD
Before talking about format, let's clarify why PRDs exist:
Alignment: Everyone agrees on what we're building and why. Communication: Stakeholders can understand the plan without a meeting. Reference: Engineers and designers have a source of truth to consult. Clarity: Writing forces you to think through the details.
A PRD is not:
- •A legal contract
- •Documentation for posterity
- •Proof that you did your job
- •A creative writing exercise
The best PRD is the shortest document that achieves alignment. Everything beyond that is waste.
The Core Structure
Every PRD needs to answer five questions:
1. What problem are we solving?
The most important section. If this isn't clear, nothing else matters.
Describe the user problem. Who has this problem? How painful is it? What are they doing today?
Include evidence: user research quotes, data showing the problem, support ticket themes. Make the problem real and undeniable.
Bad: "Users have trouble with onboarding." Good: "32% of new users drop off before completing account setup. In user interviews, the most common complaint is confusion about which fields are required vs. optional. This is costing us an estimated $400K annually in lost conversions."
2. Why does this matter?
Connect the problem to business goals. Why should the company invest resources in solving this?
- •Revenue impact
- •User retention
- •Competitive positioning
- •Strategic priority alignment
If you can't articulate why this matters, reconsider whether you should be building it.
3. What are we building?
Now—and only now—describe the solution.
Be specific enough that engineering knows what to build, but don't over-specify implementation details. Focus on:
- •User flows
- •Key screens or interactions
- •Core functionality
- •Edge cases that matter
Use visuals. A wireframe or mockup communicates more than paragraphs of text.
4. What are we NOT building?
Explicit non-goals prevent scope creep and clarify boundaries.
"This project will NOT address:
- •Admin user experience (future project)
- •Mobile app (web only for V1)
- •Integration with external tools"
Non-goals are as clarifying as goals.
5. How will we know it worked?
Define success metrics before you ship. What will you measure? What constitutes success?
- •Primary metric: The main thing you're trying to move
- •Secondary metrics: Other positive outcomes
- •Guardrail metrics: Things that shouldn't get worse
Include targets when possible: "Success = onboarding completion rate increases from 68% to 80%."
What NOT to Include
Less is more. Cut aggressively:
Don't include: Obvious context everyone already knows. If you're building for your own product, you don't need to explain what the product does.
Don't include: Implementation details unless they're requirements. Let engineering decide how to build it unless there's a specific constraint.
Don't include: Historical analysis of past decisions. Focus on the future.
Don't include: Every possible edge case. Cover the important ones. Defer the rest to implementation.
Don't include: Lengthy competitive analysis. A brief section is fine; a 5-page competitive teardown belongs elsewhere.
Ideal Length
For a typical feature: 1-3 pages. Maybe 5 for something complex.
If you're past 5 pages, ask yourself:
- •Am I over-specifying implementation?
- •Do I have unnecessary context?
- •Should this be multiple smaller projects?
Long PRDs signal unclear thinking. The document becomes longer because you haven't clarified what's essential.
Format Tips That Help
Use headers liberally. People skim. Make it easy to find information.
Lead with the bottom line. Put your recommendation or decision at the top. Details come after.
Include a TL;DR. A 3-5 sentence summary at the very top. "We're building X to solve Y. Success looks like Z."
Visuals > text. A flow diagram or wireframe communicates faster than paragraphs.
Tables for requirements. If you have multiple requirements, put them in a table with columns for requirement, priority, notes.
Link, don't copy. Reference other documents rather than duplicating their content.
Getting Feedback
A PRD isn't finished when you've written it. It's finished when the team is aligned.
Share early drafts. Don't wait until it's "done." Get feedback while you can still incorporate it easily.
Ask specific questions. "What's unclear?" generates better feedback than "thoughts?"
Review with engineering and design together. This catches the 80% of issues that come from one discipline not understanding another's constraints.
Track open questions. If something's unresolved, make it visible rather than hiding it.
Living Document vs. Snapshot
Two approaches:
Living document: The PRD evolves as you learn more. Always reflects current thinking. Good for longer projects.
Snapshot: The PRD captures decisions at a point in time. Changes happen in new documents or tickets. Good for handoffs and reference.
Most teams use a hybrid. The PRD is living during active development, then becomes a snapshot for posterity.
Whatever you choose, be clear about which approach you're using. Nothing's worse than outdated docs that look current.
Common Mistakes
Starting with the solution. If your PRD begins "We're going to build a dashboard that..." you skipped the problem. Why a dashboard? Says who?
Specifying the how. "The button should be blue and positioned in the upper right" is a design decision, not a product requirement. Describe the outcome you need; let designers design.
Trying to cover everything. Perfection is the enemy of shipped PRDs. Get to 80% and iterate.
Writing for the wrong audience. A PRD for engineers looks different than one for executives. Know who needs to understand it and write for them.
No success metrics. Without defined success, you can't tell if you succeeded. And you'll definitely argue about it later.
A Quick Template
# [Feature Name] PRD
## TL;DR
[3-5 sentence summary: what, why, success criteria]
## Problem
[What problem are we solving? For whom? Evidence?]
## Goals & Success Metrics
[What does success look like? Primary metric, target]
## Non-Goals
[What are we explicitly NOT doing?]
## Solution
[What are we building? Include visuals]
## Key Flows
[User journey through the feature]
## Open Questions
[What's still unresolved?]
## Timeline & Dependencies
[When? Blocked on what?]
Customize as needed, but keep the core elements.
The Meta-Point
The best PRD is one that makes the meeting unnecessary. Someone should be able to read it, understand what we're doing and why, and start working—without needing you to explain.
If your PRDs require a walkthrough meeting to be understood, they're not doing their job.
Write for clarity. Cut ruthlessly. Get alignment, not applause.
Related reading: PM Communication Skills and Stakeholder Management.