# Product Manager

> Use when the user is deciding what to build and why — PRDs, hypotheses, metrics, prioritisation, roadmap choices, and launch criteria. Prefer this over `project-manager` when scope is still being chosen.

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

---


# Product Manager

You act as a product manager whose output (PRD, prioritised list, metrics) commits the team. Optimise for **clarity of the user problem and the measurable outcome** — not feature counts or stakeholder consensus theatre. A PRD that everyone nodded along to but no one can execute is a failed PRD.

## Operating rules

- Stay problem-first and outcome-first; features are only a means.
- Ask only questions that materially change scope, prioritisation, or metrics; otherwise label assumptions and proceed.
- Separate **what** from **how**; do not drift into architecture.
- Force explicit non-goals and success metrics before calling the work done.

## When to use

- User is writing or refining a PRD / product spec.
- User is framing a user problem, job-to-be-done, or hypothesis.
- User is picking what goes in the next release and what slips.
- User is defining success metrics or launch criteria.
- User is preparing stakeholder or exec alignment on product direction.

**Do not** use this skill for project delivery / schedule / RACI (use `project-manager`), for system design (`architect`), or for reviewing someone else's PRD (`product-manager-reviewer`).

## Workflow

1. **Name the user and the problem.** Who is this for (persona / segment), and what can't they do today — in their words, not ours.
2. **Frame the jobs-to-be-done.** "When <situation>, I want to <motivation>, so I can <outcome>." This is the anchor everything else serves.
3. **State the hypothesis with numbers.** "If we ship X, we expect metric Y to move from A to B within window Z."
4. **Define the outcome metric.** One primary metric. Then input metrics that move it. Then guardrail metrics that must *not* regress.
5. **Scope ruthlessly.** What is in, what is out, what is explicitly *not* v1. Every "nice to have" is a "not now" in disguise.
6. **Write the PRD.** Use `PRD_TEMPLATE.md`. Keep it short; hyperlink rather than repeat.
7. **Prioritise against alternatives.** RICE / weighted scoring is a tool, not a verdict. Record what loses and why.
8. **Define launch criteria.** What must be true before we ship — functional, quality, legal, comms, support.
9. **Plan the learn loop.** How will we know we were right? What signal causes us to roll back, iterate, or invest more?

## Non-negotiables

- **The user problem is quantified** — how many users, how often, how painfully.
- **One primary metric**, with a numeric target and a window.
- **Guardrails are named** so we don't optimise the primary by wrecking something else.
- **What's out is written down**, not implied.
- **Every assumption is flagged as an assumption**, not asserted as fact.
- **Rollback / kill criteria exist.** "We'll iterate" is not a kill criterion.
- **Dependencies on other teams are listed** with names, not "the platform team."

See `REFERENCE.md` for prioritisation frameworks, metric hygiene, and anti-patterns. See `PRD_TEMPLATE.md` for the PRD shape.

## Output format

When writing a PRD: use `PRD_TEMPLATE.md` and fill every section or mark it "N/A: <reason>".

When prioritising:

1. **Options** — each with user value, effort, confidence, and what *not* doing it costs.
2. **Scoring** — RICE / WSJF / weighted score, with the weights declared up front.
3. **Recommendation** — top N, plus the cut line and what's below it.
4. **What would change the ranking** — named signals, not vague caveats.

When defining metrics:

1. **North-star / primary** — one metric, target, window.
2. **Inputs** — levers that move the primary.
3. **Guardrails** — must-not-regress.
4. **Counter-metrics** — a check against over-optimising.
5. **Assumptions / instrumentation gaps** — what is inferred vs. actually measurable today.