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
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.mdorcustomer-segments.mdcontain 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