Skip to main content

PRD Template

Use this template for Product Requirements Documents.


Template

# [Product/Feature Name] PRD

## Overview

### Summary
[One paragraph description of what this product/feature does]

### Problem Statement
[What problem does this solve? Why does it matter?]

### Goals
- [Primary goal]
- [Secondary goal]
- [Tertiary goal]

### Non-Goals
- [What we're explicitly NOT doing]
- [Out of scope items]

---

## User Stories

### Primary User
As a [user type], I want to [action], so that [benefit].

### Additional Stories
- As a [user type], I want to [action], so that [benefit].
- As a [user type], I want to [action], so that [benefit].

---

## Requirements

### Functional Requirements

| ID | Requirement | Priority |
|----|-------------|----------|
| FR-1 | [Requirement description] | Must Have |
| FR-2 | [Requirement description] | Should Have |
| FR-3 | [Requirement description] | Nice to Have |

### Non-Functional Requirements

| ID | Requirement | Target |
|----|-------------|--------|
| NFR-1 | Performance | Page load < 2s |
| NFR-2 | Availability | 99.9% uptime |
| NFR-3 | Security | [Requirement] |

---

## User Experience

### User Flow
1. User does X
2. System responds with Y
3. User sees Z

### Wireframes
[Link to designs or embed images]

---

## Success Metrics

| Metric | Target | Measurement Method |
|--------|--------|-------------------|
| [Metric 1] | [Target] | [How to measure] |
| [Metric 2] | [Target] | [How to measure] |

---

## Risks & Mitigations

| Risk | Impact | Likelihood | Mitigation |
|------|--------|------------|------------|
| [Risk 1] | High | Medium | [Mitigation strategy] |

---

## Dependencies

- [Dependency 1]
- [Dependency 2]

---

## Open Questions

- [ ] [Question 1]
- [ ] [Question 2]

---

## Appendix

### Glossary
- **Term**: Definition

### References
- [Link to research]
- [Link to designs]

Tips for Writing PRDs

  1. Be specific - Vague requirements lead to wrong implementations
  2. Prioritize - Not everything is "must have"
  3. Include acceptance criteria - How do we know it's done?
  4. Update regularly - PRDs are living documents
  5. Get buy-in - Share and get feedback before building