The PRD template engineers actually read.

What is a PRD (product requirements document)?

A PRD is a single source of truth that defines what a product or feature will do, who it's for, and how success will be measured. It's the alignment artifact that keeps engineering, design, data, security, and leadership pointed at the same outcome — and it's the document every other downstream artifact (tickets, designs, evals) traces back to. A good PRD template captures that structure so each new feature starts from a known shape instead of a blank page.

Per Atlassian's authoritative agile-PRD reference, the PRD is the artifact that "keeps everyone aligned on what to build, who to build for, and why it matters." It's a living document — not a fixed contract — that evolves with the product.

PRD vs. MRD vs. FRD

Modern lean teams collapse MRD and PRD into a single short doc and treat the FRD as engineering-owned implementation notes — the PRD stops at the what, the FRD picks up the how.

What should be included in a PRD?

Every modern PRD includes ten core sections: overview, objective, context, assumptions, scope, requirements, design, metrics, impact, and open questions. This is the canonical structure documented in Aha!'s canonical 10-section PRD breakdown, and it maps cleanly onto how engineering, design, data, and finance read a spec.

1. 01

   Overview

   What it is, who it's for, why now.

2. 02

   Objective

   The single measurable outcome.

3. 03

   Context

   Background, prior art, related work.

4. 04

   Assumptions

   Dependencies treated as true.

5. 05

   Scope

   In and out, numbered.

6. 06

   Requirements

   Functional + non-functional.

7. 07

   Design

   Link the high-fidelity prototype.

8. 08

   Metrics

   Primary KPI plus guardrails.

9. 09

   Impact

   Revenue / retention / cost estimate.

10. 10

    Open questions

    Owner and decision date per row.

"The majority of the product spec should be the high-fidelity prototype."

The Two-Layer PRD framework

Use a Lean PRD by default; expand to a Full PRD only when one of four trigger conditions fires. The Lean PRD has six fields and fits on one screen. Each field maps cleanly to one or more Full PRD sections — so expansion is mechanical, not creative.

Pair the Lean PRD with ZeroTwo's Canvas to draft, fork multi-model outputs side-by-side, and merge the best paragraph from each into the section that needs it.

"Nailing the problem statement is the single most important step in solving any problem. It's deceptively easy to get wrong, and when done well it's a superpower of the best leaders."

The Lean PRD template — one-page, copy-paste

A Lean PRD template (also called a one-page PRD) has six fields and fits on one screen: Problem, Outcome, Solution Sketch, Non-Goals, Success Metrics, and Risks. It's the default starting shape for any new feature at a fast-moving team — including most startups, agile squads, and product-led companies.

# Lean PRD — <feature name>

## Problem
1-sentence problem statement. Who it hurts. How often. Cost today.

## Outcome
1 sentence. User-visible behavior change. Measurable.

## Solution sketch
- bullet 1 (lo-fi)
- bullet 2
- bullet 3 (≤5 total)

## Non-goals
- explicit out-of-scope item
- explicit out-of-scope item
- explicit out-of-scope item

## Success metrics
- Primary: <one metric with target + window>
- Guardrail: <metric we must not regress>
- Guardrail: <metric we must not regress>

## Risks
- highest-impact unknown → mitigation
- highest-impact unknown → mitigation
- highest-impact unknown → mitigation

# Lean PRD — Slack incident-digest bot

## Problem
On-call engineers spend ~47 min every Monday reconstructing what broke
in #incidents over the weekend. Affects 12 SREs weekly. Cost: ~9 eng-
hours/week of high-context time.

## Outcome
Every Monday 8:00 local, on-call gets a Slack DM with a ranked digest
of weekend incidents, owners, status, and remaining action items.
Triage time drops from 47 → 15 min within 90 days.

## Solution sketch
- Daemon polls #incidents on a schedule (cron in app runtime)
- Summarizes each thread with Claude Sonnet 4.5 (structured JSON)
- Groups by severity, dedupes follow-ups, ranks by unresolved-impact
- Delivers to per-user Slack DM at user-local 08:00
- Adds /digest slash command for ad-hoc replay

## Non-goals
- No incident creation or routing
- No PagerDuty integration in v1
- No automatic remediation actions

## Success metrics
- Primary: median Monday triage time ≤ 15 min by day 90 (baseline 47)
- Guardrail: ≥ 80% digest-open rate (no spam alarms)
- Guardrail: zero false-resolved incidents from auto-grouping

## Risks
- Summarization hallucination → JSON schema + 2-model self-check
- Slack rate limits on backfill → batch + token-bucket
- Timezone misroute → store IANA tz per user; default to Slack profile

The worked example reduces Monday triage time from 47 → 15 min over 90 days — a realistic, measurable outcome with a baseline anchor. Use it as a shape reference: every field is one paragraph or one bulleted block, and the whole document fits in a single Notion / Google Docs / Linear page.

The Full PRD template — 10 sections, copy-paste

A Full PRD expands the Lean six fields into ten sections detailed enough for engineering, design, security, and finance to execute against. Trigger the expansion only when one of the four conditions in Section 3 fires. Cagan's foundational Marty Cagan's foundational PRD framework is the closest legacy template, and Aha!'s 10-section guide is the canonical modern shape — the version below is the synthesis.

# Full PRD — <feature name>

## 1. Overview
2-3 sentence elevator pitch. What it is, who it's for, why now.

## 2. Objective
The single measurable outcome. Tie to an OKR or roadmap theme.

## 3. Context
Background, prior art, related work. Link the discovery docs.

## 4. Assumptions
List dependencies you're treating as true. Flag the load-bearing ones.

## 5. Scope
In scope (numbered). Out of scope (numbered).

## 6. Requirements
### 6.1 Functional
User stories: As a <role>, I can <action> so that <outcome>.
### 6.2 Non-functional
Performance, reliability, security, accessibility, observability.

## 7. Design
Link to the high-fidelity prototype. Inline the key flows. Mark open
design questions.

## 8. Metrics
Primary KPI + guardrails. Define instrumentation events and dashboards.

## 9. Impact
Estimated revenue / retention / cost impact. Confidence interval.

## 10. Open questions
Numbered list with owner + decision date.

The Full PRD is where the PRD earns its weight. Most projects never need it — but when scope, risk, or stakeholder count escalate, the extra structure is the difference between a clean sign-off and a three-week revision loop. Length grows with stakeholder count, not project size: a small project with regulatory review may need a longer PRD than a multi-team feature with a single approver.

The PRD Section × AI Model Matrix

Different PRD sections benefit from different AI models — Claude Sonnet 4.5 excels at structured problem statements and user stories, Perplexity at sourced market scans, GPT-5 at executive summaries, o-series reasoning at metric formulation, and Grok 4 at risk red-teaming. The heatmap below is our first-party recommendation based on patterns we've seen running multi-model PM workflows.

Inside ZeroTwo you can switch between Claude Sonnet 4.5 for structured docs, Perplexity for sourced research, and GPT-5 for executive summaries inside one subscription — section by section.

Score legend: deeper indigo = better fit. Excellent = first choice for that section; good = strong alternative; fair = usable but other models lead. Rows ordered by total coverage. ZeroTwo internal recommendation.

How do you write a PRD? (step-by-step)

Write a PRD in six steps: capture the problem, define the outcome, sketch the solution, list non-goals, set success metrics, and red-team the risks. Each step takes 5–10 minutes for a focused PM — an entire Lean PRD draft lands in under 45 minutes.

Per Carnegie Mellon Software Engineering Institute on software rework economics, 60–80% of software cost is rework — and more than half of that stems from misunderstood or incomplete requirements. The six-step PRD process is the cheapest possible insurance against that overrun. Engineers can later use ZeroTwo's AI for developers view to convert the Requirements section into Jira-ready tickets.

1. 01

   Capture the problem

   Write the one-sentence problem statement first. Who it hurts, how often, what it costs today. If the problem isn't crisp, every downstream section will drift.

2. 02

   Define the outcome

   Describe the user-visible behavior change in one sentence. Measurable. If you can't pick a number, you can't pick a feature.

3. 03

   Sketch the solution

   Five bullets max. Low-fidelity. The PRD is the what, not the how — leave room for design and engineering to choose the implementation.

4. 04

   List non-goals

   Three to five explicit out-of-scope items. Non-goals are how you protect timeline; every scope question gets answered before it's asked.

5. 05

   Set success metrics

   One primary metric with a target and window. Two guardrails you must not regress. Instrument before you ship.

6. 06

   Red-team the risks

   List the three highest-impact unknowns with a mitigation each. If you can't think of three, you haven't thought hard enough.

PRD anti-patterns — what to skip

The most common PRD failure modes are writing implementation details instead of requirements, treating the PRD as a contract, and skipping the success metrics. Each of these costs a team a full revision cycle — sometimes more. The five patterns below account for most of the IAG $2.24M per-project premium on weak requirements.

Is a PRD still used in agile?

Yes — most modern teams use lean PRDs alongside user stories, treating the PRD as the why and stories as the what. The legacy waterfall PRD — fixed, signed, contracted — is dead. The lean PRD is mainstream and pairs cleanly with sprint planning, dual-track discovery, and continuous delivery.

User stories live in the backlog. The PRD lives one level up: it anchors the why, defines the success metrics, and answers the scope questions before they reach the standup. When a story gets ambiguous mid-sprint, the team reaches for the PRD, not the backlog.

The cost of a bad PRD

Seven numbers from primary sources on why PRD quality compounds into project cost. Every figure links to its source.

Key takeaways

• Use the Two-Layer PRD. Default to the Lean six-field template; expand to the Full 10-section PRD only when scope, stakeholder count, or risk fires a trigger.

• Problem statement is field #1. One sentence. Who it hurts, how often, what it costs today. Lenny Rachitsky's "superpower" leverage point.

• Always include success metrics. One primary metric with a target and window, plus two guardrails. No exceptions — PMI 2025 ties this to project success directly.

• Match the model to the section. Claude for problem statements, Perplexity for market scans, GPT-5 for exec summaries, o-series for metrics, Grok for risk red-team — all swappable in ZeroTwo Canvas.

• Treat the PRD as living. Not a contract. Update it as the product evolves; if it stops being current, the source of truth moves to Slack and you lose alignment.

• Length follows stakeholders, not size. Lean PRD ≈ 400 words. Full PRD ≈ 1,500–3,000. A small project with regulatory review may need a longer PRD than a large one with a single approver.

Frequently asked

Related ZeroTwo guides

Start writing your PRD with 60+ AI models — free.

Open both templates in ZeroTwo Canvas, switch models per section, and merge the best output from each. Adjacent reading: AI for product managers.