# Product Manager

> Product/program management for software products. Use when defining product strategy, writing PRDs, prioritizing roadmap, running discovery, setting success metrics, managing stakeholders, planning launches, or making build/buy/cut decisions. Covers vision, user research synthesis, RICE/ICE/Kano/MoSCoW prioritization, user stories, acceptance criteria, sprint planning, metrics (North Star, activation, retention, NPS), A/B testing, go-to-market, and business cases. Keywords: PM, product manager, PRD, roadmap, prioritization, RICE, user stories, acceptance criteria, North Star metric, activation, retention, A/B test, launch, stakeholder, JTBD, MVP.

- Skill: `praxstack/product-manager` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add praxstack/product-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/praxstack/product-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: praxstack (https://skillmd.com/u/praxstack)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/praxstack/product-manager

---


# Product Manager

**Audience:** Product and program managers shipping software products.

**Goal:** Make the right bets — decide WHAT to build and WHY, measure whether it worked, iterate — without overstepping HOW engineering builds it.

## Core Responsibilities

- **Own the problem, not the solution.** Fall in love with the user's problem; the solution is a hypothesis that gets tested and changed. Ship the cheapest experiment that can invalidate the hypothesis.
- **Write requirements engineers can build from without 15 clarification questions.** A vague PRD is a tax paid by the whole team, forever. Clear PRDs explain the WHY, define success metrics, and make scope boundaries explicit (including non-goals).
- **Prioritize under scarcity.** You always have more demand than capacity. Prioritization frameworks (RICE, ICE, Kano, MoSCoW) are aids, not oracles — the real job is weighing confidence, strategic fit, and opportunity cost.
- **Instrument before you launch.** If you cannot measure success, you cannot claim it. Define leading and lagging indicators, wire analytics early, set baselines before changes.
- **Say no with reasons.** Every "no" preserves capacity for a "yes." Link refusals to explicit tradeoffs, not personal taste.
- **Close the feedback loop.** Users who give feedback and hear nothing back stop giving feedback. Acknowledge, update on prioritization, notify on ship.

## Decision Framework

**What does PM decide vs. engineering decide?**
- **PM decides:** what features, who it's for, when it launches (with eng input), what "done" means (acceptance criteria), what metric it moves.
- **Engineering decides:** architecture, tech stack, implementation approach, estimates, when it's technically ready.
- **Collaborative:** scope-vs-timeline tradeoffs, tech-debt budget, build-vs-buy.

Do not specify the implementation. Do not skip over engineering to pick libraries. Do not commit timelines without eng input.

**Prioritization: pick the right tool**
- **RICE** (Reach × Impact × Confidence / Effort): compares features at similar scope/granularity. Most useful when team debates a backlog.
- **ICE** (Impact × Confidence × Ease): faster RICE for experiments and small bets.
- **Kano:** separates basic (expected), performance (linear satisfaction), and delighters (unexpected). Use when choosing between "fix" vs "add."
- **MoSCoW** (Must/Should/Could/Won't): scope-cutting within a release.
- **Value-vs-Effort 2x2:** quick triage; "high value, low effort" beats everything.
- **Opportunity Solution Tree** (Teresa Torres): trace solutions back to outcomes through opportunities. Best for discovery, not just prioritization.

No framework is neutral — the weights encode your strategy. Two teams with the same RICE spreadsheet will get different rankings because one weighted confidence higher.

**Scope-vs-timeline tradeoff:** If shipping on date is critical, cut scope (not quality). If scope is critical, push date. Never cut quality — the bug budget compounds.

**Build / buy / partner:**
- Build when: it's core differentiation, the moat is real, team has the skill.
- Buy when: it's commodity, existing products meet 80% of need, ROI payback <18 months.
- Partner when: you need the capability short-term, a build is years out, partner has distribution.

**Discovery vs delivery allocation:** Strong teams split ~30% discovery (talking to users, testing concepts, exploring) and 70% delivery. Zero-discovery teams ship features nobody wants.

## Quality Gates / Checkpoints

**Before writing a PRD:**
- Problem validated with >= 5 user conversations (not assumptions).
- North Star or primary success metric defined.
- Non-goals explicitly listed (what you're NOT building).

**Before sprint commitment:**
- User stories INVEST-compliant (Independent, Negotiable, Valuable, Estimable, Small, Testable).
- Acceptance criteria are testable (given/when/then).
- Designs attached if UI is involved.
- Dependencies identified and scheduled.

**Before launch:**
- Success metrics + measurement wired (not TODO).
- Rollout plan exists (beta %, expand %, monitoring, rollback).
- Support docs, help articles, customer success briefed.
- Go/no-go criteria defined with named thresholds (not vibes).

**Post-launch:**
- Metrics reviewed against predictions within 1-2 weeks.
- Learnings documented (what we expected vs what happened).
- Decision to double-down, iterate, or kill.

## Anti-Patterns

- **NEVER** promise a delivery date without engineering buy-in. "By Q2" written in a PRD without a conversation is fiction.
- **NEVER** write PRDs as "build a feature like X at company Y." Start from user problem and metric.
- **NEVER** ship without instrumentation. Retrofitting analytics later means you lose the launch window to learn.
- **NEVER** ship without explicit success criteria. "Users like it" is not measurable.
- **NEVER** use "feature parity with competitor" as a strategy. You're always a step behind and losing margin.
- **NEVER** conflate "users requested it" with "users need it." 10 support tickets asking for dark mode may indicate 10 loud people, not 10,000 quiet ones — validate with data.
- **NEVER** rank based on HiPPO (Highest-Paid Person's Opinion). Frame decisions in user/business terms.
- **NEVER** build what users ask for literally. "Faster horse" — extract the underlying need.
- **NEVER** skip the launch retro. If it launched and you moved on without learning, you paid for the experiment and threw away the result.
- **NEVER** tell engineering HOW to build. That's their domain. Tell them WHAT and WHY.
- **NEVER** extend sprint mid-sprint. Scope changes go to the backlog and get re-prioritized.
- **NEVER** write a 30-page PRD for a 3-week feature. The PRD serves the project; not vice versa.

## Standard Workflow

1. **Discovery.** Talk to users (5-10 interviews), synthesize patterns, define the job-to-be-done. Frame the problem.
2. **Strategy alignment.** Tie the opportunity to a strategic theme / OKR / North Star. If it doesn't tie, push back or explain the exception.
3. **Prioritize.** Apply a framework (RICE/ICE/Kano/MoSCoW). Compare against alternatives. Articulate the opportunity cost of saying yes.
4. **Write PRD.** Problem, goals, metrics, user stories, acceptance criteria, non-goals, rollout plan, risks. Link to designs, research.
5. **Engineering review (CHECKPOINT).** Feasibility, scope, estimates. Architecture proposal from eng. Resolve "can we?" before "when will we?"
6. **Plan sprints.** Break into shippable chunks. Define "done" for each. Keep scope flexible, timeline firm (or vice versa — pick one).
7. **Stay in the loop.** Standups to listen for blockers, not to direct. Answer product questions in minutes, not days. Accept/reject work at story level.
8. **Ship staged.** Soft launch to 5-10% — expand with data — GA. Rollback plan documented.
9. **Measure.** Watch leading indicators hourly on launch day, daily for a week, then weekly. Check against pre-launch predictions.
10. **Retro + iterate.** What happened vs what we expected? What did we learn? What do we change?

## Deliverables Contract

**PRD must have:**
- Problem statement (user + business)
- Target users (persona or segment)
- Goals and success metrics (specific, measurable)
- Non-goals (explicit scope exclusions)
- User stories with acceptance criteria
- High-level solution (not implementation)
- Dependencies (cross-team, external)
- Rollout plan
- Risks + mitigations
- Open questions + decision owners/dates

**User story must have:**
- "As a X, I want Y, so that Z" format (role, action, benefit — not feature list)
- Acceptance criteria in given/when/then format
- Attached designs if UI-involved
- Estimable (team has enough info to size)
- Testable (pass/fail is unambiguous)

**Launch plan must have:**
- Pre-launch checklist (what must be true to ship)
- Rollout phases with % and gates between
- Monitoring and alerting
- Rollback procedure (who pulls the trigger, how)
- Communication plan (users, internal, partners)
- Success criteria (leading and lagging)
- Post-launch retro schedule

**Status update (weekly) must have:**
- Wins (shipped / metric moves)
- In progress (what + confidence level)
- Blockers with owners
- Asks of stakeholders
- Upcoming milestones

## References

- `references/prioritization-frameworks.md` — RICE, ICE, Kano, MoSCoW, Value/Effort, Opportunity Solution Tree. CONDITIONAL (load when prioritizing).
- `references/prd-templates.md` — PRD structures, user story + acceptance-criteria patterns, non-goals, rollout plans. MANDATORY before writing a PRD.
- `references/metrics-and-analytics.md` — North Star, acquisition/activation/retention/revenue/referral, A/B testing pitfalls, cohort analysis. CONDITIONAL (load when defining metrics or interpreting data).
- `references/agile-sprint-planning.md` — sprint ceremonies, backlog grooming, INVEST, estimation, capacity planning. CONDITIONAL (load when planning sprints).
- `references/go-to-market.md` — launch phases, positioning, competitive analysis, business case + ROI. CONDITIONAL (load for launches or strategic bets).