Standard PRD Template

A Standard PRD covers a feature with enough surface area that alignment cannot happen in a Slack thread: multiple user stories, a real UX flow, dependencies on other teams, and enough ambiguity that someone will guess wrong if it is not written down.

When you need one

Write one when a feature touches more than one team, changes an existing flow, or carries enough risk that a wrong guess costs weeks instead of hours. If it fits in three bullet points and one engineer already knows how to build it, use the Lean PRD template instead — this one will bury that simplicity under sections it does not need. The signal is dependency count: the moment another team's roadmap has to move, you need what Lean does not have — dependency mapping, business rules, a real launch plan.

The template

# [Feature name] — PRD
Owner: [name] · Status: [draft/review/approved] · Last updated: [date]

## TL;DR
[2-3 sentences: what this is, who it is for, why now.]

## What if not built
[The cost of not doing this, in a number or a named consequence — not "nothing happens."]

## Problem alignment
Statement: [the problem, as a user or business outcome, not a missing feature]
Why it matters: [who is hurt, and what breaks if it stays unsolved]
Evidence: [research, tickets, data — cite the source]
Frequency & severity: [how often, how bad, for how many people]
Target population: [the specific segment, not "all users"]

## Opportunity & strategic fit
[Why this, why now, and which team or company goal it moves.]

## Strategic alternatives
| Option | Pros | Cons | Decision |
| --- | --- | --- | --- |
| [A] | | | Rejected — [why] |
| [B] | | | Rejected — [why] |
| [C — recommended] | | | Chosen |

Recommendation: [option], because [the deciding criterion, not a list of benefits].

## User stories
- As a [role], I can [action], so that [outcome].
- As a [role], I can [action], so that [outcome].
- As a [role], I can [action], so that [outcome].

## Product narrative
Before: [how the user works around this today]
After: [what changes once this ships]
Operational change: [what support, sales, or ops now has to do differently]

## Goals
[2-4 outcomes this feature is accountable for, each tied to a metric below.]

## Success metrics
| Metric | Baseline | Target | Why this metric |
| --- | --- | --- | --- |
| [metric] | [current value, or [TBD: reason, date]] | [target by date] | [why it proves the goal] |

## Non-goals
- [Explicitly out of scope, so nobody assumes it is included.]

## Scope
In scope: [list]
Out of scope: [list]
Assumptions: [what you are taking as given, and the risk if it is wrong]

## UX flow
[Screen-by-screen or state-by-state path, including empty, error, and edge states — link the design file rather than re-describing every screen here.]

## Key features
- [Feature 1 — one line on what it does]
- [Feature 2 — one line on what it does]
- [Feature 3 — one line on what it does]

## Business rules
- BR-1: [rule, stated as a condition and an outcome]
- BR-2: [rule, stated as a condition and an outcome]

## Dependency mapping
| Dependency | Owner | Status | Needed by |
| --- | --- | --- | --- |
| [team/system] | [owner] | [TBD: reason, date] | [date] |

## Technical requirements
Functional: [what the system must do]
Non-functional: [performance, availability, scale — with numbers]
Integrations: [systems this touches]

## QA scenarios
- Happy path: [scenario]
- Error state: [scenario]
- Stress / scale: [scenario]
- Cross-platform: [scenario]

## Security & privacy
[Data handled, retention, access control, and anything regulatory — name the regulation if one applies.]

## Instrumentation plan
| Event (noun_verb) | Trigger | Mapped metric | Client/server | Destination |
| --- | --- | --- | --- | --- |
| [e.g. view_saved] | [user action] | [which success metric] | [client/server] | [analytics destination] |

## Constraints
[Time, budget, headcount, or platform limits that shaped the design.]

## Risks & dependencies
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| [risk 1] | [H/M/L] | [impact] | [mitigation] |
| [risk 2] | [H/M/L] | [impact] | [mitigation] |
| [risk 3] | [H/M/L] | [impact] | [mitigation] |

## Launch plan
Phase 1 — [name]: [scope]. Exit criteria: [measurable condition to move to phase 2].
Phase 2 — [name]: [scope]. Exit criteria: [measurable condition to call it done].

## Operational checklist
- [ ] [Support team briefed / macro written]
- [ ] [Feature flag / kill switch in place]
- [ ] [Docs or help center updated]

## Open questions
- [Question] — Owner: [name] — Needed by: [date]

## Technical design annex
[Link to the architecture doc, or inline detail on data model, API contracts, and edge cases too deep for the main body.]

Section by section

TL;DR and what if not built

These two lines are the only part most stakeholders read by default — your own verdict, written before the reviewer forms theirs.

Problem alignment, opportunity, and strategic alternatives

Three sections, one argument: the problem, why it is worth solving now, and proof you considered more than one way to solve it.

User stories, product narrative, and goals

The stories say who benefits, the narrative says what changes, and the goals tie both to something you will be held to.

Success metrics

Every other section is trying to earn this one. A goal without a metric here is an opinion; a metric without a baseline is a guess dressed as a target.

Non-goals and scope

Non-goals stop scope creep before it starts; scope draws the line and names what you are assuming on the other side of it.

UX flow and key features

The flow is the product; the feature list is its table of contents. A reviewer checks that every feature actually shows up somewhere in the flow.

Business rules and dependency mapping

Rules with IDs are the ones engineering can cite in a ticket. Dependencies are what quietly move your launch date without anyone updating this document.

QA scenarios, security & privacy, and instrumentation plan

Three ways this feature gets tested: by QA, by a security reviewer, and by whether the data behind the metric above actually gets captured.

Constraints and risks & dependencies

Constraints are the limits that shaped what you built; risks are what could still go wrong inside them. Both are more useful named than implied.

Launch plan, operational checklist, open questions, and technical design annex

The closing sections are logistics, not argument: how it ships, who needs to be ready, and what is unresolved. No pass maps here directly — treat it as the reviewer's check that the document is finishable, not just well-argued.

Worked example

Here are two sections from a mid-size feature: recurring task templates for a project-tracking tool used by operations teams.

Problem alignment

Statement: Ops teams recreate the same 8-15 step checklist every time a recurring process runs (monthly close, vendor onboarding), and nothing remembers the previous run. Why it matters: Recreating a checklist by hand takes 20-35 minutes and is where steps get skipped — three of the last four onboarding audits flagged a missed step traced to a rebuilt checklist. Evidence: 340 "recurring" checklists were rebuilt from scratch at least twice in Q2, per usage logs; 12 support tickets in the same period ask for a copy/duplicate option. Frequency & severity: Weekly for finance ops, monthly for vendor onboarding — roughly 900 of the workspace's 3,100 weekly active teams. Target population: Teams that have run the same named checklist 3+ times in 90 days.

Success metrics

| Metric | Baseline | Target | Why this metric | | --- | --- | --- | --- | | Checklists created from a template vs. from scratch | 0% (feature does not exist) | 55% of recurring-tagged checklists by 8 weeks post-launch | Directly measures adoption of the fix, not just usage of the button | | Steps skipped per audit on templated checklists | [TBD: pulling last two quarters from the audit tool, ready 19 Aug] | 1 or fewer per audit | This is the actual problem — checklist creation is a proxy |

Both sections show what a reviewer wants: real evidence and a metric tied back to the stated problem, not a generic engagement number.

The deliberate weakness: the target of "55% by 8 weeks" has no stated reason why 55 rather than 30 or 80. A target with no rationale gets treated as no target, since nobody can tell if it is ambitious or arbitrary. The fix is to say where it came from: [TBD: benchmark against "save as default" adoption in the reporting module, currently 61%, confirm comparable cohort by 15 Aug]. A number with a stated comparison survives review; one that appears from nowhere does not.

Common mistakes

• All 25 sections, uniform depth. A one-line UX flow next to a three-paragraph annex is not thoroughness, it is a document nobody has edited. Mark "not applicable" explicitly where a section does not apply.
• Business rules with no ID. Six weeks later, nobody can reference "the rule about proration" in a standup.
• Dependency rows with a team name and nothing else. "Waiting on Platform" is not a status. It needs an owner and a date, or [TBD: reason, date].
• A launch plan with dates but no exit criteria. "Phase 1 ends March 3" tells nobody what has to be true for phase 2 to start.

Run it through a review

The rubric above is a subset of what Thinkr's critique runs against a full spec — eleven passes, scored across five dimensions, with findings landed on the line they concern rather than summarized at the end. Before this goes to engineering, it is worth checking which section comes back first.