Product Requirements Document
Purpose
Create a decision-ready product specification that explains why work matters, what must be delivered, what is out of scope, and how success will be evaluated without inventing unavailable facts.
Workflow
- State the user or business problem, relevant context, and the intended outcome.
- Define measurable success criteria and identify the evidence or baseline supporting each one.
- Describe the proposed user-facing behavior and the functional requirements needed to support it.
- Separate in-scope work, explicit exclusions, assumptions, dependencies, and unresolved questions.
- Surface non-functional requirements such as accessibility, reliability, privacy, performance, or security only when relevant.
- Identify risks, owners where known, and validation or rollout considerations.
- Deliver the PRD as a reviewable draft; do not present it as approved unless the user confirms approval.
Required sections
Include: Problem, Goals and success measures, Users and use cases, Scope, Requirements, Non-functional considerations, Dependencies and risks, Open questions, and Acceptance criteria.
Quality boundaries
Do not fabricate customer evidence, market data, timelines, owners, technical commitments, or performance targets. Mark assumptions and placeholders visibly. Keep solution detail sufficient for alignment but leave implementation design to the relevant technical decision process.
Error handling
| Situation |
Response |
| Problem is not agreed |
Produce a problem-framing draft and identify the missing decision. |
| Requirements conflict |
Record the conflict, affected stakeholder, and trade-off rather than hiding it. |
| Metrics have no baseline |
Propose a measurement plan and label the target provisional. |
| Scope is too broad |
Split the document into a smallest viable release and deferred work. |
1---2name: product-requirements-document3description: Write a clear product requirements document that defines the problem, scope, requirements, success measures, risks, and open questions. Use for: product requirements document, PRD, feature specification, engineering handoff.4license: Apache-2.05---67# Product Requirements Document89## Purpose1011Create a decision-ready product specification that explains why work matters, what must be delivered, what is out of scope, and how success will be evaluated without inventing unavailable facts.1213## Workflow14151. State the user or business problem, relevant context, and the intended outcome.162. Define measurable success criteria and identify the evidence or baseline supporting each one.173. Describe the proposed user-facing behavior and the functional requirements needed to support it.184. Separate in-scope work, explicit exclusions, assumptions, dependencies, and unresolved questions.195. Surface non-functional requirements such as accessibility, reliability, privacy, performance, or security only when relevant.206. Identify risks, owners where known, and validation or rollout considerations.217. Deliver the PRD as a reviewable draft; do not present it as approved unless the user confirms approval.2223## Required sections2425Include: **Problem**, **Goals and success measures**, **Users and use cases**, **Scope**, **Requirements**, **Non-functional considerations**, **Dependencies and risks**, **Open questions**, and **Acceptance criteria**.2627## Quality boundaries2829Do not fabricate customer evidence, market data, timelines, owners, technical commitments, or performance targets. Mark assumptions and placeholders visibly. Keep solution detail sufficient for alignment but leave implementation design to the relevant technical decision process.3031## Error handling3233| Situation | Response |34|---|---|35| Problem is not agreed | Produce a problem-framing draft and identify the missing decision. |36| Requirements conflict | Record the conflict, affected stakeholder, and trade-off rather than hiding it. |37| Metrics have no baseline | Propose a measurement plan and label the target provisional. |38| Scope is too broad | Split the document into a smallest viable release and deferred work. |
Stijnman