Prd Documentation

PRD Documentation Skill - Professional Product Requirements Writing

This Skill provides expertise in writing comprehensive, clear, and actionable Product Requirements Documents (PRDs) and Feature Specifications.

When to Use This Skill

Use this Skill when you need to:

• Write complete PRD documents
• Create feature specifications
• Define technical requirements
• Document acceptance criteria
• Specify non-functional requirements
• Create user stories with details
• Plan product launches

Core Process

Step 1: Gather Requirements

Essential Inputs:

• Validated business idea (from idea-agent)
• Target users and personas
• Business objectives and success metrics
• Key features and scope
• Technical constraints
• Timeline and resources

If Missing, Ask:

• "What problem does this product solve?"
• "Who are the primary users?"
• "What are the must-have features for MVP?"
• "What are the business goals and KPIs?"
• "What technical constraints exist?"
• "When is the target launch date?"

Step 2: Use Reference Templates

Always read these templates:

# Use Read tool:
/reference/prd-templates/standard-prd-template.md
/reference/prd-templates/feature-spec-template.md

These provide:

• Complete PRD structure (15 sections)
• Feature specification format
• Acceptance criteria templates
• Technical requirements checklist
• Success metrics frameworks

Step 3: PRD Structure

Follow this comprehensive 15-section structure:

1. Document Information

- Product Name: [Name]
- Version: [1.0]
- Author: [Name]
- Last Updated: [Date]
- Status: [Draft | In Review | Approved | In Development]

2. Executive Summary

Product Overview:

• One-paragraph description
• Core value proposition

Problem Statement:

• What problem we're solving
• Why it matters now

Success Criteria:

• Primary metric and target
• Secondary metrics

3. Goals and Objectives

Business Goals:

• Revenue impact
• Market position
• Strategic alignment

User Goals:

• User benefits
• Problem solved
• Outcome achieved

Product Objectives (OKRs):

Objective 1: [Qualitative, inspiring goal]
├─ Key Result 1.1: [Measurable, time-bound]
├─ Key Result 1.2: [Measurable, time-bound]
└─ Key Result 1.3: [Measurable, time-bound]

Objective 2: [Qualitative goal]
├─ Key Result 2.1: [Measurable]
└─ Key Result 2.2: [Measurable]

4. Target Audience

Primary Persona:

### Persona: [Name]

Demographics:
- Age: [Range]
- Location: [Where]
- Job/Role: [Title]
- Tech Proficiency: [High/Medium/Low]

Goals:
- [Goal 1]
- [Goal 2]

Pain Points:
- [Pain 1]
- [Pain 2]

Current Solutions:
- [What they use today]

Quote:
"[In their own words]"

5. User Stories and Use Cases

Format:

### User Story: [Title]

As a [specific user type],
I want to [specific action],
So that [specific benefit].

**Acceptance Criteria:**

Given [precondition]
When [action]
Then [expected outcome]
And [additional outcome]

**Priority:** P0 | P1 | P2
**Story Points:** [1-13]

Use Case Format:

### Use Case: [Title]

**Actor:** [Who performs this]
**Trigger:** [What initiates this]
**Preconditions:** [What must be true]

**Main Flow:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Alternative Flows:**
- If [condition], then [alternative steps]

**Postconditions:** [System state after completion]

6. Features and Requirements

For Each Feature:

## Feature: [Name]

**Description:**
[What it is and why it's important]

**User Value:**
[How it benefits users]

**User Story:**
As a [user],
I want to [action],
So that [benefit].

**Functional Requirements:**
1. [Requirement 1]
2. [Requirement 2]
3. [Requirement 3]

**Acceptance Criteria:**
Given [context]
When [action]
Then [outcome]

**Priority:** P0 (Must) | P1 (Should) | P2 (Could)
**Effort:** XS | S | M | L | XL
**Dependencies:** [Feature IDs or systems]
**Technical Notes:** [Implementation considerations]

**Edge Cases:**
- [Edge case 1 and handling]
- [Edge case 2 and handling]

**Error Handling:**
- [Error scenario 1]: [Error message and action]
- [Error scenario 2]: [Error message and action]

Non-Functional Requirements:

### Performance
- Page Load Time: < [X] seconds
- API Response Time: < [Y] ms
- Concurrent Users: [Z] minimum
- Data Processing: [Rate/volume]

### Security
- Authentication: [Method]
- Authorization: [RBAC, ABAC]
- Data Encryption: [At rest, in transit]
- Compliance: [GDPR, HIPAA, SOC 2]
- Input Validation: [Rules]
- Rate Limiting: [Limits]

### Scalability
- Horizontal Scaling: [Yes/No]
- Auto-scaling: [Yes/No]
- Peak Load Capacity: [X users/requests]
- Database Sharding: [If applicable]

### Reliability
- Uptime SLA: [99.9%]
- Disaster Recovery: RPO/RTO
- Backup Strategy: [Frequency, retention]
- Monitoring: [Tools, alerts]

### Accessibility
- WCAG Level: [AA | AAA]
- Screen Reader: [Supported]
- Keyboard Navigation: [Full support]
- Color Contrast: [Ratio]
- Focus Indicators: [Visible]

### Browser/Platform Support
**Desktop:**
- Chrome: [Latest 2 versions]
- Firefox: [Latest 2 versions]
- Safari: [Latest 2 versions]
- Edge: [Latest 2 versions]

**Mobile:**
- iOS Safari: [Latest 2 versions]
- Chrome Mobile: [Latest 2 versions]

7. Design and UX

### Design Principles
1. [Principle 1: e.g., Simplicity first]
2. [Principle 2: e.g., Progressive disclosure]
3. [Principle 3: e.g., Accessible by default]

### Key Screens
**Screen 1: [Name]**
- Purpose: [What users do here]
- Key Elements: [Components, CTAs]
- User Flow: [Navigation]

### User Flows
**Flow: [Name]**
1. [Entry point]
2. [Step 1]
3. [Decision point]
4. [Step 2]
5. [Exit/Success state]

### Design Assets
- Wireframes: [Link to Figma/Sketch]
- Mockups: [Link]
- Design System: [Link]
- Style Guide: [Link]

8. Technical Specifications

### System Architecture
[High-level architecture diagram or description]

Frontend <-> API Gateway <-> Backend Services <-> Database ↓ Third-party APIs

### Technology Stack
- Frontend: [React, Vue, Angular]
- Backend: [Node.js, Python, Java]
- Database: [PostgreSQL, MongoDB]
- Infrastructure: [AWS, GCP, Azure]
- Cache: [Redis, Memcached]

### API Requirements
**Endpoint:** `POST /api/resource`

Request:
```json
{
  "field1": "value",
  "field2": 123
}

Response:

{
  "success": true,
  "data": {
    "id": "uuid",
    "created_at": "timestamp"
  }
}

Error Codes:

• 400: Bad Request
• 401: Unauthorized
• 404: Not Found
• 500: Internal Server Error

Data Model

Entity: User

{
  id: UUID (PK)
  email: String (unique, indexed)
  name: String
  created_at: Timestamp
  updated_at: Timestamp
}

Relationships:

• User has_many Orders
• Order belongs_to User

Integrations

#### 9. Analytics and Metrics

```markdown
### Key Performance Indicators

**Product KPIs:**
- Acquisition: [New users/month]
- Activation: [% completing onboarding]
- Engagement: [DAU, session length]
- Retention: [Day 7, Day 30]
- Revenue: [MRR, ARPU]
- Referral: [NPS, viral coefficient]

**Success Metrics:**
| Metric | Current | Target | Timeline |
|--------|---------|--------|----------|
| User Adoption | 0 | 10K users | 3 months |
| Activation Rate | - | 40% | Launch+30d |
| DAU/MAU | - | 25% | Launch+90d |
| NPS | - | 40+ | Launch+90d |

### Event Tracking Plan

| Event Name | Description | Properties | Priority |
|------------|-------------|------------|----------|
| user_signup | User completes registration | source, plan | P0 |
| feature_used | User activates key feature | feature_name, duration | P0 |
| conversion | User upgrades to paid | plan, amount | P0 |
| error_occurred | System error | error_type, page | P1 |

### A/B Testing

**Test 1: [Onboarding Flow]**
- Hypothesis: [Simplified onboarding will increase activation by 20%]
- Variants: Control vs Variant A
- Success Metric: [Onboarding completion rate]
- Sample Size: [10,000 users]
- Duration: [2 weeks]

10. Risks and Mitigations

| Risk | Probability | Impact | Mitigation Strategy |
|------|-------------|--------|---------------------|
| Technical complexity | Medium | High | Prototype early, allocate buffer time |
| Low user adoption | Low | High | Beta test, user research, iterative launch |
| Third-party dependency | Medium | Medium | Alternative vendor, fallback plan |
| Competitive response | High | Medium | Focus on differentiation, speed to market |
| Scope creep | High | Medium | Strict prioritization, clear MVP definition |

11. Timeline and Milestones

### Project Phases

**Phase 1: Planning (Weeks 1-2)**
- [ ] PRD Approval
- [ ] Design Review
- [ ] Technical Spec Complete

**Phase 2: Development (Weeks 3-8)**
- Sprint 1 (Weeks 3-4): Core features
- Sprint 2 (Weeks 5-6): Integration
- Sprint 3 (Weeks 7-8): Polish and bug fixes

**Phase 3: Testing (Weeks 9-10)**
- [ ] QA Testing
- [ ] User Acceptance Testing
- [ ] Performance Testing
- [ ] Security Audit

**Phase 4: Launch (Week 11)**
- [ ] Soft Launch (10% rollout)
- [ ] Monitor metrics
- [ ] Full Launch (100% rollout)

### Dependencies
| Dependency | Owner | Status | Due Date | Blocker? |
|------------|-------|--------|----------|----------|
| [API from Team B] | [Name] | In Progress | [Date] | Yes |
| [Design System Update] | [Name] | Not Started | [Date] | No |

12. Open Questions and Assumptions

### Open Questions
1. **[Question about feature X]**
   - Decision needed by: [Date]
   - Owner: [Name]
   - Options: A, B, C
   - Recommendation: [Option A because...]

2. **[Question about technical approach]**
   - Decision needed by: [Date]
   - Owner: [Name]

### Assumptions
1. Users have stable internet connection
2. 80% of traffic from mobile devices
3. Third-party API has 99.9% uptime
4. Users familiar with similar products

### Out of Scope (Explicitly NOT Included)
1. [Feature X] - Planned for v2.0
2. [Platform Y support] - Not in roadmap
3. [Integration Z] - Deprioritized

13-15. Supporting Sections

### Resources and Team
**Core Team:**
- Product Manager: [Name]
- Engineering Lead: [Name]
- Design Lead: [Name]
- QA Lead: [Name]

**Extended Team:**
- Engineers: [X people]
- Designers: [Y people]
- QA: [Z people]

### Launch Plan
**Pre-Launch:**
- [ ] Beta program (100 users, 2 weeks)
- [ ] Marketing materials
- [ ] Support documentation
- [ ] Team training

**Launch:**
- [ ] Announcement (blog, email, social)
- [ ] Press release
- [ ] Customer outreach

**Post-Launch:**
- [ ] Monitor metrics daily
- [ ] User feedback collection
- [ ] Iteration plan

### Change Log
| Date | Version | Changes | Author |
|------|---------|---------|--------|
| 2024-01-15 | 1.0 | Initial draft | PM Name |
| 2024-01-20 | 1.1 | Added technical specs | PM Name |
| 2024-01-25 | 2.0 | Final for review | PM Name |

Best Practices

Writing Style

✅ Do:

• Use clear, unambiguous language
• Be specific and measurable
• Include examples
• Use tables and bullets
• Write from user perspective
• Define acronyms on first use

❌ Don't:

• Use vague terms ("user-friendly", "fast")
• Mix implementation with requirements
• Skip edge cases and errors
• Write lengthy paragraphs
• Assume technical knowledge

Acceptance Criteria

✅ Do:

• Use Given-When-Then format
• Cover happy path, errors, edge cases
• Make testable and measurable
• Include visual feedback requirements
• Specify error messages

❌ Don't:

• Write vague criteria ("works well")
• Focus only on happy path
• Skip error handling
• Forget accessibility
• Leave untestable criteria

Prioritization

Use MoSCoW:

• P0 (Must Have): Blocking for launch
• P1 (Should Have): Important, not blocking
• P2 (Could Have): Nice to have
• P3 (Won't Have): Out of scope

Review Checklist

Before finalizing PRD:

• All sections complete
• User stories have acceptance criteria
• Success metrics defined and measurable
• Technical requirements clear
• Dependencies identified
• Risks assessed with mitigations
• Timeline realistic
• Open questions documented
• Reviewed by engineering
• Reviewed by design
• Reviewed by QA
• Approved by stakeholders

Output Format

File Naming:

[product-name]-prd-v[version].md
Example: ai-study-planner-prd-v1.0.md

Location:

/docs/prd/[filename]

Format:

• Markdown with proper headings (##, ###)
• Tables for comparisons and data
• Code blocks for technical specs
• Checkboxes for action items
• Links to external resources

Example Output

See /reference/prd-templates/standard-prd-template.md for complete example.

Integration Points

This Skill works with:

• prd-agent: Primary user of this skill
• idea-generation: Takes validated idea as input
• userstory-documentation: Provides requirements for story breakdown
• pm-knowledge-base: Uses OKR, metrics, prioritization frameworks

Always use reference templates as foundation, customizing for specific product needs.