product-manager

What this skill does

# Product Manager

## Overview
This skill enables structured product management work—from writing comprehensive PRDs and user stories through feature prioritization and metrics definition. It provides repeatable frameworks (RICE scoring, MoSCoW, OKR-aligned roadmaps) and document templates grounded in real product scenarios. The output is always decision-ready: actionable artifacts that engineering, design, and stakeholders can align on.

## When to Use
- Writing a Product Requirements Document (PRD) for a new feature or product
- Prioritizing a feature backlog with a scoring framework
- Translating user needs into user stories with acceptance criteria
- Defining success metrics (product KPIs) for a feature or initiative
- Creating a quarterly roadmap aligned to business objectives
- Writing a one-pager or feature brief for executive review

## When NOT to Use
- Conducting user research or usability testing (use ux-researcher skill)
- Designing wireframes or high-fidelity UI (use a design skill)
- Writing technical specifications for engineers (use a tech spec skill)
- Building business cases with financial modeling (use business-analyst skill)

## Quick Reference
| Task | Framework/Template |
|------|--------------------|
| Feature prioritization | RICE score: (Reach × Impact × Confidence) / Effort |
| Backlog triage | MoSCoW: Must have / Should have / Could have / Won't have |
| User story format | "As a [user], I want [action] so that [benefit]" |
| Acceptance criteria | Given/When/Then (BDD-style) |
| Success metrics | Primary: 1 north star. Secondary: 3–5 supporting. Guardrails: 2–3 don't-break metrics |
| PRD sections | Overview → Problem → Goals → Users → Requirements → Metrics → Risks → Timeline |
| Impact sizing | 1–5 scale: 1=minimal, 3=moderate, 5=massive uplift |
| Effort sizing | T-shirt: XS/S/M/L/XL; or story points; or person-weeks |

## Instructions

### Step 1: Write a Product Requirements Document (PRD)

**PRD Template:**

---
**Feature Name:** [Name]
**Author:** [PM Name] | **Date:** [Date] | **Status:** Draft / Review / Approved
**Engineering Owner:** | **Design Owner:** | **Launch Target:**

---

**1. Overview (TL;DR)**
One paragraph: what we're building, why, and the expected business impact.

**2. Problem Statement**
- What user pain point or business problem does this solve?
- What is the current experience? (describe the before state)
- What is the evidence this problem is real? (user research, support tickets, data)

**3. Goals and Non-Goals**
| Goals | Non-Goals |
|-------|-----------|
| ✅ Users can complete X without Y friction | ❌ This does not redesign the entire onboarding flow |
| ✅ Reduce support tickets about Z by 30% | ❌ This does not support mobile in V1 |

**4. User Personas**
Who are the primary users? List 1–3 personas with their role, context, and motivation.

**5. Functional Requirements**
List every user-facing behavior the feature must support, organized by user flow:
- FR-01: [Requirement]
- FR-02: [Requirement]

**6. Non-Functional Requirements**
- Performance: page load < 2 seconds at P95
- Availability: 99.9% uptime SLA
- Security: [specific requirements]
- Accessibility: WCAG 2.1 AA compliant

**7. Success Metrics**
- **Primary metric (north star):** e.g., 30-day retention rate for new users
- **Secondary metrics:** e.g., time-to-first-value, feature adoption rate
- **Guardrail metrics:** e.g., support ticket volume (must not increase > 5%)

**8. Risks and Mitigations**
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| [Risk] | High/Med/Low | High/Med/Low | [Plan] |

**9. Open Questions**
- [ ] Question 1 — Owner: [Name] — Due: [Date]

**10. Launch Plan**
- Alpha: [audience, date]
- Beta: [audience, date]
- GA: [audience, date]

---

### Step 2: Prioritize Features with RICE
RICE score = (Reach × Impact × Confidence) / Effort

**Reach**: How many users affected per quarter? (raw number)
**Impact**: Effect per user: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
**Confidence**: How sure are we? 100%=high, 80%=medium, 50%=low
**Effort**: Person-months required

```
Feature A: Reach=5000, Impact=2, Confidence=80%, Effort=2 months
RICE = (5000 × 2 × 0.8) / 2 = 4,000

Feature B: Reach=1000, Impact=3, Confidence=90%, Effort=0.5 months
RICE = (1000 × 3 × 0.9) / 0.5 = 5,400  ← prioritize this first
```

**MoSCoW for sprint planning:**
- **Must have**: Without this, the sprint/release fails (user can't complete core task)
- **Should have**: High value, but workaround exists without it
- **Could have**: Nice to have; cut if effort spikes
- **Won't have**: Explicitly deferred to future release; prevents scope creep

### Step 3: Write User Stories
Format: `As a [user type], I want [capability] so that [benefit].`

Rules for good user stories:
- Focus on the user's goal, not the implementation
- One story = one deliverable unit of value
- Small enough to complete in one sprint
- Testable: acceptance criteria can be written for it

**Example:**
> As a **free-plan user**, I want to **upgrade to Pro with one click from within the app** so that **I don't have to navigate to a separate billing page and lose my context.**

### Step 4: Write Acceptance Criteria (Given/When/Then)
For each user story, write 2–5 acceptance criteria in BDD format:

```
Scenario: Successful upgrade flow
  Given I am logged in as a free-plan user
  And I am on any page in the app
  When I click "Upgrade to Pro" in the nav bar
  Then I should see the upgrade modal with pricing details
  And the modal should pre-fill my account email
  
Scenario: Failed payment
  Given I am on the upgrade modal
  When I submit payment with a declined card
  Then I should see the error message "Payment declined. Please try another card."
  And my account should remain on the free plan
  And no charge should appear on my card
```

### Step 5: Define Product Metrics
For every feature, define metrics in three tiers:

**Tier 1 — Primary (North Star)**: The one metric that proves the feature is delivering value.
**Tier 2 — Secondary**: Supporting metrics that explain *why* the primary metric moved.
**Tier 3 — Guardrails**: Metrics that must NOT regress (existing feature health).

Example for an upgrade flow feature:
- **Primary**: Conversion rate from free to paid (target: +2pp in 90 days)
- **Secondary**: Modal open rate, modal → checkout rate, checkout → completed rate
- **Guardrails**: Free plan user satisfaction score (must not drop), support tickets about billing (must not increase > 10%)

## Examples

### Example 1: Write a PRD for a New Feature — In-App Notifications

**Input:** "We want to add in-app notifications so users don't miss important events."

**PRD excerpt:**

---
**Feature Name:** In-App Notification Center
**Status:** Draft | **Launch Target:** Q2 2024 | **Effort:** M (3 engineers, 6 weeks)

**Problem Statement:**
Users miss critical events (payment failures, team invitations, limit warnings) because they only receive emails, which have a 22% open rate. This results in 340 monthly support tickets from users who say they "didn't know" about an issue. Churn analysis shows 18% of churned users had an unresolved payment failure 7+ days before cancellation.

**Goals:** Enable users to see and act on critical account events without leaving the app. Target: reduce missed-event support tickets by 50% in 90 days.

**Non-Goals:** Push notifications (mobile), email digest redesign, third-party integrations.

**Requirements:**
- FR-01: Users can see a notification bell icon in the top nav with an unread count badge
- FR-02: Clicking the bell opens a dropdown with the 20 most recent notifications
- FR-03: Notifications have type (info/warning/error), title, body, timestamp, and optional CTA link
- FR-04: Users can mark individual or all notifications as read
- FR-05: System generates notifications for: payment failure, plan limit reached, team invite received, 7-day trial ending

**Primary metric:** Support tickets t