PRD template · PRD Template

Read the same template used in the editor, with questions to help you make each decision. The completed example PRD is a separate reference, not a format you need to follow.

Choose the format that matches the handoff:

Markdown: Editable plain text for source control, issue descriptions, or handing to an agent.
Word (.docx): Editable in a word processor for collaborators who review or comment there.
PDF: Fixed-layout reading, sharing, printing, or approval where editing is not expected.
Draft backup: The editor’s lossless .prd.json reopen/import format for exact in-progress fields; use Download draft backup under Draft controls. It is not a finished document export.

Use these sections as a starting point. Change, remove, reorder, or skip them when they do not apply. Replace the placeholders you keep with your own decisions.

Product summary and desired outcome

Summarize the product, who it is for, and the outcome this work should produce.

What will exist when this work is complete?
What change should the product create for its users?

## Product summary and desired outcome

{Product summary and desired outcome}

Context and problem

Describe the current situation, the problem to solve, and the evidence or assumptions that explain why it matters now.

What happens today?
What pain, risk, or opportunity makes this work worthwhile?

## Context and problem

{Context and problem}

Goals and success measures

State the goals and the observable measures that will show whether the product achieved them.

Which outcomes should improve?
What signals, targets, or timeframes define success?

## Goals and success measures

{Goals and success measures}

Users and important use cases

Identify the users who matter for this work and the important tasks or journeys each needs to complete.

Who uses, administers, or is affected by the product?
Which use cases must work at launch?

## Users and important use cases

{Users and important use cases}

Scope and non-goals

Define what this work includes, what it deliberately excludes, and where its boundaries sit.

Which capabilities belong in this release?
Which plausible additions should not be built?

## Scope and non-goals

{Scope and non-goals}

User experience

Describe the screens, interactions, states, responsive behavior, and accessibility decisions users should experience.

What do users see and do from start to finish?
How should loading, empty, error, success, and small-screen states behave?

## User experience

{User experience}

Functional requirements

List observable product behavior, using exact labels, values, ordering, limits, and fallback rules where those details matter.

What can a person or automated test observe?
Which strings, numbers, precedence rules, or edge cases must be exact?

## Functional requirements

{Functional requirements}

Data, APIs, and external integrations

Specify the data the product reads or writes, its API contracts, and each external system interaction.

What data is stored, generated, imported, or shared?
How should integration failures, limits, and retries behave?

## Data, APIs, and external integrations

{Data, APIs, and external integrations}

Constraints and fixed implementation decisions

Record the constraints and implementation choices that are fixed, plus alternatives that remain open or are ruled out.

Which technology, compatibility, budget, timing, or operating constraints apply?
Which decisions must not drift during implementation?

## Constraints and fixed implementation decisions

{Constraints and fixed implementation decisions}

Security, privacy, identity, and permissions

Define applicable security, privacy, identity, permission, and trust-boundary decisions, including how untrusted input is handled.

Who may see or change each resource?
Where does trusted data end and untrusted data begin?

## Security, privacy, identity, and permissions

{Security, privacy, identity, and permissions}

Acceptance criteria and failure recovery

Write pass-or-fail acceptance criteria and define expected behavior when operations fail, time out, or need recovery.

What must be true for this work to be accepted?
What should users see and do after a failure?

## Acceptance criteria and failure recovery

{Acceptance criteria and failure recovery}

Validation plan and definition of done

Name the runnable commands, end-to-end journeys, and other evidence that define a complete and validated result.

Which checks prove individual requirements?
Which complete journeys, environments, or restart checks must pass?

## Validation plan and definition of done

{Validation plan and definition of done}