How to Write a PRD That Actually Ships: The 6-Dimension Framework
A PRD (Product Requirements Document) is the single most important document a Product Manager writes. It defines what to build, why to build it, and how to measure success.
Most PRDs fail not because the idea is bad, but because the document lacks clarity, measurable outcomes, or a testable hypothesis. After analyzing hundreds of PRDs and studying frameworks from Figma, Asana, Amazon, and leading PM practitioners like Lenny Rachitsky, we distilled what makes a PRD excellent into 6 dimensions.
Key Takeaways
- • Impact Definition (25%) is the most important dimension - always start with measurable outcomes
- • Use the hypothesis format: "We believe [X] for [user] will result in [metric], because [evidence]"
- • Non-Goals are critical - explicitly state what you're NOT building to prevent scope creep
- • Solution comes last - describe user outcomes, not implementation details
- • 2-4 pages is ideal - clarity beats length every time
What is a PRD?
A PRD (Product Requirements Document) is a document that describes what a product or feature should do, who it's for, and how success will be measured. It serves as the single source of truth for product development teams.
The PRD bridges the gap between business strategy and technical execution. It answers three fundamental questions:
- Why? The business problem and expected impact
- What? The user experience and functionality
- How will we know? The success metrics and validation approach
Why Most PRDs Fail
You've written a PRD. You present it. The feedback comes back: "Needs more detail." "What's the success metric?" "Who exactly is this for?" Sound familiar?
The problem isn't that you don't know your product—it's that PRDs require a specific structure to communicate effectively. Without it, stakeholders fill in the gaps with assumptions, and those assumptions rarely match yours.
The 3 PRD Failure Modes
- Vague metrics: "Improve user engagement" instead of "Increase DAU/MAU ratio from 0.15 to 0.22 in 90 days"
- Solution-first thinking: Starting with "We should build X" instead of "Users struggle with Y"
- Missing hypothesis: No way to validate if the solution actually solved the problem
The 6-Dimension PRD Framework
Based on frameworks from Figma's narrative specs, Asana's outcome-focused documentation, Amazon's PR/FAQ method, and insights from practitioners like Lenny Rachitsky, we've identified 6 dimensions that predict PRD success:
1. Impact Definition (25% weight)
This is the most heavily weighted dimension because it answers the fundamental question: Why are we building this?
An excellent impact definition includes four elements:
- Metric: What number will change?
- Direction: Will it go up or down?
- Magnitude: By how much? (baseline → target)
- Timeframe: By when?
"Improve user activation"
"Increase activation rate from 32% → 40% within 90 days of launch"
2. Problem Narrative (20% weight)
The problem narrative grounds your PRD in reality. It answers: Who is suffering, and why?
Three components of an excellent problem narrative:
- Specific user: Not "users" but "new users in their first 7 days who haven't connected a data source"
- Articulated pain: What frustration or obstacle do they experience?
- Evidence: User quotes, support tickets, data from analytics, or research findings
Example Problem Narrative
"New users who sign up from our marketing site drop off at a 47% rate during step 3 of onboarding (data source connection). Support tickets show users saying 'I don't know what data to connect' and 'The instructions are confusing.' This is our biggest activation blocker."
3. Hypothesis (20% weight)
A hypothesis makes your PRD falsifiable. It forces you to commit to a prediction that can be proven wrong—which is the only way to learn.
Use this exact PRD hypothesis format:
"We believe that [doing X] for [user Y] will result in [metric Z moving], because [reason grounded in evidence]."
"We think simplifying onboarding will help users."
"We believe that adding guided templates during step 3 for new users will increase completion rate from 53% to 70%, because users report not knowing what data to connect."
4. Success Criteria (15% weight)
Success criteria answer: How will we know this worked? Crucially, they also define what doesn't count as success.
- Success threshold: "≥30% of new users complete the guided flow"
- Non-success definition: "Positive feedback without behavior change is NOT success"
- Leading indicators: Early signals to track before final results (e.g., template selection rate)
Don't confuse output metrics (features shipped) with outcome metrics (user behavior changed). "Launched the feature" is not a success criterion.
5. Non-Goals (10% weight)
Non-goals prevent scope creep and align stakeholders on what you're intentionally not doing. They show you've thought about trade-offs.
Example Non-Goals
- • Supporting team collaboration features (will address in Q3)
- • Third-party integrations beyond our top 3 data sources
- • Custom branding for enterprise users
- • Mobile app support (web-first approach)
6. Solution Fit (10% weight)
The solution should come after the problem, not before. It should describe what the user experiences, not implementation details.
"Build a React component with a dropdown using Radix UI that calls our REST API endpoint /api/templates..."
"Users see 3 template options relevant to their industry. Selecting one pre-fills the connection form with suggested values."
Free PRD Template
Copy this PRD template and fill in each section. Use [PLACEHOLDER: ...] for data you need to gather.
# PRD: [Feature Name] ## Impact Definition [Metric] will move from [baseline] → [target] within [timeframe]. ## Problem Narrative **User:** [Specific user segment] **Pain:** [What they're struggling with] **Evidence:** - [User quote, support ticket, or data point] - [Additional evidence] ## Hypothesis We believe that [doing X] for [user Y] will result in [metric Z moving], because [reason grounded in evidence]. ## Success Criteria **Success:** [Measurable threshold] **Non-success:** [What doesn't count] **Leading indicators:** [Early signals to track] ## Non-Goals - [What this PRD does NOT solve] - [Explicitly out of scope] ## Solution Description [User-centric description of the experience, not implementation details] ## Open Questions - [Unknowns that need answers] - [Dependencies to resolve]
Frequently Asked Questions
What are the 6 dimensions of a good PRD?
The 6 dimensions are: 1) Impact Definition (25%) - measurable business outcomes, 2) Problem Narrative (20%) - specific user pain with evidence, 3) Hypothesis (20%) - testable prediction, 4) Success Criteria (15%) - how you'll measure success, 5) Non-Goals (10%) - what's explicitly out of scope, 6) Solution Fit (10%) - outcome-focused solution description.
What is the most important part of a PRD?
Impact Definition is the most important dimension (25% weight) because it answers 'Why are we building this?' A good impact definition includes: the metric that will change, the direction (up or down), the magnitude (baseline to target), and the timeframe.
How do you write a PRD hypothesis?
Use this format: 'We believe that [doing X] for [user Y] will result in [metric Z moving], because [reason grounded in evidence].' For example: 'We believe that adding guided templates during onboarding for new users will increase completion rate from 53% to 70%, because users report not knowing what data to connect.'
What should NOT be in a PRD?
Avoid: 1) Implementation details like specific technologies or code architecture, 2) Vague metrics like 'improve engagement', 3) Solution-first thinking without defining the problem, 4) Missing hypothesis that makes the PRD unfalsifiable, 5) Output metrics (features shipped) instead of outcome metrics (user behavior changed).
How long should a PRD be?
Most effective PRDs are 2-4 pages. The goal is clarity, not length. A PRD should be long enough to cover all 6 dimensions with specific examples and evidence, but short enough that stakeholders will actually read it. If your PRD exceeds 10 pages, consider breaking it into smaller features.
Sources & Further Reading
- Lenny Rachitsky - "Examples and templates of 1-Pagers and PRDs" (Lenny's Newsletter)
- Figma - PRD Template & Product Requirements Documentation
- Amazon - Working Backwards PR/FAQ Instructions & Template
- Asana - Write an Effective Product Brief (Template)
- Marty Cagan - "INSPIRED: How to Create Tech Products Customers Love" (SVPG)
- Marty Cagan - "The End of Requirements" (SVPG)
Ready to test your PRD?
Paste your PRD into Roastinator 300K and get instant AI feedback on all 6 dimensions. Free, no signup required.
Try Roastinator 300K Free