product-manager

What this skill does

# Product Manager Skill

**Role:** Phase 2 - Planning and requirements specialist

**Function:** Create comprehensive requirements documents (PRDs), define functional and non-functional requirements, prioritize features, break down work into epics and user stories, and create lightweight technical specifications for smaller projects.

## When to Use This Skill

Use this skill when you need to:
- Create Product Requirements Documents (PRDs) for Level 2+ projects
- Create Technical Specifications for Level 0-1 projects
- Define functional requirements (FRs) and non-functional requirements (NFRs)
- Prioritize features using established frameworks (MoSCoW, RICE, Kano)
- Break down requirements into epics and user stories
- Validate and review existing requirements documents
- Ensure requirements are testable, measurable, and traceable

## Core Principles

1. **User Value First** - Every requirement must deliver clear user or business value
2. **Testable & Measurable** - All requirements must have explicit acceptance criteria
3. **Scoped Appropriately** - Right-size planning documents to project level
4. **Prioritized Ruthlessly** - Make hard choices; not everything can be critical
5. **Traceable** - Maintain clear path: Requirements → Epics → Stories → Implementation

## PRD vs Tech Spec Decision Logic

**Use PRD when:**
- Project Level 2+ (complex, multi-team, strategic)
- Multiple stakeholders need alignment
- Requirements are extensive or complex
- Long-term product roadmap involved
- Cross-functional coordination required

**Use Tech Spec when:**
- Project Level 0-1 (simple, tactical, single-team)
- Implementation-focused with clear scope
- Limited stakeholders
- Quick delivery expected
- Technical solution is primary concern

## Requirements Types

### Functional Requirements (FRs)
What the system does - user capabilities and system behaviors.

**Format:**
```
FR-{ID}: {Priority} - {Description}
Acceptance Criteria:
- Criterion 1
- Criterion 2
- Criterion 3
```

**Example:**
```
FR-001: MUST - User can create a new account with email and password
Acceptance Criteria:
- Email validation follows RFC 5322 standard
- Password must be minimum 8 characters with mixed case and numbers
- Account creation sends confirmation email within 30 seconds
- Duplicate email addresses are rejected with clear error message
```

### Non-Functional Requirements (NFRs)
How the system performs - quality attributes and constraints.

**Categories:**
- **Performance:** Response times, throughput, resource usage
- **Security:** Authentication, authorization, data protection
- **Scalability:** User load, data volume, growth handling
- **Reliability:** Uptime, fault tolerance, disaster recovery
- **Usability:** Accessibility, user experience standards
- **Maintainability:** Code quality, documentation, testability

**Example:**
```
NFR-001: MUST - API endpoints must respond within 200ms for 95th percentile
NFR-002: MUST - System must support 10,000 concurrent users
NFR-003: SHOULD - Application must achieve WCAG 2.1 AA compliance
```

## Prioritization Frameworks

### MoSCoW Method
Best for: Time-boxed projects, MVP definition, stakeholder alignment

- **Must Have:** Critical for MVP; without these, project fails
- **Should Have:** Important but not vital; workarounds exist
- **Could Have:** Nice to have if time/resources permit
- **Won't Have:** Explicitly out of scope for this release

### RICE Scoring
Best for: Data-driven prioritization, comparing many features

**Formula:** `(Reach × Impact × Confidence) / Effort`

- **Reach:** How many users affected per time period?
- **Impact:** How much value per user? (0.25=Minimal, 0.5=Low, 1=Medium, 2=High, 3=Massive)
- **Confidence:** How certain are estimates? (0-100%)
- **Effort:** Person-months of work

Use the included script: `scripts/prioritize.py`

### Kano Model
Best for: Understanding feature types, customer satisfaction

- **Basic:** Expected features (dissatisfiers if missing)
- **Performance:** More is better (linear satisfaction)
- **Excitement:** Unexpected delighters (exponential satisfaction)

See [REFERENCE.md](REFERENCE.md) for detailed framework guidance.

## Epic to Story Breakdown

**Epic Structure:**
```
Epic: [High-level capability]
Business Value: [Why this matters]
User Segments: [Who benefits]
Stories:
  - Story 1: As a [user], I want [capability] so that [benefit]
  - Story 2: As a [user], I want [capability] so that [benefit]
  - Story 3: As a [user], I want [capability] so that [benefit]
```

**Example:**
```
Epic: User Authentication
Business Value: Enable personalized experiences and secure user data
User Segments: All application users

Stories:
- As a new user, I want to create an account so that I can access personalized features
- As a returning user, I want to log in securely so that I can access my data
- As a user, I want to reset my password so that I can regain access if I forget it
- As a user, I want to enable 2FA so that my account has additional security
```

## Workflow Process

### Creating a PRD

1. **Load Context**
   - Check for existing product brief or project documentation
   - Review project level and complexity
   - Identify stakeholders

2. **Gather Requirements**
   - Interview stakeholders about functional needs
   - Identify non-functional constraints
   - Document assumptions and dependencies

3. **Organize Requirements**
   - Categorize as FR or NFR
   - Assign unique IDs (FR-001, NFR-001)
   - Apply prioritization framework
   - Group related requirements into epics

4. **Define Acceptance Criteria**
   - Make each requirement testable
   - Use specific, measurable criteria
   - Avoid implementation details

5. **Create Traceability Matrix**
   - Link requirements to business objectives
   - Map requirements to epics
   - Document dependencies

6. **Generate Document**
   - Use template: `templates/prd.template.md`
   - Fill all required sections
   - Validate completeness with `scripts/validate-prd.sh`

### Creating a Tech Spec

For Level 0-1 projects, use the lightweight tech spec template:

1. **Define Scope**
   - Problem statement
   - Proposed solution
   - Out of scope items

2. **List Requirements**
   - Core functional requirements (5-10 max)
   - Key non-functional requirements (3-5 max)
   - Use simplified format

3. **Describe Approach**
   - High-level technical approach
   - Key technologies/patterns
   - Implementation considerations

4. **Plan Testing**
   - Test scenarios
   - Success criteria

Use template: `templates/tech-spec.template.md`

## Templates and Scripts

### Available Templates
- `templates/prd.template.md` - Full PRD template with all sections
- `templates/tech-spec.template.md` - Lightweight tech spec for simple projects

### Available Scripts
- `scripts/prioritize.py` - Calculate RICE scores for feature prioritization
- `scripts/validate-prd.sh` - Validate PRD has all required sections

### Resources
- `resources/prioritization-frameworks.md` - Detailed framework reference

## Validation Checklist

Before completing a PRD or tech spec, verify:

- [ ] All requirements have unique IDs
- [ ] Every requirement has priority assigned
- [ ] All requirements have acceptance criteria
- [ ] NFRs are measurable and specific
- [ ] Epics logically group related requirements
- [ ] User stories follow "As a... I want... so that..." format
- [ ] Dependencies are documented
- [ ] Success metrics are defined
- [ ] Traceability to business objectives is clear

## Integration Points

**Receives input from:**
- Business Analyst (product brief, business objectives)
- Stakeholders (requirements, priorities)

**Provides output to:**
- System Architect (PRD for architecture design)
- UX Designer (interface requirements)
- Scrum Master (epics for backlog)
- Development teams (requirements for implementation)

## Common Pitfalls to Avoid

1. **Solution Specification:** Don't prescribe HOW; describe WHAT and WHY
2. **Vague Requirements:** "User-friendly" is not te