prd template
A great PRD is an independent document which can set the context for anyone who reads it. It is not a boring documentation job — it is one of the most critical responsibilities a PM has.
This is the template. No download. No email gate. Copy the markdown below, paste it into Notion, Confluence, or a plain text file, and fill in your details.
What follows the template is a section-by-section explanation of why each field exists — because a template you do not understand is a template you will misuse.
The template
Copy everything between the horizontal rules below.
# PRD: [Feature Name]
**Version:** v1.0
**Author:** [Your name]
**Last updated:** [Date]
**Status:** Draft | In Review | Approved
---
## Changelog
| Version | Date | What changed | Why |
|---------|------|-------------|-----|
| v1.0 | [date] | Initial draft | — |
---
## 1. Purpose
[2-3 sentences. What problem are we solving? For whom? Why now?]
**The problem:** [One sentence describing the user pain]
**Who is affected:** [Segment of users, how many, how often]
**Why this sprint:** [What changed that makes this urgent or timely]
**Example:**
> Sellers on our marketplace currently wait 7-14 days for payouts. This causes cash flow problems for small sellers (under INR 5L monthly GMV), and 23% of churned sellers cited delayed payouts as the primary reason. We are building same-day payouts to reduce seller churn in this segment.
---
## 2. Route (Scope)
**In scope:**
- [Specific capability 1]
- [Specific capability 2]
- [Specific capability 3]
**Out of scope:**
- [What we are explicitly not building — and why, briefly]
- [Defer to later, not never]
**Assumptions:**
- [Assumption 1 — specific enough to verify]
- [Assumption 2 — specific enough to verify]
**Example:**
> **In scope:** Same-day payout for UPI-linked bank accounts, for sellers with verified KYC, for orders marked delivered and not disputed.
>
> **Out of scope:** International payouts, credit-based advances, payouts for disputed orders.
>
> **Assumptions:** Payout partner API supports batch processing of at least 500 transactions per call. If not, we fall back to sequential processing with a 2-hour SLA instead of instant.
---
## 3. Scenarios
[Use Given-When-Then for every behavior. Cover the happy path, the top 2-3 error states, and any edge case where the engineer might guess wrong.]
### Scenario 1: [Happy path name]
**Given:** [Precondition]
**And:** [Additional precondition if needed]
**When:** [Trigger]
**Then:** [System behavior]
**And:** [Additional system behavior]
### Scenario 2: [Error state name]
**Given:** [Precondition]
**When:** [Trigger]
**Then:** [System behavior]
**And:** [User-visible consequence]
### Scenario 3: [Edge case name]
**Given:** [Precondition]
**When:** [Trigger]
**Then:** [System behavior]
[Add scenarios until every ambiguous state is covered. If you are unsure whether a scenario belongs, write it. You can always cut. You cannot un-discover a missing edge case in production.]
---
## 4. Acceptance Criteria
| Criteria | Measurement | Pass condition |
|----------|-------------|---------------|
| [What "done" looks like] | [How you will measure it] | [The number or behavior that = pass] |
| [What "done" looks like] | [How you will measure it] | [The number or behavior that = pass] |
**Example:**
| Criteria | Measurement | Pass condition |
|----------|-------------|---------------|
| Payout initiated within 30 min of job trigger | Logs: payout API call timestamp vs job start | < 30 min in 99% of cases |
| Seller notification delivered after initiation | Notification service logs | < 5 min in 99% of cases |
| Failed payouts retried automatically | Retry queue depth + success rate | 1 retry after 1 hour, 100% automation |
| Payout dashboard load time | Performance test on staging | < 2s for sellers with up to 500 transactions |
---
## 5. Design References
**Figma:** [Link to the Figma file — not a screenshot, the live link]
**Status:** [Designs ready | In progress — wireframes expected by DATE | Not started]
If designs are not ready:
> "Build against scenario descriptions for now. Figma link will be added by [date]. Flag any scenario whose implementation depends on a visual layout decision."
---
## 6. Success Metrics
[The metric, the baseline, the target, and the timeframe. Not "we will track metrics." Specific numbers.]
| Metric | Baseline | Target | Timeframe |
|--------|----------|--------|-----------|
| [What we will measure] | [Current number] | [Goal] | [When we measure] |
**Example:**
| Metric | Baseline | Target | Timeframe |
|--------|----------|--------|-----------|
| Seller churn (under 5L GMV segment) | 23% quarterly | 15% quarterly | 2 quarters post-launch |
| Average payout time | 8.3 days | < 1 day | At launch |
| Seller NPS (payout-related) | 32 | 55 | 1 quarter post-launch |How to fill each section
Section 1: Purpose
The purpose section is the hardest to write well. Most PMs write too much here — market analysis, stakeholder context, historical background. That is a business case, not a purpose statement.
The purpose section answers one question: why does this work matter to the user?
If you cannot write it in three sentences, you have not finished your discovery. Go back to your user interviews. Find the sentence that explains the pain simply. That sentence is your first line.
The “Why now?” is not optional. Engineers ask this question in sprint planning, often out loud. “Why are we doing this in Q2 and not Q4?” If you cannot answer this, the team will assume the work is arbitrary. Arbitrary work gets deprioritized when things get busy.
Red flags in Section 1:
- More than three sentences before you name the user problem
- “Improve the user experience” without specifying which experience and how it is currently broken
- No mention of scale — how many users are affected, how often
Section 2: Route
The scope section is a boundary document. It exists so that when an engineer encounters an ambiguous case at 4 PM on a Friday, they can answer the question themselves without pinging you.
Two things PMs consistently get wrong here:
“Out of scope” written defensively. “We are not building dark mode.” Why are you telling me this? I was not planning to build dark mode. Only put something out of scope if there is a plausible reason someone would expect it to be in scope. “Out of scope: payouts for disputed orders” belongs here because the engineer will naturally ask about it. “Out of scope: payment for cryptocurrency” probably does not.
Assumptions written as facts. “The API supports batch processing” is a fact you hope is true. “We are assuming the API supports batch processing of 500+ transactions per call — if this is not true, the architecture changes” is an assumption. The difference is that assumptions carry a consequence if violated. Write the consequence.
Section 3: Scenarios
This is the core of the PRD. Get this section right and the rest is cleanup.
The Given-When-Then format comes from Behaviour Driven Development (BDD). The reason it works is structural: it forces you to separate preconditions (Given), triggers (When), and consequences (Then). When you write in paragraph form, these collapse together and the engineer has to parse them apart. When you write in GWT, the engineer can drop each scenario directly into a test case.
How many scenarios is enough?
Cover the happy path first. Then ask: what are the two or three most likely ways this flow breaks? What are the states that are not obvious from the happy path? Write those.
You do not need to cover every possible state. You need to cover every state where a reasonable engineer would make a different assumption than you would. The test is: “Would Vikram know what to do here without asking me?” If yes, skip it. If no, write it.
The error state test: For every “Then the system does X,” ask “What if X fails?” and then “What does the user see?” If both questions have obvious answers, you do not need a scenario. If either has an answer that requires a product decision — “do we retry silently, show an error, or send an email?” — write the scenario.
Section 4: Acceptance Criteria
Acceptance criteria translate scenarios into pass/fail tests. Every scenario should produce at least one criterion.
The column that most PMs skip is Measurement — how you will actually check this in testing. “The payout is fast” is not measurable. “Payout API call timestamp vs job start timestamp, measured in logs” tells the engineer exactly what to instrument.
If you cannot specify how something will be measured, you cannot honestly say it is an acceptance criterion. Move it to the success metrics section instead, or go back and make it specific.
Section 5: Design References
One rule: link to the live Figma, never embed a screenshot.
Screenshots go stale. A Figma link always shows the latest version. When the design changes in week two of the sprint, the engineer who pulls up the PRD sees the updated flow, not the one from three weeks ago.
If designs are not ready, say so explicitly and say what the engineer should do in the interim. “Use your best judgment” is not a direction. “Build against the scenario descriptions for now, flag any decision that requires a visual layout call” gives the engineer enough to start.
Section 6: Success Metrics
This section is for you, not for engineering. But it belongs in the PRD for two reasons.
First, it reminds the whole team what the feature is for — not just what it does mechanically. An engineer who knows the payout feature exists to reduce seller churn by 8 percentage points will make different micro-decisions than one who sees it as “build a batch job that initiates bank transfers.”
Second, it gives QA and data teams a north star. “Is this working?” is a question that gets asked in every sprint review. If your success metrics are already in the PRD, the answer is a dashboard pull, not a 45-minute meeting.
What makes a success metric real: a baseline (the number today), a target (the number after launch), and a timeframe (when you will measure). If you do not have a baseline, go find one before finalizing the PRD. If there is no data for the baseline, say so explicitly and specify how you will measure it post-launch.
When to use this vs a longer PRD
Use this 6-section template when you are writing a PRD for a single feature or capability — something an engineer could build in one to two sprints.
Use a longer format when:
- You are scoping an entire product (use one overview doc + individual 6-section PRDs per feature)
- The feature requires an architecture decision that engineering needs to document separately
- Regulatory or compliance requirements need their own section and sign-off process
The anti-pattern is using this template as a checklist and expanding every section into paragraphs. A PRD that runs 10 pages is almost always two PRDs that have not been separated yet. The act of splitting a large PRD into smaller ones forces clarity about where one capability ends and another begins.
For very large features, structure it this way:
/feature-same-day-payouts/
├── overview.md (shared Purpose + Success Metrics)
├── prd-payout-initiation.md
├── prd-bank-verification.md
├── prd-retry-and-reconciliation.md
└── prd-seller-notifications.mdThe overview holds shared context. Each PRD holds scenarios and acceptance criteria for one bounded piece. An engineer can own a single PRD. Reviews are faster. Changes to one capability do not force everyone to re-read the whole document.
Pick the next feature on your roadmap — or the one you are currently planning.
Work through the template in order. Do not skip sections. If you cannot fill a section, that is information: you have a gap in your discovery or design.
After you have filled all six sections, do this self-audit:
- Purpose check: Read your purpose section aloud. Does it tell you who is in pain, how many of them, and why this matters now? If not, rewrite it.
- Scope check: For each “In scope” item, ask: “Could an engineer misinterpret this?” For each “Out of scope” item, ask: “Would anyone realistically expect this to be in?” Remove the ones that answer no.
- Scenario check: Count your scenarios. If you have only one (the happy path), you have not finished. Find at least two error states.
- Acceptance criteria check: Read each criterion. Can it be tested? Can it be logged? If you wrote a criterion with the word “appropriate,” “smooth,” or “good,” rewrite it with a number.
- Send it to an engineer before the sprint. Ask: “What would you need to know that is not in this document?” Their first question tells you what to add. Their second tells you what to clarify.
You are three days before sprint start. You have drafted the PRD for a checkout redesign. The scenarios cover adding to cart, applying a coupon, and completing payment. Your backend engineer, Ananya, messages you: 'What happens when a coupon is applied to an item that goes out of stock between cart and checkout? The coupon is already validated. Do we honour it on an equivalent item, remove it, or hold the order?' You did not write this scenario.
You have three days. The sprint starts Monday. This is Friday afternoon.
your path
Related pages
- Writing PRDs That Engineers Read — the theory behind this template: why each section exists, anti-patterns, and how to handle large features
- User Stories — the Given-When-Then format in depth, and when to use user stories vs scenarios
- Working with Engineering — how to hand off a PRD so the sprint starts without a 45-minute kickoff meeting
- Measuring Outcomes — how to build your Section 6 success metrics from the right data