> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# What Is a Product Requirements Document? How to Write One
> Learn what a product requirements document is, how to write and review one with people and coding agents, and where technical design begins.
A product requirements document, or PRD, defines the user problem, intended outcome, scope, and observable requirements for a product or feature. It answers what should change and why. It should stop before detailed technical design and the step-by-step implementation sequence.
## What belongs in a PRD
| Question | PRD answer |
| ----------------------------------- | ---------------------------------------------------------- |
| Who has the problem? | Named users, relevant context, and journeys |
| Why solve it? | Evidence, goals, and the outcome that matters |
| What must the product do? | Observable functional requirements and acceptance criteria |
| What quality boundary matters? | Measurable nonfunctional requirements |
| What is excluded? | Non-goals and release boundaries |
| How will the team judge the result? | Success metrics plus counter-metrics |
| What is still unknown? | Open questions with an owner or evidence path |
A useful requirement is specific enough to challenge but does not prescribe a design without cause:
```md theme={null}
FR-4. A workspace owner can choose an expiry when creating a guest link.
Acceptance: Given an owned folder, when the owner selects seven days,
then the created link shows the same expiry before it is copied.
```
The requirement describes user-visible behavior. It does not choose a database column, cache strategy, or route implementation.
## How to write a product requirements document
1. State the user problem and link the evidence that makes it worth solving.
2. Name the users and write the journeys that deliver the intended outcome.
3. Set goals, non-goals, constraints, and dependencies before listing features.
4. Write observable requirements with acceptance criteria. Keep technical choices out unless they are fixed product constraints.
5. Add success metrics, counter-metrics, and open questions with owners or evidence paths.
6. Review the full document for conflicts, undefined terms, missing failure paths, and assumptions that a coding agent could mistake for decisions.
The [product requirements document template and example](/templates/product-requirements-document) applies this sequence in copyable Markdown.
## When to use one
Use a PRD when several people or agents need a shared product boundary before technical design, especially when the work has multiple user journeys, meaningful non-goals, business or usability outcomes, or unresolved product questions.
Use a [PRFAQ](/frameworks/amazon-working-backwards-prfaq) earlier, when the team still needs to test the proposed customer value and answer the questions that could stop the idea. A PRFAQ can lead to a PRD once the product direction is clear.
Skip a separate PRD when the change is small, reversible, and already has a clear user outcome. A concise issue or coding plan may be enough. Do not create a PRD only to satisfy a process label.
## How people and coding agents should review it
People should challenge the problem, evidence, priority, user impact, risk, and success measures. Coding agents can help test internal consistency, find undefined terms, trace acceptance criteria to requirements, and identify technical questions that the PRD leaves unresolved.
Use this review sequence:
1. Restate the user problem and intended outcome without copying the summary.
2. Trace each journey to one or more requirements.
3. Mark requirements that cannot be observed or tested.
4. Check goals against non-goals, constraints, success metrics, and counter-metrics.
5. Separate product questions from technical-design questions.
6. Record open questions instead of silently filling them with agent assumptions.
An agent should not turn an ambiguous product choice into an implementation detail. It should surface the choice and request evidence or a decision.
## Where the PRD stops
| Document | Primary job | Typical detail |
| ----------------------- | --------------------------------------------------- | ------------------------------------------------------------------- |
| PRD | Define product intent and required outcomes | Users, journeys, scope, requirements, acceptance, metrics |
| Technical specification | Define the maintained technical behavior and design | Architecture, interfaces, data, failure behavior, security, rollout |
| Implementation plan | Sequence the current change | Files or systems, ordered steps, dependencies, risks, validation |
These boundaries are editorial guidance, not universal industry law. Teams use different names. The important test is whether readers can tell which document owns product intent, which owns technical truth, and which is the current execution sequence.
BMad Method’s pinned [PRD template](https://github.com/bmad-code-org/BMAD-METHOD/blob/717479bc3f50f38119fd958b9e577a8bde2e0184/src/bmm-skills/2-plan-workflows/bmad-prd/assets/prd-template.md) separates product vision, users, journeys, requirements, non-goals, scope, metrics, and questions from its later architecture and delivery artifacts. GitHub Spec Kit’s pinned [specification](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/spec-template.md), [plan](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/plan-template.md), and [tasks](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/tasks-template.md) show a comparable separation under different names. Atlassian’s maintained [PRD guide](https://www.atlassian.com/agile/product-management/requirements) is another source-backed example of goals, assumptions, user stories, design context, and out-of-scope decisions.
Start with the [PRD template](/templates/product-requirements-document). Then use [PRD vs technical specification vs implementation plan](/compare/prd-vs-technical-specification-vs-implementation-plan) to place the downstream documents. Workspaces can [share, annotate, edit, and version the PRD](/workspaces/review-plans-and-technical-decisions) with people and agents; it does not generate the document for you.
*Reviewed July 18, 2026. Written and maintained by the Plannotator documentation team.*