prd-templates

What this skill does

# 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**:

```markdown
## 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)

```markdown
## 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** - All evidence must cite source:

- "Synthesized from 6 interviews (research-ops, Oct 2025)"
- "From competitive-landscape.md (created Stage 1, validated Oct 2025)"
- "User-provided: 12 support tickets over 3 months"
- "WebSearch: Current competitor analysis (Oct 2025)"

**Template examples show FORMAT only**:

- Examples in templates demonstrate structure, not content to copy
- Never copy example numbers, quotes, or data as if they were real
- Replace with actual data or omit section

**Check context first**:

- Before asking user, check if `competitive-landscape.md` or `customer-segments.md` contain feature-relevant data
- If context files exist but don't cover this feature, ask user if new research is needed
- Route to specialist agents (market-analyst, research-ops) when beneficial

---

### 3. Proposed Solution

**Purpose**: Paint picture of what we're building

**Include**:

- High-level description (what and why)
- Key capabilities (what it can do)
- User experience (how users interact)
- Value proposition (why users care)

**Show, don't just tell**:

- User scenarios (storytelling)
- User flows (step-by-step)
- Mockups (visual representation)
- Concrete examples

---

### 4. Requirements

**Purpose**: Define what to build

**Functional requirements**:

- Number them (REQ-001, REQ-002)
- Use active voice ("System shall...")
- Be specific and testable
- Include acceptance criteria

**Non-functional requirements**:

- Performance (speed, latency, throughput)
- Security (authentication, authorization, encryption)
- Scalability (load handling, growth capacity)
- Accessibility (WCAG compliance)
- Reliability (uptime, error rates)

**Prioritize ruthlessly**:

- **P0/Must**: Required for launch
- **P1/Should**: Important, can defer if needed
- **P2/Nice-to-have**: Future consideration

---

### 5. Out of Scope

**Purpose**: Prevent scope creep and maintain focus

**Why it matters**:

- Explicitly stating what we're NOT doing prevents scope creep mid-development
- Helps prioritization discussions
- Maintains focus on core value

**Include**:

- Features/capabilities explicitly excluded
- Brief rationale for each
- Note if it's "never" or "not now"

---

### 6. Launch Plan

**Purpose**: Define rollout strategy

**Include**:

- Rollout approach (phased, beta, full launch)
- Target segments or cohorts
- Success validation approach
- Go/No-Go criteria

---

## PRD Writing Bes