mohitagw15856
95 lines
2.6 KiB
Markdown
95 lines
2.6 KiB
Markdown
---
|
|
name: prd-template
|
|
description: Product Requirements Document creation following proven PM template structure. Use when the user asks to create, write, draft, or help with a PRD, product requirements document, product spec, feature specification, or product documentation for a new feature or product.
|
|
---
|
|
|
|
# PRD Template Skill
|
|
|
|
This skill helps create professional Product Requirements Documents following industry best practices.
|
|
|
|
## Template Structure
|
|
|
|
Every PRD should include these sections in order:
|
|
|
|
### 1. Overview
|
|
- **Problem Statement**: What problem are we solving? (2-3 sentences)
|
|
- **Proposed Solution**: High-level description of what we're building (2-3 sentences)
|
|
- **Success Metrics**: How we'll measure success (3-5 key metrics)
|
|
|
|
### 2. Context & Background
|
|
- **Why Now**: Why is this the right time?
|
|
- **Strategic Alignment**: How does this align with company objectives?
|
|
- **User Research Summary**: Key insights from research (if applicable)
|
|
|
|
### 3. User Stories & Use Cases
|
|
Format: "As a [user type], I want to [action] so that [benefit]"
|
|
- Include 3-7 primary user stories
|
|
- Add acceptance criteria for each
|
|
|
|
### 4. Requirements
|
|
**Functional Requirements:**
|
|
- Must-have features (P0)
|
|
- Should-have features (P1)
|
|
- Nice-to-have features (P2)
|
|
|
|
**Non-Functional Requirements:**
|
|
- Performance expectations
|
|
- Security considerations
|
|
- Accessibility requirements
|
|
|
|
### 5. Design & User Experience
|
|
- Link to design mocks or wireframes
|
|
- Key user flows
|
|
- Edge cases and error states
|
|
|
|
### 6. Technical Considerations
|
|
- Architecture implications
|
|
- Dependencies on other systems
|
|
- Technical risks and mitigations
|
|
|
|
### 7. Implementation Plan
|
|
- **Phase 1 (MVP)**: What goes in first version
|
|
- **Phase 2**: What comes next
|
|
- **Phase 3**: Future enhancements
|
|
|
|
### 8. Open Questions
|
|
- Decisions that still need to be made
|
|
- Stakeholders to consult
|
|
- Research needed
|
|
|
|
### 9. Appendix
|
|
- Research links
|
|
- Related documents
|
|
- Competitive analysis
|
|
|
|
## Writing Guidelines
|
|
|
|
**Tone**: Clear, concise, actionable
|
|
**Audience**: Engineers, designers, stakeholders
|
|
**Length**: Aim for 3-6 pages for features, 8-12 for products
|
|
|
|
**Best Practices:**
|
|
- Use concrete examples over abstractions
|
|
- Include "why" not just "what"
|
|
- Make requirements testable
|
|
- Link to supporting materials
|
|
- Update as decisions are made
|
|
|
|
## What Makes a Good PRD
|
|
|
|
✅ **Do:**
|
|
- Write from the user's perspective
|
|
- Include specific success metrics
|
|
- Address edge cases
|
|
- Link to research and data
|
|
- Make trade-offs explicit
|
|
|
|
❌ **Don't:**
|
|
- Write implementation details (that's tech spec)
|
|
- Assume everyone has context
|
|
- Leave requirements ambiguous
|
|
- Skip the "why"
|
|
- Forget about accessibility
|
|
|
|
## Example PRD Opening
|