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.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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
: 4-8 hours to write
: 3-5 pages
: Cross-functional team
Effort
Length
Audience
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
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)
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.
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.
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
Troubleshooting
"My PRD is 20 pages and nobody reads it": You're writing a comprehensive PRD when you need a lean one. Match template to context: lean PRD for small features, comprehensive for cross-team initiatives. If in doubt, start lean and expand only the sections that need depth.
"Stakeholders keep adding scope after the PRD is approved": Your Out of Scope section is either missing or too vague. List specific things you are NOT building. Scope changes after approval require a PRD amendment with re-approval.
"I don't have data for the Evidence section": Skip it. The Evidence section is optional. A clear problem statement from user perspective is more valuable than fabricated metrics. Flag unknowns as assumptions to validate post-launch.
Related Skills
user-story-templates: For user story format and acceptance criteria
specification-techniques: General spec writing best practices
