PRD template

Product requirements document — the template

A method by Alexis Boyer · version 4.0 · September 22, 2026

Gate 2 fills this template; the filled PRD lives in the project folder beside the project memory and the project journal and moves into docs/ with them when the code starts, and it is what the coding agent reads at every gate after this one.

1. Strategic framing

In a few lines, say what the product is going to be: what is wanted, what is not wanted, the boundary it holds and the business loop it serves.

• What this product is going to be:
• What is wanted from it:
• What is explicitly not wanted:
• The business loop it serves:
• The constraints that shape it:
• What the sections below detail:

2. Product boundary

Draw the line around the product: who it serves, what belongs elsewhere, and what it must never expose.

• Who the product is for:
• Who it is not for:
• Workflows that belong in another product:
• What the product must never expose:
• Shared core or backend objects assumed:
• Non-goals:
• How an out-of-scope workflow is represented here instead (safe status, handoff, request state):

3. Roles and permissions

Write out every role, including two roles that differ by a single screen.

• Where role differences change navigation, actions, disabled states or empty states:
• How a role is granted, changed and removed:

4. Core workflows

List each workflow the product exists to carry, from its entry point to its final state.

• Workflow:
• Who runs it:
• Entry point:
• Steps:
• Branches:
• Failures and how they end:
• Confirmations:
• Final state:

5. Product states and data visibility

Name the states each object moves through, what moves it, and what is visible in each state to each role.

• Object:
• Its states, in order:
• What moves it from one state to the next:
• Terminal states, and what reopens them:
• What each role sees in each state:
• What is hidden in each state, and from whom:

6. Privacy and ethics rules

Say which data is sensitive and how it must be handled; this controls the interface, the data model, search, exports, backend read models and QA.

• Sensitive data held or displayed here:
• How each kind must be handled:
• What must never be shown, and to whom:
• Rules for search, filters and exports:
• Rules for what may reach the browser at all:
• Controlled exceptions, with the fields each one is allowed:
• The intake path for a request to see sensitive data:
• Retention and deletion expectations:

7. Which source wins when sources disagree

Write the order down, most authoritative first, so an agent does not overfit to an outdated document.

• What must be checked before an old backlog ticket is used:
• Who records a change to this order, and where:

8. Design baseline and acceptable drift

Name the design reference this product follows and the drift that is acceptable; the design itself arrives at Gate 3, so state here what is assumed and what must be requested.

Assumed now:

• The design reference this product follows (design system, or a named reference product standing in for one):
• Its version or location, as known today:
• What counts as non-negotiable in it:
• What counts as acceptable drift from it:
• Where the prototype and the front end must draw on the same reference:

To request from Design Ops:

• The components and their states:
• The tokens and the rules for using them:
• What may be extended and what may not:
• Who maintains the system:
• An agent-readable form of the above:
• The named owner of each request, and the date the answer is needed:
• What is being followed in the meantime, and with whose agreement:

9. Functional depth

Say which flows must really work in the front-only prototype and which may stay placeholders.

• Flows that must work end to end in the front-only prototype:
• Flows that may stay placeholders, scoped on purpose:
• What each clickable surface does, where a user can click it:
• Simulated states deliberately allowed, and their limits:
• States required everywhere: empty, loading, validation error, permission-denied, confirmation, success and failure:

10. Backlog taxonomy

Keep these categories apart, so an undecided question is not coded around as if it were a defect.

11. Backend and API assumptions

Separate what this product assumes the backend already does from what has to be requested, since the contracts are obtained at Gate 4 and the connection is made at Gate 5.

Assumed now:

• Backend objects, state machines and workflow contracts assumed:
• Authentication and permission rules assumed:
• The business meaning of key fields and status values, as understood here:
• APIs believed to exist and used by these flows:
• The shape the front end's mock services will follow until the real contracts arrive:

To request from Backend and API Ops:

• The API catalog with real examples:
• Request and response shapes, errors and versioning, for each API used here:
• Confirmation of the business meaning of key fields and status values:
• Reference patterns for authentication, migrations and tests:
• A test environment with test identities and safe data:
• Read-only access to logs, errors and health, and who to reach when something breaks:
• APIs that do not exist yet, raised through the written request route:
• The named owner of each request, and the date the answer is needed:

To request from Frontend Ops, where these flows depend on it:

• The approved starter repository, its current version, its owner and how to start it:
• The API client pattern, authentication, error handling and loading states:
• The checks required on a deployable branch, and the preview or environment path:
• The named owner of each request, and the date the answer is needed:

12. Acceptance criteria

Per flow, say what has to be true before it counts as done.

• Flow:
• Works end to end, against the mock services and then against the real backend:
• Empty, loading, error and permission-denied states handled:
• Matches the design reference where that reference is non-negotiable, within the drift accepted in section 8:
• No privacy regression:
• Tests added or updated:
• Checks to run before finishing (typecheck, lint, tests, build, walk the flow in a browser):
• Memory and journal updated when product behaviour, architecture, a stakeholder decision or future reasoning changed:

13. The QA contract

Say how this product gets checked, so the check is not invented at the end.

• Personas to test:
• Role-based privacy checks:
• Requirements derived from transcripts:
• Regression flows:
• Validation commands:
• Expected report format:
• Severity meanings in use, and when defects start being tracked rather than fixed as they appear:

14. Open decisions

One row per decision: its alignment question states what one source says, what the other says and the product risk of choosing wrong; who decides is a person, not a team.

Text licensed CC BY 4.0. Code MIT.