PRD · Planning guide

Product requirements document

A shared statement of the user problem, intended outcome, scope, and evidence of success.

A concise Markdown template for product intent, traceable requirements, measures, risks, and one decision gate.

Download prd-template.md ↓View the Markdown example ↓

At a glance

Terminology: A local product-management record, not an ISO-defined document type
Record steward: Product — keeps the record current and connects its evidence
Decision authority: A named sponsor or accountable role — decides the recorded gate outcome
Shelf life: Update it when evidence, scope, or delivery decisions change

A product requirements document makes a proposed product change reviewable. This guide uses it to record the user problem and evidence, intended outcome, scope boundaries, expected behaviour, and measures.

A named record steward keeps the PRD current and links research, designs, constraints, risks, dependencies, and delivery work. A named decision authority uses the gate to choose go, hold, stop, or recovery; a material scope change reopens the gate. Use an RFC when a technical trade-off needs its own proposal.

State the outcome, boundaries, evidence, and next decision. Link detailed technical and operational work instead of copying it.

Technical references

Use these only when the change needs the deeper contract. Keep the main document focused on its decision.

Payment recovery and decision binding
A small, provider-neutral contract for creating payments, resolving uncertain outcomes, and preventing stale fraud decisions from authorising fulfilment.
Controlled rollout evidence
A practical guide to registering a decision plan for comparative experiments and staged rollouts, with stable assignment, usable evidence, and clear pause authority.

# PRD: Guest checkout

Illustrative example · fictional names, dates, figures, and URLs · status: In delivery · record steward: jonas@ · decision authority: @checkout-sponsor · target release: 2026-09-15

## Decision summary

Approve a 2% guest-checkout trial for eligible new visitors. Expansion needs registered evidence; otherwise account-first remains.

## Problem, outcome, scope, and constraints

The current journey requires an account before purchase. In the 12 complete UTC weeks from 2026-06-01 to 2026-08-23, 34% of eligible attempts reaching forced sign-in had no matching paid order within 24 hours; `account-forced` was the third-most-common validated support tag. Evidence: [CHECKOUT-18](https://example.invalid/research/CHECKOUT-18). This is an observed association, not proof that forced sign-in caused exit.

Eligible new visitors complete one purchase without an account, with no worse support, payment, fraud, privacy, accessibility, or service health.

In scope: a guest choice, contact and delivery details, approved-provider payment, confirmation, authorised support lookup, measurement, and recovery. Guest checkout creates no account, credential, reusable profile, or marketing consent. Order data is used only as approved for fulfilment, support, reconciliation, and retention. Social sign-in, loyalty points, post-purchase account creation, and changes to the existing account journey are out of scope. Constraints: approved privacy, accessibility, payment-provider, fraud, and support records must remain current.

## Roles and needs

- **Record steward:** jonas@ keeps the PRD and evidence current.
- **Sponsor:** @checkout-sponsor authorises planned start, expansion, stop, and resumption.
- **Emergency pause:** @release-manager may stop new guest assignment or the guest offer for an affected scope. Existing attempts complete or enter approved recovery.

| ID | User need | Evidence |
| --- | --- | --- |
| UN-1 | An eligible new visitor buys without creating an account. | [CHECKOUT-18](https://example.invalid/research/CHECKOUT-18) |
| UN-2 | A returning-account customer keeps the current journey. | [DES-204](https://example.invalid/design/DES-204) |
| UN-3 | A checkout user can review and correct the order before payment. | [ACC-08](https://example.invalid/accessibility/ACC-08) |
| UN-4 | A customer can recover from payment uncertainty without an unresolved second charge, duplicate order, or duplicate fulfilment. | [PAY-5.0](https://example.invalid/payment/PAY-5.0) |
| UN-5 | A support colleague can help only with the customer’s exact order. | [SUP-19](https://example.invalid/support/SUP-19) |

## Requirements

All six requirements are Must for this release.

| ID | Need | Observable behaviour and proof |
| --- | --- | --- |
| R1 | UN-1, UN-2 | Guest checkout is offered only when the approved eligibility service classifies an unauthenticated visitor as eligible. Missing or ambiguous evidence keeps the current path. [QA-101](https://example.invalid/acceptance/QA-101) |
| R2 | UN-1 | The flow creates no account and uses only data approved in [PRIV-4.0](https://example.invalid/privacy/PRIV-4.0). Card data goes to the hosted provider; the service never stores PAN or CVV/CVC. [QA-102](https://example.invalid/acceptance/QA-102) |
| R3 | UN-3 | All organisation-controlled guest pages and states meet [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/#conformance-reqs). The provider hand-off has approved accessibility evidence, tested hand-off, and documented recovery route. [QA-103](https://example.invalid/acceptance/QA-103) |
| R4 | UN-4 | A retry, lost response, callback, or query creates no duplicate order or fulfilment and leaves no unresolved second charge. The server verifies the matching provider result before finalisation; browser return is not proof. Follow [payment recovery](/plan/prd/payment-recovery/). [QA-104](https://example.invalid/acceptance/QA-104) |
| R5 | UN-5 | Support discloses one order only when the approved [identity-verification procedure (IVP)](https://example.invalid/support/SUP-19) establishes the requester’s entitlement. Failed, expired, replayed, cross-customer, or cross-tenant checks disclose nothing. [QA-105](https://example.invalid/acceptance/QA-105) |
| R6 | UN-1 | Each enrolled attempt records its assigned experience, outcome, safety signals, and data-quality evidence. Use a concurrent control that meets `STAT-1.0` causal-design conditions; history plans but does not establish causation. Follow [controlled rollout evidence](/plan/prd/controlled-rollouts/). [QA-106](https://example.invalid/acceptance/QA-106) |

## Measures and decision gate

| Measure | Registered decision use |
| --- | --- |
| Eligible-visitor completion | Compare eligible attempts with one paid order in the defined window against the concurrent control. |
| `account-forced` contacts | Track validated contacts in the defined window after an eligible attempt. |
| Payment and fraud safety | Track duplicate charge or order, unresolved provider result, fraud-control bypass, and registered harm limits. |
| Existing-path, service, and data quality | Track returning-account completion, support, accessibility, errors, latency, assignment coverage, and reconciliation. |

[STAT-1.0](https://example.invalid/analysis/STAT-1.0) fixes population, assignment, windows, thresholds, data-quality checks, and action before 2% starts. It pre-registers outcome review 14 days after final scheduled 25% enrolment, after the seven-day outcome window and reconciliation.

| Required evidence | Decision authority | Decision and action |
| --- | --- | --- |
| Start, expansion, or resumption: QA-101–QA-106 checks, specialist approvals, monitoring, recovery exercise, and pre-registered `STAT-1.0` conditions pass with no unresolved critical harm, recovery, or data-quality issue. | @checkout-sponsor | Go; otherwise Hold or Stop. |
| Safety breach, failed approval, duplicate charge or order, unauthorised disclosure, fraud-control bypass, or material service regression. | @checkout-sponsor | Recover — @release-manager pauses new assignment immediately; the sponsor resumes with fresh recovery evidence. |

## Risks and open questions

- **Payment uncertainty:** Payments reconciles unknown results; unresolved results hold the rollout.
- **Fraud or wrongful block:** Risk owns the policy, review path, and registered harm limit; a breach pauses new assignment.
- **OQ-1:** Support and security must approve and test the identity-verification procedure (IVP) by 2026-09-01. It blocks 2%.

Detailed guidance

Use it when

A product or feature needs shared intent across disciplines
The user problem, scope, or expected behaviour needs review
The team needs measurable outcomes and a clear review point
Assumptions, dependencies, or open questions could change the work

Skip it when

A contained maintenance change already has clear evidence and acceptance criteria
A low-risk, reversible experiment fits in a short brief or backlog item
The document would only repeat information that is current and reviewable elsewhere

What it contains

Decision summary: The proposed change, who it serves, the decision required, and what happens without action.
Problem and evidence: Who is affected, what happens now, and the evidence behind the claim.
Outcomes and measures: The intended outcomes and the measures and guardrails that inform a decision.
Scope and constraints: What is included, what is deliberately excluded, and the limits the work must respect.
Users, needs, and evidence: Stable user-need IDs with the situation, need, and supporting evidence.
Requirements and acceptance: Observable behaviour, release priority, and linked acceptance proof.
Delivery and operations: Material dependencies, migration, support, monitoring, and recovery, each with an owner.
Risks and open questions: Items that could change the work, with an owner, action, and due date.
Specialist records: Linked payment, rollout, webhook, event-processing, and other specialist evidence for each applicable concern.
Decision gate: The required evidence, the decision authority, and the recorded decision and action.

Write it well

Name a record steward and a separate decision authority
Write it with product, design, engineering, research, and affected partners
Link each requirement to a user need and planned acceptance evidence
Define only the measures that inform a decision
Keep go, hold, stop, and recovery conditions in one decision-gate table
Link detailed designs, policies, and technical contracts instead of duplicating them

Avoid

Specify every implementation detail before the team has learned enough
Use sign-off as a reason to freeze requirements that should change
Treat delivery as success instead of defining an outcome for users or the business
Write the PRD alone or duplicate detailed work that can be linked
Use Must or Should without defining the release-priority rule
Treat a historical baseline as proof that a rollout caused an outcome