Product Manager

# Product Manager Reference Guide

This document provides detailed guidance on prioritization frameworks, requirements patterns, and best practices for product management activities.

## Prioritization Frameworks

### MoSCoW Method

**Overview:** Time-boxed prioritization framework for requirements classification.

**When to Use:**
- Fixed timeline projects
- MVP definition
- Stakeholder alignment needed
- Resource-constrained environments
- Clear scope boundaries required

**How to Apply:**

1. **Must Have (Critical)**
   - Without this, the project/release fails
   - Legal/regulatory requirements
   - Core functionality that defines the product
   - Safety-critical features
   - **Test:** "What happens if we don't include this?" → "Project fails"

2. **Should Have (Important)**
   - Important but not vital
   - Workarounds exist if not included
   - Significant impact on user satisfaction
   - Will be included unless resource/time constraints prevent
   - **Test:** "What happens if we don't include this?" → "Users disappointed but product viable"

3. **Could Have (Nice to Have)**
   - Desirable but not necessary
   - Small impact if left out
   - Will be included if time/resources allow
   - Often called "nice to haves"
   - **Test:** "What happens if we don't include this?" → "Most users won't notice"

4. **Won't Have (Out of Scope)**
   - Explicitly excluded from this release
   - May be considered for future releases
   - Helps manage scope creep
   - Documents conscious decisions
   - **Test:** "Why are we explicitly excluding this?" → Document the reason

**Example Application:**

```
Feature: User Dashboard

Must Have:
- Display user's active projects
- Show recent activity feed
- Basic profile information
- Logout functionality

Should Have:
- Project completion statistics
- Activity filters (date, type)
- Customizable layout
- Quick action shortcuts

Could Have:
- Team member activity view
- Exportable reports
- Dark mode toggle
- Widget customization

Won't Have:
- Social sharing features
- Collaborative editing
- Mobile app (separate project)
- Third-party integrations
```

### RICE Scoring

**Overview:** Data-driven prioritization using quantitative scoring.

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

**When to Use:**
- Multiple features to compare
- Data-driven decision making needed
- Cross-functional prioritization
- Resource allocation decisions
- Portfolio management

**Component Definitions:**

1. **Reach (How Many?)**
   - Number of users/customers affected per time period
   - Measured in users per quarter/month
   - Based on data, not assumptions
   - Examples:
     - "500 users per month will use this feature"
     - "2,000 customers per quarter will benefit"
   - **Estimation:** Use analytics, surveys, or market research

2. **Impact (How Much Value?)**
   - Value delivered per user
   - Scored on scale: 3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
   - Measures satisfaction, revenue, efficiency gain
   - Examples:
     - Massive (3): Solves critical pain point, major revenue driver
     - High (2): Significant improvement to key workflow
     - Medium (1): Noticeable benefit, clear value
     - Low (0.5): Minor improvement, marginal benefit
     - Minimal (0.25): Barely noticeable improvement
   - **Estimation:** User research, revenue projections, efficiency metrics

3. **Confidence (How Sure?)**
   - Certainty in your estimates
   - Percentage: 100% = High confidence, 80% = Medium, 50% = Low
   - Accounts for uncertainty in Reach and Impact
   - Examples:
     - 100%: Backed by solid data and research
     - 80%: Some data, reasonable assumptions
     - 50%: Mostly assumptions, limited data
   - **Rule:** If confidence <50%, gather more data

4. **Effort (How Much Work?)**
   - Total team time required
   - Measured in person-months
   - Includes design, development, testing, deployment
   - Examples:
     - 0.5 = 2 weeks of team time
     - 1.0 = 1 month of t