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 tagged "missed-event" (target: −50% in 90 days) Secondary: Notification open rate, CTA click rate per notification type Guardrails: Page load time on nav (must stay < 200ms), email open rate (must not drop)

Example 2: Prioritize a Feature Backlog

Input: 5 features competing for next quarter's roadmap.

Feature	Reach	Impact	Confidence	Effort (months)	RICE Score
SSO / SAML login	800 enterprise users	3 (massive — blocks enterprise sales)	90%	2	1,080
Dark mode	12,000 all users	0.5 (minimal productivity gain)	80%	1	4,800
Bulk CSV export	2,500 power users	2 (high — replaces manual workaround)	90%	0.5	9,000 ← #1
AI summary feature	5,000 users	2 (high)	50%	3	1,667
Mobile app	12,000 all users	2 (high)	70%	8	2,100

Recommendation:

Bulk CSV export (RICE: 9,000) — quick win, clear ROI
Dark mode (RICE: 4,800) — broad reach, low effort
Mobile app (RICE: 2,100) — high effort; plan for H2
AI summary (RICE: 1,667) — deprioritize until confidence improves
SSO (RICE: 1,080) — low RICE score but strategic; fast-track if enterprise deal depends on it

Best Practices

Write the success metrics before writing requirements—it clarifies what you're actually building
Every requirement should map to a user need; delete requirements that don't
Invite engineering into PRD review early—they'll catch infeasibility and suggest better approaches
Keep the PRD to 2–4 pages; appendices for edge cases and technical detail
Version your PRD (v0.1 draft, v1.0 approved) and record who approved it and when
"Non-goals" are as important as goals—they prevent scope creep

Common Mistakes

Writing requirements as solutions ("Add a button that…") instead of problems ("Users need to…")
Including too many must-haves: if everything is a must, nothing is
Skipping acceptance criteria: engineers will interpret requirements differently without them
Defining success only by shipping, not by user behavior change
Ignoring guardrail metrics: a new feature that improves one thing but breaks another is not a success
Writing a PRD in isolation: no engineering or design input until handoff

Tips & Tricks

Use the "5 Whys" to make sure you're solving the root cause, not a symptom
For ambiguous requirements, write what the UI should say—even rough copy clarifies intent
A one-page feature brief (problem + proposed solution + success metric) is faster to align on than a full PRD; use it to get buy-in before writing the full doc
Add a "North Star Question": "How will we know in 90 days if this feature succeeded?" Answer it in the metrics section
Link the PRD to the relevant user research, data analysis, and design mockups in a "references" section

product-manager