/prd-templates

name: prd-templates
description: Master PRD templates including problem statements, success metrics, requirements, user stories, and technical considerations. Use when writing PRDs, documenting features, defining requirements, communicating product decisions, or creating feature specifications. Covers PRD structure, writing best practices, and templates from Amazon, Google, and high-performing PM teams.

PRD Templates

Comprehensive PRD (Product Requirements Document) templates and frameworks for documenting product requirements and driving successful execution.

When to Use This Skill

**Auto-loaded by agents**:

• `requirements-engineer` - For Amazon PR/FAQ, comprehensive PRD, and lean PRD templates

**Use when you need**:

• Writing product requirements documents
• Documenting feature specifications
• Aligning cross-functional teams
• Communicating product decisions
• Creating feature briefs
• Defining project scope
• Establishing success metrics

When to Use Which Template

We provide 4 ready-to-use PRD templates for different contexts:

Lean PRD

**Use for**: Small features, enhancements, bug fixes **Effort**: 1-2 hours to write **Length**: 1-2 pages **Audience**: Engineering team

**Best for**:

• Features requiring < 1 week of development
• Well-understood problems with clear solutions
• Internal tools or quick experiments
• Low cross-functional complexity

**Template**: `assets/lean-prd-template.md`

---

Comprehensive PRD (Standard)

**Use for**: Most features, new capabilities, significant enhancements **Effort**: 4-8 hours to write **Length**: 3-5 pages **Audience**: Cross-functional team

**Best for**:

• Standard features (1-4 weeks of development)
• Customer-facing changes
• Features requiring cross-functional alignment
• New capabilities or platform features

**Template**: `assets/comprehensive-prd-template.md`

---

Amazon PR/FAQ

**Use for**: New products, major bets, working backwards from customer **Effort**: 8-16 hours to write **Length**: 3-6 pages (1-2 page PR + 2-4 pages FAQ) **Audience**: Solo dev or small team (customer-first thinking)

**Best for**:

• New products or product lines
• Major strategic initiatives
• Customer-facing launches
• Working backwards from customer experience
• Pitching to executives or board

**Unique approach**: Start with the press release announcing the finished product, then answer hard questions. Forces customer-first thinking and addresses risks early.

**Template**: `assets/amazon-pr-faq-template.md`

---

Google PRD

**Use for**: Data-driven products, cross-team initiatives, scale-focused **Effort**: 8-12 hours to write **Length**: 5-10 pages **Audience**: Cross-functional teams, leadership

**Best for**:

• Products where metrics and scale matter from day one
• Cross-team initiatives requiring tight coordination
• Features with significant technical complexity
• Initiatives requiring executive approval

**Unique approach**: Emphasizes objectives (goals and non-goals), user benefits, and clear success criteria with measurable targets.

**Template**: `assets/google-prd-template.md`

---

Core PRD Components

Regardless of template, great PRDs include these key elements:

1. Problem Statement

**Purpose**: Validate this is worth solving

**Include**:

• User pain point (describe from their perspective)
• Who experiences it (user segment, % affected)
• Impact if not solved (business + customer cost)
• Evidence (research, data, quotes)

**Template**:

## Problem Statement

**Who**: [user segment, % affected]
**Pain**: [describe from their perspective]
**Impact**: [business + customer cost if unsolved]
**Evidence**: [research, data, quotes]

**Good example**: "Small business owners spend 5+ hours per week manually creating invoices, leading to delayed payments and cash flow issues. 68% of survey respondents cited invoicing as their #1 time sink. Current tools require accounting expertise most small business owners lack."

**Bad example**: "We need an invoicing feature because competitors have one."

---

2. Goals & Success Criteria

**Purpose**: Define what winning looks like

**Include**:

• Business goals (revenue, efficiency, market position)
• User goals (what users can newly accomplish)
• Success metrics with baselines and targets
• Timeline for measurement (30/60/90 days)

## Success Criteria

| Metric | Baseline | Target | Timeline |
|--------|----------|--------|----------|
| [metric] | [current] | [goal] | [30/60/90d] |

**Make metrics SMART**:

• **Specific**: "Increase DAU" not "grow users"
• **Measurable**: Quantifiable number
• **Achievable**: Stretch but realistic
• **Relevant**: Ties to business goals
• **Time-bound**: Clear deadline

**Track both**:

• **Leading metrics**: Predict success (activation, engagement)
• **Lagging metrics**: Measure outcome (revenue, retention)

---

2.5. Evidence (Optional Section)

**Purpose**: Validate the problem with data

**CRITICAL - Never Fabricate Evidence**:

PRDs are specifications Claude Code uses to build features. Fabricated evidence leads to wrong implementations. All included evidence MUST be from real sources.

**Include Evidence section ONLY when you have**:

• Real user research (synthesized by research-ops or user-provided)
• Competitive analysis (from competitive-landscape.md or market-analyst)
• Support data (ticket volumes, customer quotes from user)
• Analytics data (user-provided metrics and usage patterns)

**If no evidence exists**: Omit the Evidence section entirely. Do not use placeholders or template examples as if they were real data.

**Valid evidence sources**:

• Context files: `competitive-landscape.md` (Stage 1), `customer-segments.md` (Stage 2)
• Specialist agents: research-ops synthesis, market-analyst competitive research
• User-provided: Support tickets, analytics, surveys, interview transcripts
• WebSearch: Current market data, competitor information

**Attribution required*