Skip to content
PMcademy
Template

The PRD that survives contact with engineering

One page. Four sections engineers actually read before they start arguing about scope.

When you reach for it

Before a build starts, when more than one person has to build it and nobody agrees yet what done means.

  1. 1

    Problem, in one paragraph, with a number

    Grounds the document in evidence so engineering checks your data instead of trusting your judgement.

    What it asks

    What is broken, for whom, and how do you know? Use one real number.

    Filled in

    38 percent of new Sona users abandon the linked-bank step before finishing, per Ana's funnel report for August. Priya's team has 61 support tickets this month with the same phrase: "it says my bank isn't supported but it is." Both point at the same failure: our bank search returns no results for correctly spelled banks that just aren't in the top 50 by user count.

    How it goes wrong

    Writing the problem as the solution in disguise, for example "we need a redesigned bank search." That forecloses the actual best fix, which might be adding banks to the index rather than touching the UI at all.

  2. 2

    What we are building, and what we are not

    Sets the smallest version that solves the problem, and rules out the ideas that will otherwise attach themselves to it mid-sprint.

    What it asks

    Describe the smallest version that solves the problem, then list what's explicitly out of scope.

    Filled in

    We add fuzzy matching to bank search, so "chase" also matches JPMorgan Chase and typos within two characters resolve. Out of scope: adding new banks to the index (a data problem, already Ana's ticket) and redesigning the results page.

    How it goes wrong

    Leaving the non-goals section empty. Every adjacent idea then becomes "well, while we're in there," and the two week build becomes six.

  3. 3

    Acceptance criteria, each one somebody could fail

    Turns the feature into conditions a tester can actually check, instead of a feeling everyone privately defines differently.

    What it asks

    List the conditions that must be true before this ships, written so a tester could fail each one.

    Filled in

    1. Typing "chase" or "chace" returns JPMorgan Chase in the top 3 results. 2. Searching a bank not in our index returns "we don't support this bank yet," never a blank list. 3. Search returns in under 400ms at the 95th percentile, measured against last week's volume.

    How it goes wrong

    Writing criteria nobody could ever fail, like "search should feel fast and intuitive." Ask what would prove that wrong. If there's no answer, it's a mood, not a criterion, and it's exactly what a model asked to draft acceptance criteria tends to produce.

  4. 4

    Rollout and the way it fails

    Plans for the version of this that goes wrong, before launch day turns into the first time anyone thought about it.

    What it asks

    How does this reach users, and what's the plan if it's wrong?

    Filled in

    Ship behind a flag to 10 percent of new signups for 3 days. Watch the abandon rate at the linked-bank step. If it doesn't move, the fuzzy match isn't the fix, and we pull the flag instead of pushing to 100. Dev owns the flag, Ana owns the dashboard.

    How it goes wrong

    No rollback plan, so the first sign of trouble becomes a war room instead of a flag flip.

Take the whole thing

Paste into your doc
# [Feature name]: PRD

## Problem
What is broken, for whom, and how do you know?
(One paragraph. Use a real number: a metric, a ticket count, a quote.)


## Solution
What is the smallest version that solves the problem?


## Non-goals
What are we explicitly NOT building in this pass?


## Acceptance criteria
Numbered. Each one must be something a tester could fail.

1.
2.
3.

## Rollout and risk
How does this reach users? Flag, percentage, duration?


What's the rollback plan if we're wrong? Who owns pulling it?


Owner:
Target date:
More templates