Most PRDs are too long and get ignored. They start as good intentions and end up as 15-page documents nobody reads, covering edge cases that never ship and implementation details that engineers ignore anyway.
A good PRD is a decision record. It captures why you're building something, who it's for, and how you'll know if it worked. Everything else is bloat.
The 7 Sections That Belong in a PRD
1. Problem Statement
What problem exists, for whom, and how do you know it's real? This section should be ruthlessly specific. "Users are frustrated with onboarding" is not a problem statement. "63% of trial users who fail to complete account setup in the first session never return (based on June-August cohort data)" is.
Include the user segment affected and the evidence you have. One paragraph is usually enough.
2. Goals and Success Metrics
What does success look like? State two to four measurable outcomes you expect this work to drive. For each metric, include a baseline and a target.
Example:
- Activation rate (users completing setup in first session): 34% → 55%
- Time-to-first-value: 4.2 days → 1.5 days
- Onboarding NPS: 31 → 52
These aren't aspirational. They're the criteria you'll use at launch to evaluate whether it worked. If you can't name them before you build, you're not ready to build yet.
For more on choosing the right metrics, see the complete guide to product metrics.
3. Non-Goals
What are you explicitly not solving? Non-goals prevent scope creep and protect the team from "while we're in there" thinking. They're also useful for stakeholders who might assume you're solving adjacent problems.
Example non-goals for an onboarding project:
- We are not redesigning the core product UI
- We are not changing the pricing or trial structure
- We are not building a help center or documentation site
4. User Stories
A short set of stories in the format: "As a [user type], I want to [action], so that [outcome]."
Keep this to five to eight stories maximum. If you need more than that, you're probably combining multiple features into one PRD. Split them.
Example:
- As a new admin user, I want to see my team's progress in setup so I can tell when we're ready to go live.
- As a first-time user, I want step-by-step guidance so I don't need to read documentation to get started.
5. Constraints
What are the real limits? These might be technical (must work on existing data model), business (must ship before Q2 pricing change), legal (GDPR compliance required), or resource (one engineer, six weeks).
Be honest here. Hiding constraints in a PRD and discovering them mid-sprint is one of the most common causes of rework.
6. Open Questions
What do you not know yet that could affect the design or build? List them explicitly. Assign an owner and a resolution date where possible.
Example:
- Do we need to support SSO setup in the onboarding flow? Owner: PM. Decision needed by April 5.
- What happens to partially-completed setups if a user upgrades mid-onboarding? Owner: Engineering. Decision needed before design sign-off.
Open Questions is the most important section most PMs skip.
7. Appendix
Background research, data, links to related PRDs, customer quotes, or any supporting material that's useful but not essential to the core decision. Keep it out of the main body so the PRD stays readable.
A Worked Example: SaaS Onboarding Flow Improvement
Problem Statement: 58% of new users who activate a trial fail to complete account setup within 24 hours. Users who don't complete setup within 24 hours convert at 12% vs. 41% for users who do (Q3 cohort data, n=1,847). Current setup flow has no progress indication, no contextual guidance, and no checkpoint saves.
Goals:
- Increase 24-hour setup completion from 42% to 65%
- Improve trial-to-paid conversion for users who complete setup (baseline: 41%, target: 50%)
Non-Goals: Not redesigning the core dashboard. Not changing the trial length or pricing.
User Stories: [3-5 stories as above]
Constraints: Must use existing authentication system. Must ship before May 1 renewal season. One frontend engineer allocated.
Open Questions: Does mobile setup need to reach parity in v1? (Owner: PM, needed by April 8)
What NOT to Include
Technical implementation details. "We'll use a React stepper component with Redux state management" belongs in the engineering spec, not the PRD. Your job is to define what needs to happen, not how.
Exhaustive edge cases. A few critical edge cases in the user stories section are fine. A 40-row table of edge case scenarios belongs in QA planning, not the PRD.
UX wireframe descriptions in prose. "The modal should have a blue header with the company logo centered above the form fields" is not PRD content. Link to the design file.
For more on structuring product requirements alongside discovery, see the complete guide to product discovery.
One-Pager vs. Full PRD
Use a one-pager (1-2 pages) for: single-team features, improvements to existing flows, work scoped under 6 weeks.
Use a full PRD (4-8 pages) for: multi-team or cross-functional projects, new product areas, high-risk or high-visibility features, anything with significant compliance or legal review.
The default should be the one-pager. If you feel pressure to write more, ask yourself whether you're adding value or covering uncertainty with words.
How PRDs Evolve
A PRD written at the start of a sprint is not the same document you want at handoff. Start minimal: problem statement, goals, a few user stories. Add the constraints and open questions as you learn them. Finalize non-goals after your first design review.
The PRD should reflect what you know, not what you hope is true. Update it as you learn.
For teams using prioritization frameworks to decide what to PRD first, the RICE calculator and weighted scoring tool are good starting points.