On this page
A product requirements document should help a team make consistent implementation and review decisions. It describes the problem, the people affected, the intended behavior, the boundaries of the release, and the evidence needed to decide that the work is ready. Its value comes from reducing ambiguity, not from its page count.
The document is most useful when it follows a complete journey. A list of screens can omit permissions, background processing, failed requests, support work, and recovery. Start with what a person is trying to accomplish, then explain what must happen from the initial trigger through a meaningful finish.
Begin with the problem and its evidence
Describe a concrete situation in which the current experience fails. For a fictional equipment-reservation service, the problem might be that staff cannot tell whether a request has been accepted, so they send duplicate requests and call the office for confirmation.
Separate observation from inference. Support records may show repeated calls about reservation status. They do not automatically prove that a new mobile app is the right solution. Record what the evidence establishes and what still needs investigation.
Name the affected users and circumstances. A first-time requester, an administrator, and a person collecting equipment may need different information. Avoid defining the audience only as “everyone” or “the customer,” because those labels conceal important differences in access and responsibility.
State the outcome before the feature
An outcome describes what becomes possible or improves. In the reservation example, a requester should be able to determine whether the request is pending, accepted, declined, or canceled, and know the next relevant action.
The feature may be a status page, a notification, or a change to an existing confirmation screen. Keep the outcome distinct from the chosen interface so the team can assess alternatives without losing the purpose of the work.
Choose a useful success signal and define it carefully. A reduction in duplicate requests might matter, but only if the system still accepts legitimate repeated reservations. A rise in page views could mean that the page is helpful or that people must revisit it because the information is unclear.
Map the complete journey
List the starting condition, the user's action, the system response, the resulting state, and the finish. Include any handoff to another person or system. The journey is incomplete if it stops when a button changes color while the actual reservation remains unresolved.
For the fictional service, a simple flow might be: choose an available item, enter the required details, review the request, submit once, receive a reference, and view the current status. An administrator then accepts or declines the request through an authorized process.
Show where the requester leaves the product and returns. An email link, a saved reference, or an authenticated account may provide that route. Decide what happens when the link expires, the person changes devices, or the notification is delayed.
Define states and transitions explicitly
A state table often reveals missing decisions more quickly than a paragraph of feature language. Keep the example small enough to review while including the transitions that affect the user's understanding.
| Current state | Event | Resulting state | What the requester sees |
|---|---|---|---|
| Draft | Valid submission completes | Pending | Reference and expected next step |
| Pending | Authorized approval completes | Accepted | Collection details or where to find them |
| Pending | Authorized decline completes | Declined | Clear outcome and appropriate next option |
| Pending | Cancellation completes | Canceled | Confirmation that the request is no longer active |
This is an illustrative model, not a universal reservation specification. Real requirements must decide whether accepted requests can be canceled, how availability is reserved, and what happens when two people request the same item.
Avoid using one vague status such as “done” for several outcomes. Accepted, declined, and canceled all end part of a workflow, but they mean different things to the person using the service.
Separate requirements from design choices
A requirement might say that a requester can review the details before submitting. A design choice might place that review on a separate screen. Record both where needed, but do not confuse the chosen arrangement with the underlying need.
Likewise, a requirement to prevent unauthorized status changes does not specify every implementation detail. Engineering and security design must explain how access is enforced. The PRD should identify the boundary and reference the design rather than pretending that a sentence alone provides the control.
Use precise language for constraints. “Fast” and “secure” are aspirations unless the team agrees on an observable standard, a relevant context, and a way to verify it. Keep measurements tied to the user journey and operating conditions that matter.
Include failure and recovery behavior
Describe what the user sees when validation fails, a network request times out, a dependency is unavailable, or the submission result is uncertain. Preserve useful input where appropriate and explain how the user can continue without accidentally duplicating the action.
In the reservation example, a timeout after submission should not automatically tell the requester to submit again. The system may need to check whether the request was created and show a recoverable status. The exact design depends on the service, but the ambiguity belongs in the requirements discussion.
Identify which failures require support and what information support can safely use to investigate. A reference number and a clear status may help more than an unexplained error code. Avoid exposing private records or internal diagnostics to someone who is not authorized to see them.
Make scope exclusions useful
An exclusion should prevent a predictable misunderstanding. The first release might support a single pickup location and omit recurring reservations. State that plainly, along with any effect on the user journey.
Do not hide a required step by placing it out of scope. If a reservation cannot be completed without staff approval, the release still needs an operational approval path, even if the first version uses an existing staff tool.
Distinguish a deliberate exclusion from an unresolved decision. “No recurring reservations in this release” is a scope choice. “Cancellation after acceptance needs a policy decision” is an open question with an owner and a deadline for resolution.
Write acceptance criteria that can reject a bad implementation
Acceptance criteria should describe observable behavior in a defined situation. “The confirmation looks good” is difficult to review consistently. “After a successful submission, the requester sees the reservation reference and pending status” is clearer.
Include criteria for the important boundaries: a person cannot view another person's private request, invalid input receives a useful correction, and an uncertain submission does not silently create duplicate reservations. The criteria should reflect the actual risks of the feature rather than a generic checklist pasted into every document.
Link the criteria to the relevant design, test evidence, and unresolved questions. A reviewer should be able to trace an important requirement to evidence without searching across unrelated conversations.
Record dependencies and operating responsibilities
A product may depend on email delivery, inventory data, staff availability, or a third-party service. Name the dependency and describe what happens when it is delayed or unavailable. Do not present an external team's unconfirmed work as a settled fact.
Include ownership after launch. Someone must maintain reference data, answer support questions, monitor failures, and decide whether the feature should be paused. A complete release plan covers those responsibilities as well as the interface.
Keep sensitive implementation details in the appropriate restricted document. The PRD can link to a security or operations plan without copying credentials, private customer records, or production access instructions into a broadly shared artifact.
Keep the document current without erasing decisions
Give the document an owner and a revision date. When a requirement changes, update the current behavior and record the material decision that changed it. Readers should not have to infer the latest scope from a long comment thread.
Archive superseded alternatives where they help explain a tradeoff, but keep the main document focused on the current release. A PRD that presents three incompatible designs without identifying the chosen one is not ready to guide implementation.
Before development or approval, walk through the journey with design, engineering, support, and the relevant operational owner. Ask each person to explain the expected result at the important boundaries. Differences in those explanations are useful findings to resolve before they become inconsistent product behavior.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Service Manual: Learning about users and their needs Requirements should be informed by what actual or likely users need to accomplish and should be revisited as evidence develops.
- GOV.UK Service Manual: Writing user stories User stories connect the person, need, and purpose; acceptance criteria describe outcomes that establish whether the need is met.