Define how a feature's success will be measured before it's built — one primary metric with target, timeframe, and baseline; guardrail and counter-metrics; an instrumentation plan naming every event; and a pre-committed decision rule for what happens if the target is missed. Use when the user asks "how do we know this worked", needs KPIs or success criteria for a feature, or wants a measurement/instrumentation plan before launch.
Pack product-managerTier standardJob Decide what to buildv0.1.1
In Claude Code, with the product-manager plugin installed, invoke it as:
/product-manager:success-metrics
Try it
A realistic prompt from the skill's acceptance evals:
Define success metrics for this feature: a unified customer view for our support agents, merging tickets, orders, and chat history into one screen. Goal from the PRD: cut median ticket handle time. Current handle time lives in our Zendesk dashboard.
What a good result looks like
Exactly one primary metric, and it's an outcome, not an output or a vanity count. The doc states why it was chosen over the runner-up.
Baseline, target, timeframe all present — or "measure baseline" is explicitly milestone 1. No target hangs in the air.
Every metric maps to a named event marked exists/must-build. A metric without an event is fiction with a chart placeholder.
The counter-metric names the gaming path. "Could this number improve while the user's life gets worse?" has a written answer.
The decision rule is action-shaped and pre-committed — who does what at which threshold — not "we'll review the data".
Guardrails have current values and alert thresholds, so "don't degrade X" is checkable, not sentimental.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 75% of its checks, against 61% without it, and a blind judge preferred it. How skills are checked
24 assertions across 4 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Exactly one primary metric, and it is an outcome (handle time), not an output or vanity count — with the runner-up named and the choice justified
The primary has baseline (with source), target, and timeframe including a patience window — or measuring the baseline is explicitly milestone 1
2-3 leading indicators, each with a causal sentence
2-4 guardrails with current values and alert thresholds (or a week-1 baseline plan for brand-new surfaces)
A counter-metric names the specific gaming path (e.g. premature ticket closure → reopen rate)
Every metric maps to a named event marked exists/must-build, and must-build events are launch blockers
A pre-committed, action-shaped decision rule names who does what at which threshold
No metrics are invented — with no goal stated, the output is BLOCKED: need the feature's goal
The BLOCKED output routes to prd-draft (or names the goal as what to rerun with)
No primary metric, instrumentation table, or decision rule appears
Does not set a target of donating again within 30 days; recognises the 12-week minimum gap between donations and uses a timeframe consistent with it
Uses or reconciles the export's baseline (4,410 of 15,200, about 29%) rather than taking the brief's 35% as fact
Deals with the TV campaign starting the same day as a confound — for example a holdout group or comparison that separates the SMS effect — rather than relying on a simple before-and-after
Includes at least one measure that would show the reminders causing harm, such as opt-outs or complaints
Acknowledges the stated data gaps (no click data from the SMS vendor; phone bookings not tagged by channel) and does not rely on data that is not collected
Does not invent baselines or figures not in the brief; any new number is labelled as an assumption or a target
Fits on about one page
Gives a short set of measures without asking questions first
A few bullets — no more than about 8 bullets or 200 words
Picks one main measure tied to a plausible purpose of pre-ordering (for example less food waste or shorter lines) and says what change would count as success, rather than listing many equal metrics
Includes something to watch for that would mean the change is hurting, such as fewer students eating lunch or students who miss the morning order going without
Measures are things a cafeteria manager can actually count without new data systems (for example meals prepared versus taken, or timing the line)
Does not invent current numbers (meals served, waste amounts) as facts
Plain English with no data jargon
When it should and shouldn't activate
Should activate:
How do we know this feature worked? Define the KPIs
Set up success criteria and an instrumentation plan before we launch
What should we measure to judge the new onboarding flow?