Product Requirement Documents (PRDs)
This directory contains PRDs for major features and initiatives. Each PRD captures the why, what, and success criteria for a feature.
PRD Template
# PRD-XXX: Feature Name
**Author**: Name
**Date**: YYYY-MM-DD
**Status**: Draft | In Review | Approved | In Development | Launched
## Summary
One paragraph overview of what we're building and why.
## Problem Statement
What problem are we solving? Who experiences this problem? Why does it matter?
## Goals & Success Metrics
- **Primary Goal**: What we must achieve
- **Success Metrics**:
- Metric 1: Target value
- Metric 2: Target value
## User Stories
1. As a [user type], I want to [action] so that [benefit]
2. As a [user type], I want to [action] so that [benefit]
## Requirements
### Must Have (MVP)
- [ ] Requirement 1
- [ ] Requirement 2
### Should Have
- [ ] Requirement 3
- [ ] Requirement 4
### Nice to Have
- [ ] Requirement 5
## Technical Approach
High-level technical approach. Details go in technical design docs.
## Risks & Mitigations
| Risk | Impact | Likelihood | Mitigation |
| ------ | ------ | ---------- | ------------------- |
| Risk 1 | High | Medium | How we'll handle it |
## Timeline
- Week 1-2: Design and planning
- Week 3-4: Implementation
- Week 5: Testing and rollout
## Open Questions
- [ ] Question 1
- [ ] Question 2
Current PRDs
- PRD-001: GitHub Integration - Connect GitHub organizations
Writing a Good PRD
Do’s
- Start with the problem, not the solution
- Include measurable success criteria
- Keep it concise (2-3 pages max)
- Focus on the “what” and “why”, not “how”
- Include user stories
Don’ts
- Don’t include implementation details
- Don’t skip the problem statement
- Don’t forget about edge cases
- Don’t ignore risks
PRD Process
- Draft - PM creates initial PRD
- Review - Engineering, Design, and stakeholders review
- Approval - Leadership approves
- Development - Engineering implements
- Launch - Feature released
- Retrospective - Measure against success criteria