zhongwei/gh-jamesrochabrun-skills-prd-generator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d66fde9999eefbed15591acd11a5571c962f5f64
gh-jamesrochabrun-skills-pr…/skills/prd-generator/references/prd_template.md
Zhongwei Li d66fde9999 Initial commit
2025-11-29 18:49:39 +08:00

13 KiB
Raw Blame History

Product Requirements Document Template

This template provides a comprehensive structure for creating Product Requirements Documents (PRDs). Adapt sections based on your needs and project scope.

Document Header

Product/Feature Name: [Name] Status: [Draft | In Review | Approved] Author: [Your Name] Stakeholders: [List key stakeholders] Date Created: [YYYY-MM-DD] Last Updated: [YYYY-MM-DD] Version: [1.0]

Executive Summary

One-liner: [Single sentence describing the product/feature]

Overview: [2-3 paragraph summary of what you're building, why, and expected impact]

Quick Facts:

  • Target Users: [Primary user segment]
  • Problem Solved: [Core problem being addressed]
  • Key Metric: [Primary success metric]
  • Target Launch: [Date or Quarter]

Table of Contents

  1. Problem Statement
  2. Goals & Objectives
  3. User Personas
  4. User Stories & Requirements
  5. Success Metrics
  6. Scope
  7. Technical Considerations
  8. Design & UX Requirements
  9. Timeline & Milestones
  10. Risks & Mitigation
  11. Dependencies & Assumptions
  12. Open Questions
  13. Stakeholder Sign-Off

Problem Statement

The Problem

[Clearly articulate the problem you're solving. What pain point exists today?]

Current State

[Describe how users currently handle this problem, including workarounds]

Impact

User Impact:

  • [How this affects users]
  • [Quantify if possible: "Users spend 30 minutes daily on workarounds"]

Business Impact:

  • [How this affects the business]
  • [Include metrics: "Costs us $X in support tickets monthly"]

Why Now?

[Explain the urgency or strategic importance of solving this now]

Goals & Objectives

Business Goals

  1. [Goal 1]: [Description and expected impact]
  2. [Goal 2]: [Description and expected impact]
  3. [Goal 3]: [Description and expected impact]

User Goals

  1. [Goal 1]: [What users want to achieve]
  2. [Goal 2]: [What users want to achieve]
  3. [Goal 3]: [What users want to achieve]

Non-Goals

[What we're explicitly NOT trying to achieve with this effort]

User Personas

Primary Persona: [Name/Type]

Demographics:

  • Age range: [Range]
  • Role/Title: [Role]
  • Tech savviness: [Low/Medium/High]
  • Location: [Geographic info if relevant]

Behaviors:

  • [Key behavior pattern 1]
  • [Key behavior pattern 2]
  • [Key behavior pattern 3]

Needs & Motivations:

  • [What they need to accomplish]
  • [What drives their decision-making]

Pain Points:

  • [Current frustration 1]
  • [Current frustration 2]
  • [Current frustration 3]

Quote: "[Verbatim user quote that captures their perspective]"

Secondary Persona: [Name/Type]

[Repeat structure as needed for additional personas]

User Stories & Requirements

Epic: [Epic Name]

Must-Have Stories (P0)

Story 1: [Feature Name]

User Story:

As a [user type],
I want to [perform action],
So that [achieve benefit/value].

Acceptance Criteria:

  • Given [context], when [action], then [expected outcome]
  • Given [context], when [action], then [expected outcome]
  • Edge case: [Specific scenario]

Priority: Must Have (P0) Effort: [T-shirt size: XS/S/M/L/XL] Dependencies: [List any dependencies]

Story 2: [Feature Name]

[Repeat structure]

Should-Have Stories (P1)

[List P1 stories using same format]

Nice-to-Have Stories (P2)

[List P2 stories using same format]

Functional Requirements

Req ID Description Priority Status
FR-001 [Requirement description] Must Have Open
FR-002 [Requirement description] Should Have Open
FR-003 [Requirement description] Nice to Have Open

Non-Functional Requirements

Req ID Category Description Target
NFR-001 Performance Page load time < 2 seconds
NFR-002 Availability Uptime SLA 99.9%
NFR-003 Security Data encryption AES-256
NFR-004 Accessibility WCAG compliance Level AA

Success Metrics

Key Performance Indicators (KPIs)

Primary Metric (North Star)

Metric: [Your North Star Metric] Definition: [How it's calculated] Current Baseline: [Current value] Target: [Target value by launch + X months] Why This Metric: [Why this measures success]

Secondary Metrics

Metric Current Target Timeframe
[Metric 1] [Value] [Value] [When]
[Metric 2] [Value] [Value] [When]
[Metric 3] [Value] [Value] [When]

Measurement Framework

Framework Used: [AARRR / HEART / Custom]

Acquisition:

  • [Metric and target]

Activation:

  • [Metric and target]

Retention:

  • [Metric and target]

Revenue:

  • [Metric and target]

Referral:

  • [Metric and target]

Analytics Implementation

Events to Track:

  • [event_name_1] - [When triggered]
  • [event_name_2] - [When triggered]
  • [event_name_3] - [When triggered]

Dashboards:

  • [Link to primary dashboard]
  • [Link to secondary dashboard]

Scope

In Scope

Phase 1 (MVP):

  • [Feature/capability 1]
  • [Feature/capability 2]
  • [Feature/capability 3]

Phase 2 (Post-MVP):

  • [Feature/capability 1]
  • [Feature/capability 2]

Out of Scope

Explicitly Excluded:

  • [Item 1 and why it's excluded]
  • [Item 2 and why it's excluded]
  • [Item 3 and why it's excluded]

Future Considerations

Potential Future Enhancements:

  • [Enhancement 1]
  • [Enhancement 2]
  • [Enhancement 3]

Technical Considerations

High-Level Architecture

[Describe the technical approach, architecture diagram link, or key architectural decisions]

Technology Stack

Frontend:

  • [Framework/library]
  • [Key dependencies]

Backend:

  • [Language/framework]
  • [Key services]

Infrastructure:

  • [Hosting platform]
  • [Database]
  • [Caching layer]

API Requirements

New Endpoints:

  • GET /api/v1/[endpoint] - [Description]
  • POST /api/v1/[endpoint] - [Description]
  • PUT /api/v1/[endpoint] - [Description]

External APIs:

  • [Third-party API 1]
  • [Third-party API 2]

Security Requirements

  • Authentication: [Method: JWT, OAuth, etc.]
  • Authorization: [RBAC, ABAC, etc.]
  • Data Encryption: [At rest and in transit]
  • Compliance: [GDPR, HIPAA, SOC 2, etc.]
  • Rate Limiting: [Limits and throttling strategy]

Performance Requirements

  • Response Time: [Target: e.g., < 200ms p95]
  • Throughput: [Requests per second]
  • Concurrency: [Concurrent users supported]
  • Database: [Query performance targets]
  • Caching: [Cache hit rate targets]

Scalability

  • Expected Load: [Users, requests, data volume]
  • Growth Projections: [12-month forecast]
  • Scaling Strategy: [Horizontal/vertical, auto-scaling]

Data Considerations

Data Model:

  • [Key entities and relationships]

Storage Requirements:

  • [Estimated storage needs]
  • [Retention policies]

Data Migration:

  • [Migration plan if updating existing data]
  • [Rollback strategy]

Privacy & Compliance:

  • PII handling: [How personal data is handled]
  • Data deletion: [User data deletion process]
  • Audit logging: [What's logged and retained]

Design & UX Requirements

User Experience Principles

[Key UX principles guiding this feature]

User Flows

Primary Flow:

  1. [Step 1]
  2. [Step 2]
  3. [Step 3]
  4. [Final state]

Alternative Flows:

  • [Alternative scenario 1]
  • [Error handling flow]

Visual Design

Design Assets:

  • [Link to Figma/Sketch files]
  • [Link to design system]

Key Screens:

  • [Screen 1]: [Link to mockup]
  • [Screen 2]: [Link to mockup]
  • [Screen 3]: [Link to mockup]

Design System Components:

  • [Component 1 from design system]
  • [Component 2 from design system]
  • [New components needed]

Interaction Patterns

  • [Pattern 1: e.g., "Click to expand"]
  • [Pattern 2: e.g., "Drag to reorder"]
  • [Pattern 3: e.g., "Inline editing"]

Accessibility (a11y)

Requirements:

  • WCAG 2.1 Level AA compliance
  • Keyboard navigation support
  • Screen reader compatibility
  • Color contrast ratios (4.5:1 for text)
  • Focus indicators visible
  • Alternative text for images
  • Semantic HTML structure

Testing:

  • Keyboard-only navigation test
  • Screen reader test (NVDA/JAWS)
  • Color contrast verification
  • Automated a11y testing (axe/Lighthouse)

Responsive Design

Breakpoints:

  • Mobile: 320px - 767px
  • Tablet: 768px - 1023px
  • Desktop: 1024px+

Platform-Specific Considerations:

  • [iOS-specific requirements]
  • [Android-specific requirements]
  • [Web-specific requirements]

Timeline & Milestones

Target Launch Date: [YYYY-MM-DD or Q#]

Phases

Phase Deliverables Owner Start Date End Date
Discovery Requirements finalized, design approved PM/Design [Date] [Date]
Design High-fidelity mockups, user testing Design [Date] [Date]
Development Backend + frontend implementation Engineering [Date] [Date]
QA Testing complete, bugs resolved QA [Date] [Date]
Beta Beta testing with select users PM/QA [Date] [Date]
Launch Production release Engineering [Date] [Date]
Post-Launch Monitoring, iteration based on data PM/Engineering [Date] [Date]

Key Milestones

  • [Date]: Kickoff meeting
  • [Date]: Design review
  • [Date]: Technical design review
  • [Date]: Development complete
  • [Date]: QA complete
  • [Date]: Beta launch
  • [Date]: General availability
  • [Date]: Post-launch review

Risks & Mitigation

Risk Impact Probability Mitigation Strategy Owner
[Risk 1: e.g., "API partner delays"] High Medium [Strategy: e.g., "Build with mock data, switch when ready"] [Name]
[Risk 2] Medium High [Strategy] [Name]
[Risk 3] Low Low [Strategy] [Name]

Contingency Plans

If [scenario occurs]:

  • Action plan: [Steps to take]
  • Decision maker: [Who makes the call]
  • Trigger: [What indicates this scenario]

Dependencies & Assumptions

Dependencies

Internal:

  • [Dependency 1: e.g., "Design system update"]
  • [Dependency 2: e.g., "API v2 completion"]
  • [Dependency 3]

External:

  • [Dependency 1: e.g., "Third-party API approval"]
  • [Dependency 2]

Assumptions

  • [Assumption 1: e.g., "Users have updated to app version 2.0+"]
  • [Assumption 2: e.g., "Budget approved for $X infrastructure costs"]
  • [Assumption 3]

Open Questions

Track unresolved items that need decisions:

  • [Question 1]

    • Context: [Why this matters]
    • Options: [List options being considered]
    • Owner: [Who will decide]
    • Deadline: [When decision needed]

  • [Question 2]

    • Context:
    • Options:
    • Owner:
    • Deadline:

Stakeholder Sign-Off

Stakeholder Role Review Status Approved Date
[Name] Product Lead ⏳ Pending / ✅ Complete ☐ -
[Name] Engineering Lead ⏳ Pending / ✅ Complete ☐ -
[Name] Design Lead ⏳ Pending / ✅ Complete ☐ -
[Name] QA Lead ⏳ Pending / ✅ Complete ☐ -
[Name] Security ⏳ Pending / ✅ Complete ☐ -
[Name] Legal/Compliance ⏳ Pending / ✅ Complete ☐ -

Appendix

References

  • [User research findings link]
  • [Competitive analysis link]
  • [Market research link]
  • [Technical design doc link]

Related Documents

  • [Link to design files]
  • [Link to API documentation]
  • [Link to test plan]

Glossary

  • [Term 1]: [Definition]
  • [Term 2]: [Definition]
  • [Term 3]: [Definition]

Change Log

Version Date Author Changes
1.0 [YYYY-MM-DD] [Name] Initial draft
1.1 [YYYY-MM-DD] [Name] [Changes made]

Document Usage Notes

When to use this template:

  • Major new features
  • New products
  • Significant product enhancements
  • Cross-functional initiatives

When NOT to use this template:

  • Minor bug fixes
  • Small UI tweaks
  • Maintenance tasks
  • Simple A/B tests

Customization:

  • Remove sections not relevant to your project
  • Add sections specific to your domain
  • Adjust detail level based on project scope
  • Use "Lean PRD" format for smaller projects

Best Practices:

  • Start with problem, not solution
  • Keep it concise but complete
  • Use specific, measurable language
  • Include visual aids (mockups, diagrams)
  • Review with all stakeholders
  • Keep it updated as understanding evolves
Reference in New Issue View Git Blame Copy Permalink