Prd Templates

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

What is a PRD?

A PRD is the primary document for defining what to build and why. It serves as:

• Alignment tool: Gets everyone on the same page
• Decision artifact: Documents what and why
• Communication vehicle: Shares vision across teams
• Execution blueprint: Guides building and launch
• Historical record: Captures rationale for future decisions

A great PRD answers:

• What are we building?
• Why are we building it?
• Who is it for?
• How will we know it's successful?
• What are we explicitly NOT building?

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:

1. 80% of current usage is web
2. Mobile requires 3x development time
3. We can validate core value on web first
4. 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:

1. Draft 1-page overview (problem, solution, metrics, scope)
2. Validate direction with quick user feedback or research
3. Refine based on insights
4. 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:

1. Step away for 24 hours
2. Re-read with fresh eyes
3. Ask: Would Claude Code understand this?
4. Ask: Would a new teammate understand this?
5. 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

PRD Workflow

1. Research & Discovery

• Customer interviews
• Data analysis
• Competitive research
• Problem validation

2. Pre-PRD Validation (1-2 days)

• Draft 1-pager
• Validate with user feedback or research
• Iterate on direction

3. Write PRD (1-3 days)

• Choose appropriate template
• Document problem, solution, requirements
• Add mockups and user flows
• Define success metrics

4. Review & Iterate (1-2 days)

• Self-review after 24 hours
• Peer review if available
• Refine for clarity
• Finalize

5. Development

• Update PRD as decisions made
• Regular demos and check-ins
• Scope change management

6. Launch & Learn

• Execute launch plan
• Track success metrics
• Document results
• Share learnings

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

Learning More

In this skill:

• See templates in assets/ for ready-to-use formats
• See references/prd-writing-guide.md for writing techniques

Books:

• "Inspired" by Marty Cagan
• "Escaping the Build Trap" by Melissa Perri
• "The Lean Product Playbook" by Dan Olsen

Key Principle: The best PRD is the one that gets your team aligned and building the right thing. Use these templates as starting points and adapt to your context.