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 coordination

• 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)

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)

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 Best Practices

Start with Why

Most PRDs start with "what". Great PRDs start with "why".

Poor order: "We're building guest checkout. Users will be able to..." Good order: "Users abandon checkout because account creation adds friction (45% rate). To solve this, we're building..."

Be Specific and Measurable

Vague language kills PRDs.

Vague → Specific:

• "Fast" → "Page load < 2 seconds (p95)"

• "Many users" → "35% of daily active users"

• "Improve engagement" → "Increase session length from 3min to 5min"

• "Easy to use" → "New users complete key task in < 5 minutes without help"

Write for Clarity

Clear documentation serves multiple purposes:

For implementation: Clear requirements, acceptance criteria, non-functional requirements For yourself: User scenarios, flows, edge cases, decisions and rationale For users: Target audience, value proposition, differentiation

Document Decisions and Rationale

Future you needs to know why decisions were made.

Example: "We're starting with web only (no mobile app) because:

• 80% of current usage is web

• Mobile requires 3x development time

• We can validate core value on web first

• Mobile can launch in Q2 based on learnings"

Use Visuals

Tables for comparisons, diagrams for flows, mockups for UI, charts for data.

A picture is worth a thousand words of requirements.

Common PRD Mistakes to Avoid

❌ Solutionizing too early: Start with problem, not "we need to build..." ❌ Vague requirements: "Fast" instead of "< 2 seconds" ❌ Missing acceptance criteria: No clear definition of "done" ❌ No prioritization: Everything is P0 ❌ Scope creep: Adding "just one more thing" repeatedly ❌ Missing success metrics: No way to measure if it worked ❌ No evidence: "I think users want..." instead of data ❌ Too long: 20-page PRDs nobody reads

Writing Clear PRDs for Solo Builders

For solo developers and small teams, PRDs serve as thinking documents and future reference.

Start with a Brief

Before writing full PRD:

• Draft 1-page overview (problem, solution, metrics, scope)

• Validate direction with quick user feedback or research

• Refine based on insights

• Then write full PRD

Why this works:

• Low time investment if direction is wrong

• Easier to course-correct early

• Validates problem before deep specification

• Prevents over-planning before validation

Self-Review Process

Before finalizing:

• Step away for 24 hours

• Re-read with fresh eyes

• Ask: Would Claude Code understand this?

• Ask: Would a new teammate understand this?

• Update for clarity

Review checklist:

• Problem clearly stated with evidence

• Success metrics specific and measurable

• Requirements testable and complete

• Out of scope explicitly documented

• Decisions and rationale captured

PRD Review Checklist

Before submitting your PRD, verify:

Content Completeness:

• Problem clearly defined with evidence

• Goals and success metrics specified

• Solution described with user flows

• Requirements listed with acceptance criteria

• Out of scope explicitly stated

• Launch plan defined

Quality:

• Well-structured and easy to navigate

• Clear, concise language

• Specific and measurable requirements

• Technical feasibility considered

• Risks identified with mitigation

For full checklist: See assets/prd-review-checklist.md

Ready-to-Use Templates

We provide complete, copy-paste-ready templates:

In assets/ :

• lean-prd-template.md: Quick 1-2 page format for small features

• comprehensive-prd-template.md: Standard 3-5 page format for most features

• amazon-pr-faq-template.md: Working backwards from customer experience

• google-prd-template.md: Data-driven, objectives-focused format

• prd-review-checklist.md: Quality checklist before submission

In references/ :

• prd-writing-guide.md: Deep dive on writing techniques, section-by-section guidance, common mistakes

When NOT to Write a PRD

PRDs aren't always needed:

Skip for:

• Trivial changes (copy tweaks, simple bug fixes)

• Well-understood maintenance work

• One-person side projects

• Throwaway prototypes

Use instead:

• Quick Slack/email for trivial changes

• GitHub issue for bug fixes

• Lightweight spec for small projects

PRDs make sense when:

• Significant time investment (>1 week)

• Complex feature requiring clear specification

• Need documentation for future reference

• Building with AI coding tools like Claude Code

Adapting Templates

Templates are starting points, not rigid structures.

Adapt based on:

• Company culture (startup vs enterprise)

• Product maturity (new product vs established)

• Team size (2 people vs 20)

• Audience (internal tool vs customer-facing)

Good adaptation:

• Removing sections that don't apply

• Adding sections for specific context

• Adjusting level of detail

• Changing format/structure

Bad adaptation:

• Removing problem statement (always needed)

• Skipping success metrics (always needed)

• No out-of-scope (always needed)

• Ignoring audience needs

Related Skills

• user-story-templates: For user story format and acceptance criteria

• specification-techniques: General spec writing best practices

• go-to-market-playbooks: For launch planning