PRD key facts
- Start with evidence about the problem, not a preferred feature.
- Separate goals from non-goals.
- Write acceptance criteria as observable outcomes.
- Include edge cases, analytics, rollout, and rollback.
- Record unresolved questions with owners and dates.
Copyable Markdown PRD template
# Product requirements document: [Feature or product]
**Product owner:** [Name]
**Status:** Draft
**Version:** 0.1
**Last updated:** YYYY-MM-DD
## Summary
[Describe the user problem and proposed outcome.]
## Problem statement
**Who has the problem?** [User segment]
**What happens today?** [Current behavior]
**Why does it matter?** [Impact]
**Evidence:** [Research, support tickets, analytics, or links]
## Goals
- [Measurable outcome]
## Non-goals
- [What this release will not solve]
## Users and use cases
| User | Situation | Need | Desired outcome |
|---|---|---|---|
| [Persona] | [Context] | [Need] | [Outcome] |
## Requirements
| ID | Requirement | Priority | Acceptance criteria |
|---|---|---|---|
| FR-01 | The user can [action]. | Must | Given [context], when [action], then [result]. |
## Edge cases and error states
- [Condition] → [Expected behavior]
## Analytics and success measures
| Event or metric | Definition | Baseline | Target |
|---|---|---:|---:|
| [Metric] | [Calculation] | [Value] | [Value] |
## Dependencies and constraints
- [System, team, legal, security, or timeline constraint]
## Rollout and rollback
- **Rollout:** [Stages, feature flag, audience]
- **Rollback trigger:** [Condition]
- **Rollback method:** [Action]
## Open questions
- [ ] [Question] · **Owner:** [Name] · **Due:** YYYY-MM-DD
## Approval
| Role | Name | Status | Date |
|---|---|---|---|
| Product | [Name] | Pending | |
| Design | [Name] | Pending | |
| Engineering | [Name] | Pending | |
PRD versus technical design
The PRD defines the product problem and required outcomes. The technical design explains the implementation. Link the two documents instead of forcing architecture details into the PRD.
Write testable requirements
Use one requirement per row and assign a stable ID. “The page should be fast” is not testable. “The checkout confirmation appears within two seconds for 95% of successful requests under the agreed load test” gives design and engineering a measurable target.
Acceptance criteria should cover the normal outcome, permissions, empty states, errors, and important boundaries. Avoid specifying interface details unless the detail itself is a requirement.
Review a PRD
Product should verify the problem and priority. Design should verify the user flow, content, and accessibility needs. Engineering should identify feasibility, dependencies, and operational risks. Analytics should confirm events and metric definitions. Security, privacy, legal, or support review may be required depending on the change.
Approval does not eliminate discovery. Update the document when evidence changes the requirement, and record material changes so the team can see why scope moved.
Completed requirement example
Weak: “Users should be able to export quickly.”
Stronger: “A signed-in user can export the current document as PDF. For documents up to 100 pages, 95% of exports complete within 10 seconds under the agreed production load. If export fails, the document remains unchanged and the user receives a retryable error.”
The stronger requirement names the user, action, performance boundary and failure behavior without prescribing a specific implementation.
When not to use a full PRD
Do not force a large PRD onto a small copy change or a well-understood defect. A brief issue with acceptance criteria may be enough. Use the full template when multiple teams need a shared account of the problem, scope, requirements, measures and rollout.
PRD template FAQ
How long should a PRD be?
As long as needed to remove important ambiguity. Prefer evidence, tables and testable requirements over narrative. Link supporting research instead of copying it wholesale.
Who owns the PRD?
Product normally owns the problem, scope and outcomes. Design, engineering, analytics and other specialists should review the sections they must deliver or validate.
Should a PRD contain wireframes?
It can link to wireframes or include them when they clarify a requirement. Do not treat a screen design as a substitute for describing user needs, states, permissions and acceptance criteria.