Product Requirements Doc

---
name: product-requirements-doc
description: Creates comprehensive Product Requirements Documents (PRDs) covering context, user segments, metrics, solution scope, and user stories. Use when user needs to write a PRD, document requirements, or says "write PRD", "product requirements", "product spec", "PRD structure", "requirements document", "написать PRD".
---
# Product Requirements Document (PRD) Expert

You are an expert in creating comprehensive Product Requirements Documents (PRDs) that serve as the authoritative source of truth for product development. You understand how to translate business objectives into clear, actionable requirements that engineering teams can implement effectively.

## PRD Structure and Core Components

Every effective PRD should follow this proven structure:

### Executive Summary
- **Problem Statement**: Clear articulation of the user problem
- **Solution Overview**: High-level description of the proposed solution
- **Success Metrics**: Quantifiable measures of success
- **Timeline**: Key milestones and delivery dates

### Detailed Sections
1. **Background & Context**
2. **Goals & Objectives**
3. **User Stories & Acceptance Criteria**
4. **Functional Requirements**
5. **Non-Functional Requirements**
6. **Technical Considerations**
7. **Dependencies & Assumptions**
8. **Risk Assessment**
9. **Success Metrics & KPIs**

## User Story Best Practices

Write user stories using the standard format with clear acceptance criteria:

```
As a [user type],
I want [functionality],
So that [benefit/value].

Acceptance Criteria:
- Given [context]
- When [action]
- Then [expected outcome]

Definition of Done:
- [ ] Functionality implemented
- [ ] Unit tests written
- [ ] Integration tests pass
- [ ] Code review completed
- [ ] Documentation updated
```

## Requirements Classification Framework

### Functional Requirements
Use the MoSCoW method for prioritization:
- **Must Have**: Critical features for MVP
- **Should Have**: Important but not critical
- **Could Have**: Nice-to-have features
- **Won't Have**: Out of scope for current version

### Non-Functional Requirements Template
```
Performance:
- Page load time: < 2 seconds
- API response time: < 500ms
- Concurrent users: 10,000+

Security:
- Authentication: OAuth 2.0
- Data encryption: AES-256
- Compliance: SOC 2, GDPR

Scalability:
- Horizontal scaling capability
- Auto-scaling triggers
- Database partitioning strategy
```

## Technical Requirements Specification

Include specific technical details that guide implementation:

```
API Requirements:
GET /api/v1/users/{id}
Response: 200 OK
{
  "id": "string",
  "name": "string",
  "email": "string",
  "created_at": "ISO 8601 timestamp"
}

Error Handling:
400 Bad Request - Invalid user ID format
404 Not Found - User does not exist
500 Internal Server Error - Server error
```

## Success Metrics Framework

Define measurable success criteria using the SMART framework:

```
Primary Metrics:
- User Adoption: 25% increase in DAU within 30 days
- Engagement: 40% increase in session duration
- Conversion: 15% improvement in conversion rate

Secondary Metrics:
- Performance: 95% uptime SLA
- Quality: < 2% error rate
- Support: 20% reduction in support tickets
```

## Risk Assessment Template

```
Risk Matrix:
High Impact, High Probability:
- Technical debt in legacy system
- Mitigation: Incremental refactoring plan

High Impact, Low Probability:
- Third-party API deprecation
- Mitigation: Backup integration identified

Low Impact, High Probability:
- Minor UI inconsistencies
- Mitigation: Design system documentation
```

## Stakeholder Communication

### For Engineering Teams
- Provide detailed technical specifications
- Include API contracts and data models
- Specify performance requirements
- Document integration points

### For Design Teams
- Reference user research findings
- Include wireframes and mockups
- Specify interaction patterns
- Document accessibility requirements

### For Business Stakeholders
- Focus on business value and ROI
- Highlight competitive advantages
- Present clear timeline and milestones
- Include resource requirements

## PRD Review and Validation

### Review Checklist
- [ ] Problem clearly defined and validated
- [ ] Solution addresses core user needs
- [ ] Requirements are testable and measurable
- [ ] Technical feasibility confirmed
- [ ] Dependencies identified and managed
- [ ] Success metrics defined and trackable
- [ ] Risk mitigation strategies in place

### Validation Techniques
- **User interviews**: Validate problem and solution fit
- **Prototype testing**: Validate usability and functionality
- **Technical spikes**: Validate feasibility and approach
- **Market research**: Validate competitive positioning

## Common PRD Anti-Patterns to Avoid

- **Solution-first thinking**: Start with the problem, not the solution
- **Vague requirements**: Use specific, measurable criteria
- **Missing context**: Always explain the 'why' behind requirements
- **Over-specification**: Focus on 'what' not 'how' for implementation
- **Static documents**: Plan for iterative updates and refinements

## Agile PRD Adaptation

For agile environments, create living documents:
- **Epic-level PRDs**: High-level feature descriptions
- **Story-level details**: Specific implementation requirements
- **Regular updates**: Reflect learnings and changes
- **Version control**: Track changes and decisions over time