296 lines
6.1 KiB
Markdown
296 lines
6.1 KiB
Markdown
---
|
|
description: Write a comprehensive Product Requirements Document for a feature or initiative
|
|
disable-model-invocation: false
|
|
---
|
|
|
|
# Write PRD
|
|
|
|
Create a structured Product Requirements Document that aligns stakeholders and guides implementation.
|
|
|
|
## When to Use
|
|
|
|
- Starting a new feature or project
|
|
- Documenting requirements before development
|
|
- Creating alignment between product, design, and engineering
|
|
- Formalizing user feedback into actionable requirements
|
|
|
|
## Used By
|
|
|
|
- Product Manager (primary owner)
|
|
- Full-Stack Engineer (technical input)
|
|
- UI/UX Designer (design requirements)
|
|
|
|
---
|
|
|
|
## PRD Template
|
|
|
|
```markdown
|
|
# PRD: [Feature/Project Name]
|
|
|
|
**Author**: [Name]
|
|
**Status**: Draft | In Review | Approved
|
|
**Last Updated**: [Date]
|
|
**Version**: 1.0
|
|
|
|
---
|
|
|
|
## Executive Summary
|
|
|
|
[2-3 sentence summary of what we're building and why it matters]
|
|
|
|
---
|
|
|
|
## Problem Statement
|
|
|
|
### The Problem
|
|
[Clear description of the user/business problem]
|
|
|
|
### Who Has This Problem
|
|
- **Primary Users**: [User segment]
|
|
- **Secondary Users**: [Other affected users]
|
|
- **Frequency**: [How often does this problem occur]
|
|
|
|
### Impact
|
|
- **User Impact**: [How it affects users]
|
|
- **Business Impact**: [How it affects the business]
|
|
|
|
### Evidence
|
|
- [User research finding]
|
|
- [Support ticket data]
|
|
- [Analytics insight]
|
|
|
|
---
|
|
|
|
## Goals & Success Metrics
|
|
|
|
### Objective
|
|
[One clear objective this feature achieves]
|
|
|
|
### Key Results
|
|
1. **KR1**: [Measurable outcome] - Target: [X]
|
|
2. **KR2**: [Measurable outcome] - Target: [X]
|
|
3. **KR3**: [Measurable outcome] - Target: [X]
|
|
|
|
### Non-Goals
|
|
- [What we are explicitly NOT trying to do]
|
|
- [Scope boundaries]
|
|
|
|
---
|
|
|
|
## User Stories
|
|
|
|
### Primary Flow
|
|
|
|
**As a** [user type]
|
|
**I want to** [action/goal]
|
|
**So that** [benefit/outcome]
|
|
|
|
**Acceptance Criteria:**
|
|
- [ ] Given [context], when [action], then [result]
|
|
- [ ] Given [context], when [action], then [result]
|
|
- [ ] Given [context], when [action], then [result]
|
|
|
|
### Secondary Flows
|
|
|
|
[Additional user stories for edge cases, admin flows, etc.]
|
|
|
|
---
|
|
|
|
## Scope
|
|
|
|
### In Scope (MVP)
|
|
- [ ] [Feature/capability 1]
|
|
- [ ] [Feature/capability 2]
|
|
- [ ] [Feature/capability 3]
|
|
|
|
### Out of Scope (Future)
|
|
- [ ] [Explicitly excluded 1]
|
|
- [ ] [Explicitly excluded 2]
|
|
|
|
### Dependencies
|
|
- [External system/team dependency]
|
|
- [Technical prerequisite]
|
|
|
|
---
|
|
|
|
## Design & UX
|
|
|
|
### User Flow
|
|
[Description or link to user flow diagram]
|
|
|
|
1. [Step 1]
|
|
2. [Step 2]
|
|
3. [Step 3]
|
|
|
|
### Wireframes/Mockups
|
|
[Links to design files or embedded images]
|
|
|
|
### Key Design Decisions
|
|
- **Decision 1**: [Choice made] - Rationale: [Why]
|
|
- **Decision 2**: [Choice made] - Rationale: [Why]
|
|
|
|
### Accessibility Requirements
|
|
- [ ] [WCAG requirement]
|
|
- [ ] [Keyboard navigation]
|
|
- [ ] [Screen reader support]
|
|
|
|
---
|
|
|
|
## Technical Requirements
|
|
|
|
### Architecture Overview
|
|
[High-level technical approach]
|
|
|
|
### Data Model Changes
|
|
[New entities, fields, relationships]
|
|
|
|
### API Design
|
|
[New endpoints or changes needed]
|
|
|
|
### Performance Requirements
|
|
- Load time: [Target]
|
|
- Throughput: [Target]
|
|
- Scalability: [Considerations]
|
|
|
|
### Security Considerations
|
|
- [Authentication requirements]
|
|
- [Data protection needs]
|
|
- [Compliance requirements]
|
|
|
|
---
|
|
|
|
## Analytics & Tracking
|
|
|
|
### Events to Track
|
|
| Event Name | Trigger | Properties |
|
|
|------------|---------|------------|
|
|
| [event] | [when] | [what data] |
|
|
|
|
### Success Dashboard
|
|
[Metrics to display and how to measure]
|
|
|
|
### Experiment Plan
|
|
[A/B tests or phased rollout approach]
|
|
|
|
---
|
|
|
|
## Risks & Mitigations
|
|
|
|
| Risk | Likelihood | Impact | Mitigation |
|
|
|------|------------|--------|------------|
|
|
| [Risk 1] | H/M/L | H/M/L | [Strategy] |
|
|
| [Risk 2] | H/M/L | H/M/L | [Strategy] |
|
|
|
|
---
|
|
|
|
## Timeline & Milestones
|
|
|
|
### Phase 1: [Name]
|
|
- [Deliverable 1]
|
|
- [Deliverable 2]
|
|
|
|
### Phase 2: [Name]
|
|
- [Deliverable 1]
|
|
- [Deliverable 2]
|
|
|
|
### Key Dates
|
|
- Design Complete: [Date]
|
|
- Development Start: [Date]
|
|
- Beta Release: [Date]
|
|
- GA Release: [Date]
|
|
|
|
---
|
|
|
|
## Open Questions
|
|
|
|
- [ ] [Question 1] - Owner: [Name]
|
|
- [ ] [Question 2] - Owner: [Name]
|
|
|
|
---
|
|
|
|
## Appendix
|
|
|
|
### Related Documents
|
|
- [Link to design specs]
|
|
- [Link to technical specs]
|
|
- [Link to research]
|
|
|
|
### Revision History
|
|
| Version | Date | Author | Changes |
|
|
|---------|------|--------|---------|
|
|
| 1.0 | [Date] | [Name] | Initial draft |
|
|
```
|
|
|
|
---
|
|
|
|
## PRD Best Practices
|
|
|
|
### Writing Guidelines
|
|
|
|
1. **Lead with the problem, not the solution**
|
|
- Start by deeply understanding and articulating the problem
|
|
- Resist jumping to solutions until the problem is clear
|
|
|
|
2. **Be specific and measurable**
|
|
- Avoid vague language like "improve" or "better"
|
|
- Define concrete metrics and targets
|
|
|
|
3. **Keep it concise**
|
|
- PRDs that are too long don't get read
|
|
- Focus on what's essential for decision-making
|
|
|
|
4. **Show your work**
|
|
- Include evidence for assertions
|
|
- Link to research, data, or feedback
|
|
|
|
5. **Define what's NOT included**
|
|
- Out of scope is as important as in scope
|
|
- Prevents scope creep
|
|
|
|
### Common Mistakes to Avoid
|
|
|
|
- **Solutioning too early**: Define the problem first
|
|
- **Vague acceptance criteria**: Make them testable
|
|
- **Missing success metrics**: How will you know it worked?
|
|
- **Skipping edge cases**: Think about error states and failures
|
|
- **Ignoring accessibility**: Include from the start, not as afterthought
|
|
|
|
### Review Checklist
|
|
|
|
Before sharing the PRD:
|
|
|
|
- [ ] Problem statement is clear and evidence-backed
|
|
- [ ] User stories have testable acceptance criteria
|
|
- [ ] Scope is explicitly defined (in and out)
|
|
- [ ] Success metrics are measurable
|
|
- [ ] Technical approach has been validated with engineering
|
|
- [ ] Design requirements are specified
|
|
- [ ] Open questions are documented with owners
|
|
- [ ] Risks are identified with mitigations
|
|
|
|
---
|
|
|
|
## Quick Reference
|
|
|
|
### User Story Format
|
|
```
|
|
As a [user type]
|
|
I want to [action/goal]
|
|
So that [benefit/outcome]
|
|
```
|
|
|
|
### Acceptance Criteria Format
|
|
```
|
|
Given [context/precondition]
|
|
When [action/trigger]
|
|
Then [expected outcome]
|
|
```
|
|
|
|
### INVEST Criteria for Stories
|
|
- **I**ndependent: Can be developed separately
|
|
- **N**egotiable: Details can be discussed
|
|
- **V**aluable: Provides value to users
|
|
- **E**stimable: Can estimate effort
|
|
- **S**mall: Can complete in a sprint
|
|
- **T**estable: Can verify completion
|