What is a Product Requirement Document?
A PRD is a document that specifies what a product or feature should accomplish, who it serves, how success is measured, and the detailed requirements for building it. It bridges the gap between strategy ("we need to improve onboarding") and execution ("here is exactly what the new onboarding flow does").
Modern PRDs are not the 50-page waterfall documents of the past. They are concise, living documents that evolve as the team learns. The best PRDs are 3-5 pages and focus on clarity over completeness.
Why PRDs Matter
Without a PRD, requirements live in the PM's head, scattered Slack messages, and half-remembered meeting conversations. Engineers fill gaps with assumptions. Designers interpret requirements differently than the PM intended. QA does not know what "done" looks like.
A good PRD prevents rework. When requirements are explicit and shared, the team builds the right thing the first time. When requirements are ambiguous, you discover misunderstandings during code review or, worse, after launch.
PRD Template: What to Include
Here is a practical template that works for most SaaS features. Adapt the depth to match the complexity of what you are building.
1. Problem Statement (1-2 paragraphs)
What problem are you solving and for whom? Why does it matter now? This section should pass the "so what?" test. If a reader finishes and shrugs, the problem is not compelling enough to build for.
2. Goals and Success Metrics
Define 2-3 measurable outcomes. "Increase activation rate from 32% to 40% within 60 days of launch" is specific. "Improve the user experience" is not. Connect goals to business impact so stakeholders understand why this work matters. Use tools like the RICE Calculator to validate that this feature deserves priority over alternatives.
3. User Flows
Walk through the feature from the user's perspective. What do they see? What actions are available? What happens when they click? Include the happy path and 2-3 key error states. Wireframes or mockups from design go here.
4. Detailed Requirements
For each user flow, list specific requirements. Use "must," "should," and "could" to indicate priority (MoSCoW style). Each requirement should be testable.
Good: "The search bar must return results within 200ms for queries up to 100 characters."
Bad: "Search should be fast and intuitive."
5. Acceptance Criteria
Write acceptance criteria for every requirement. These are the conditions that QA and UAT will verify. Format them as "Given [context], when [action], then [expected result]."
6. Out of Scope
Explicitly list what you are not building. This prevents scope creep and manages stakeholder expectations. "V1 will not include bulk import, scheduled exports, or admin role management" is clear. Silence on scope boundaries invites assumptions.
7. Technical Constraints
Engineering adds notes on API rate limits, data migration needs, third-party dependencies, and performance requirements. PMs should not write this section alone.
8. Open Questions
List unresolved decisions with owners and deadlines. A PRD with zero open questions is either a small feature or an overly confident PM. Surfacing unknowns early is more valuable than pretending you have all the answers.
How to Write a Good PRD
Start with context: the problem, the target user, and why this matters now. This is the product brief section. Engineers who understand the "why" make better implementation decisions.
Define user flows. Walk through the feature from the user's perspective: what do they see, what actions are available, what happens when they click? Include the happy path and key error states.
Write acceptance criteria for every user story. These are testable conditions that define when the story is done. "Users can filter results by date range" is testable. "The filter should be intuitive" is not.
Document edge cases. What happens when the list is empty? What about users with 10,000 items? What if the API times out? Engineers will hit these cases. Better to think through them upfront.
Specify what is out of scope. Explicitly list what you are not building. This prevents scope creep and manages stakeholder expectations.
PRD Anti-Patterns to Avoid
The novel. A PRD that reads like a book. Engineers skim it, miss details, and ask questions the document already answered (buried on page 12). Keep sections scannable with headers, bullet points, and bold key terms.
The solution spec. A PRD that dictates database schema, API endpoints, and class structure. The PM's job is to define what the user needs, not how the system implements it. Prescribing implementation prevents engineers from finding better solutions.
The wishlist. A PRD that includes everything the PM wants without prioritization. When everything is a "must have," nothing is. Use MoSCoW or a similar framework to make priority explicit.
The ghost document. A PRD written once and never updated. Requirements change as the team learns. A PRD that reflects week-1 thinking during week-6 of development causes confusion. Set a reminder to review the PRD at sprint boundaries.
The solo effort. A PRD written by the PM in isolation. The best PRDs are drafted by the PM and reviewed by engineering (for feasibility), design (for UX gaps), and QA (for testability) before development starts.
PRDs in Practice
Stripe's PRDs are famously well-structured. They start with a "context and motivation" section, followed by user-facing behavior, API specifications, and migration plans. The emphasis is on developer experience and backward compatibility.
At Linear, PRDs are lightweight documents stored as Linear issues with linked sub-issues. The format is less formal than a traditional PRD but captures the same essential information: problem, solution, and acceptance criteria.
Common Pitfalls
- Writing a novel. If the PRD is longer than 5 pages, it probably includes implementation details that should be left to engineering.
- No acceptance criteria. Without clear criteria, "done" is subjective and arguments follow.
- Static documents. PRDs should be updated as the team learns. A PRD written 6 weeks ago may no longer reflect current understanding.
- Skipping the "why." Engineers who understand the problem often find better solutions than the one specified. Include the context.
- No review before development starts. The highest-ROI review happens before a single line of code is written. A 30-minute PRD review meeting catches misalignments that would cost days to fix during implementation.
Related Concepts
PRDs build on product briefs and are informed by product discovery. They decompose into user stories with acceptance criteria. The definition of done determines when a PRD's requirements are met. PRD quality directly affects user acceptance testing outcomes, since UAT scenarios are derived from PRD requirements. See also PRD for the existing general term.