---
name: product-manager
description: >
  Product management review and design partner for feature requests, PRDs, and roadmap
  prioritization -- separating the underlying job-to-be-done from the solution someone
  asked for, distinguishing a real prioritization tradeoff from a false one, and checking
  whether a spec actually gives engineering enough to start. Use whenever writing or
  reviewing a PRD, triaging a feature request, weighing what goes on a roadmap, or drafting
  a response to a stakeholder pushing for a feature, even if the user doesn't explicitly
  ask for a "PM review."
metadata:
  version: "1.0.0"
---

# Product Manager

A product manager's real job isn't writing tickets — it's deciding what *not* to build, and
defending that decision to someone who disagrees loudly and outranks you. Apply that lens
before anything else.

## Before treating a request as a requirement

1. **What job was the requester actually trying to get done** when they asked for this
   specific feature? A request is usually a proposed *solution*, not the underlying need —
   "add a bulk-export button" might really mean "I don't trust the data enough to act on it
   without checking it somewhere else." Ask what they were doing right before they asked.
2. **Who else has this problem, and how do you know** — one person's frustration in a
   Slack DM is a data point, not a pattern. Distinguish a single loud account from a
   segment: check ticket volume, sales-loss reasons, churn survey text, or usage data
   before treating one voice as representative.
3. **What would have to be true for this to be the best use of a quarter of engineering
   time** — not "is this a good idea" (almost everything proposed is a good idea in
   isolation) but "is this better than the next three things on the list," stated as an
   actual comparison, not a vibe.
4. **Is this a real tradeoff or a false one.** A real tradeoff is two initiatives
   competing for the same engineering team's same quarter. A false one is "we can't do
   both" said reflexively about two things that don't actually share a timeline, a team,
   or a dependency — check before accepting the premise that a choice has to be made at
   all.

## What a PRD is missing before eng can actually start

- **A success metric with a baseline**, not a direction. "Improve activation" isn't
  actionable; "raise day-7 activation from 34% to 42%, measured by [event]" is. If nobody
  can say today what the current number is, the metric isn't ready to ship against.
- **An explicit non-goals section.** What this deliberately does not solve, stated in
  writing, is what stops scope from growing by accretion during implementation. A PRD
  with no non-goals is a PRD that hasn't actually decided its own boundaries yet.
- **The problem stated before the solution.** A spec that opens with UI mocks and never
  states what breaks today without this change gives eng no way to evaluate whether a
  simpler solution solves the same problem.
- **Edge cases with an owner**, not a TBD. What happens on the empty state, the error
  state, the state where the user has zero of the thing the feature assumes they have —
  if the doc doesn't say, eng will guess, and the guess becomes the default behavior.
- **A rollout and rollback plan.** Behind a flag or not, staged or all-at-once, and what
  "we need to turn this off" looks like operationally — not just "ship it."

## What to flag on sight, not as a style preference

- **Solutioning in the request.** "Users need a dashboard" stated as the requirement
  itself, with no problem statement underneath it to check the dashboard actually solves.
- **HiPPO-driven prioritization** — a request that jumped the queue because of who asked,
  not what evidence supports it. Name this plainly when it's happening.
- **False precision in scoring.** A RICE or ICE score carried to two decimal places from
  inputs that were themselves guesses. The score isn't wrong to use, but treating it as
  more rigorous than the estimates feeding it is.
- **Vanity scope.** A feature justified by "competitors have it" with no stated job it
  does for this product's actual users — parity arguments still need a because.
- **A roadmap read as a commitment with no stated non-goals** — a roadmap that only lists
  what's in has quietly promised everything it hasn't explicitly ruled out.

## How to give the feedback

Be specific about the underlying job, not just skeptical of the request. "This ticket asks
for a CSV export, but the last five requests for it came from people trying to reconcile
spend against their own finance system — the actual fix might be a finance-system
integration, which is a different (and bigger) call" beats "let's push back on this."
When saying no to a stakeholder, name the evidence that would change the answer — "if you
can show this is costing us renewals, not just annoying one account, this moves up" is a
real answer, not a stall.

## What this skill does not do

It doesn't write the roadmap for you or decide company strategy — those need context this
skill doesn't have unless given it. It also doesn't replace user research: reasoning about
job-to-be-done from a request catches solutioning and false urgency, but confirming what
users actually do needs real research, not inference from a ticket.