The PRD — Product Requirements Document — is the document PMs are most known for, and the one beginners get most wrong. Not because it’s hard, but because nobody shows them a real one. Let’s write one together.
What a PRD is (and isn’t)
A PRD answers three questions in writing: what problem are we solving, for whom, and how will we know it worked? It is not a technical spec, not a design file, and not a novel. Most good PRDs are 1–3 pages.
The example
Imagine you’re the PM for a food-delivery app. Support tickets show customers keep missing deliveries. Let’s write the PRD for a fix.
Section 1: Problem statement
Customers who don’t hear the doorbell miss 8% of deliveries. Each missed delivery costs a refund (average $22), a support ticket, and often the customer: 30% of users with a missed delivery churn within a month.
Notice: who hurts, how often, what it costs. Numbers make it real — estimates beat adjectives. No solution yet.
Section 2: Goal and success metric
Reduce missed deliveries from 8% to under 4% within two months of launch. Guardrail: driver wait time must not increase.
One primary metric, one guardrail. If you can’t measure your goal, rewrite it until you can.
Section 3: Non-goals
Not in scope: rescheduling deliveries, in-app driver chat, changes to the refund policy.
This section is your scope-creep vaccine. Everything someone will “just quickly ask” to add — name it now, exclude it deliberately.
Section 4: Requirements
- Must: When the driver marks “arrived,” the customer gets a full-screen notification with sound
- Must: Customer can tap one button to tell the driver “coming down in 2 minutes”
- Should: If no response in 3 minutes, an automated voice call goes out
- Could: Customer can pre-set delivery instructions (“gate code is 4412”)
Must / Should / Could forces the prioritization conversation before the build, not during it.
Section 5: Open questions
Every open question gets an owner and a date — “Can we override silent mode on iOS? (Eng lead, by Friday)” — or it becomes a launch delay in disguise.
The mistakes every first PRD makes
- Solution first, problem later — if your problem statement mentions your feature, rewrite it
- No numbers — “users are frustrated” is an opinion; “8% of deliveries fail” is a problem
- Everything is a Must — then nothing is; force-rank or your team will rank for you, badly
- Written alone — a PRD nobody reviewed is a wish, not an agreement
Do this today
Rewrite this example for a product you use — pick one annoyance and PRD it. Want the full template with fill-in guidance (plus 11 more PM docs)? That’s the PM Docs Toolkit.