dawka
Sign inCreate a document
← All templates

Template preview · Software

Product requirements document

Align a product decision around a testable customer outcome.

A decision-ready PRD for a bounded product change.

Sample purpose

Align a product decision around a testable customer outcome.

Audience: Product manager, Product designer
Structure
4 sections
Criteria
13
Sources
9
Watches
5
Default approach
Review first
See the sample

Set the purpose first. Then change every section, criterion, and agent setting before anything runs.

Fictional sample

Structure and criteria

Sample content shows the shape of a useful document. Copying it is optional.

  1. 01

    Problem and outcome

    Anchor the work in a customer problem and measurable outcome.

    Review first

    Criteria

    • Names one customer segment and the friction it hits, such as returning weekly shoppers
    • Gives a baseline for the friction (e.g. 3 note re-entries per order) and a target with a date
    • Describes the outcome only; no UI or feature wording

    Sources

    Watches

    • Checks api.openalex.org monthly
    • Searches “online grocery checkout repeat data entry benchmark” monthly

    Agent may read api.openalex.org and search the web.

    Sample content

    Aster Lane shoppers re-enter delivery notes each weekly order. We will let returning shoppers save one preferred note and target a 15% reduction in checkout edits.

  2. 02

    Scope and exclusions

    Keep the release small enough to decide and ship.

    Review first

    Criteria

    • Every in-scope item is a testable user action, not a feature noun
    • At least two tempting features are listed as explicit exclusions (e.g. multiple addresses)
    • Each exclusion states why it waits, such as capacity or unproven demand

    Sources

    Watches

    • Follows Problem and outcome

    Sample content

    • ☑ Save one delivery note from checkout
    • ☑ Show and edit it on the next order
    • ☐ Support multiple saved addresses
  3. 03

    Requirements

    Make expected behavior evaluable by design and engineering.

    Review first

    Criteria

    • Each requirement is testable without interpretation, with limits stated (e.g. 120 characters, blank clears)
    • Every behavior has a success row and a failure or boundary row
    • At least one row names a privacy rule, such as household members not seeing the note
    • Evidence names a repeatable test, not an implementation detail

    Sources

    Watches

    • Follows Scope and exclusions

    Sample content

    IDBehaviorEvidence
    R1Signed-in shopper can save up to 120 characters.Checkout test saves and reuses note.
    R2Blank note clears preference.Next order shows empty field.
  4. 04

    Release measures

    Define how the team will evaluate the shipped change.

    Review first

    Criteria

    • Every metric has a baseline, a target and the query or dashboard that produces it
    • Includes an adoption metric and a guardrail metric (e.g. cart abandonment must not rise)
    • Names a review date and who decides whether to roll back

    Sources

    Watches

    • Follows Requirements

    Sample content

    Checkout note edits
    15% lower
    Preference save completion
    70%