PM PRD Writing
Problem statements, success metrics, out-of-scope, and outcomes vs. outputs
PRD writing essentials
- PRD purpose: align team on problem + solution + success criteria — not a spec or roadmap
- Problem statement: quantified symptom + user evidence + business impact (not "we need to improve X")
- Success metrics: baseline + target + metric + timeframe — outcomes, not outputs
- Out of scope: explicitly document what is NOT being built — prevents scope creep
- Outputs = "we shipped it"; outcomes = "it worked" — measure outcomes, not delivery
Question 0 of 5
What is the primary purpose of a Product Requirements Document (PRD)?
Align team on problem + solution + success criteria. A PRD answers three questions:
- Why are we building this? — the problem, opportunity, or strategic goal
- What are we building? — the proposed solution at the right level of detail
- How will we know if it worked? — measurable success metrics
Which problem statement in a PRD is written most effectively?
Quantified problem + user evidence + business impact. Problem statement anatomy:
- Data: "62% of users who sign up never complete profile setup" — the measurable symptom
- Evidence: "Exit surveys show 40% don't understand what the product does" — user research
- Impact: "$1.2M annual revenue loss" — the business consequence
What should a "success metrics" section in a PRD contain?
Baseline + target + metric + timeframe. Success metrics template:
- "Onboarding completion rate: baseline 38% → target 60% within 60 days of launch"
- "Trial-to-paid conversion: baseline 8.2% → target 11% within 90 days of launch"
- "Time to first value (first meaningful action): baseline 8 min → target under 3 min"
A PRD section reads: "Out of scope: advanced analytics, A/B testing of onboarding flows, mobile app version." Why is this section important?
Prevents scope creep by documenting what is NOT being built. Out-of-scope section value:
- When a stakeholder says "can we also add A/B testing?" — the PM can point to the PRD: "That's explicitly out of scope for v1. Here's where we documented that decision."
- Developers know where to draw the line without asking for clarification every time
- Stakeholders who didn't get their feature can see it was considered and deferred (not forgotten)
- "Out of scope" = not in this release, may or may not happen later
- "Future work" = planned for a subsequent release, already roadmapped
Which part of a PRD is most often written poorly, and what is the common mistake?
Success metrics: outputs (shipped features) vs. outcomes (measurable user behaviour change). Output vs. outcome examples:
- ❌ Output: "Launch the redesigned onboarding flow by Q3" — this is a delivery milestone, not a success metric
- ✅ Outcome: "Increase onboarding completion rate from 38% to 60% within 60 days of launch" — this is a user behaviour change