Purpose
Turn a fuzzy product goal into a defensible measurement framework — a single primary metric, supporting input metrics, and guardrail metrics that catch the damage a naive KPI would hide — so a team knows exactly what "success" means before shipping and what would signal it's going wrong.
When to Use
Invoke this skill when the user asks to:
- Define success metrics or KPIs for a feature launch, roadmap bet, or initiative
- Pick a primary metric and guardrail metrics for an A/B test or experiment
- Turn an OKR or team goal into something measurable
- Figure out what to track for a specific product area and user segment
- Sanity-check whether a chosen KPI could be gamed or cause unintended harm
Inputs Required
Before starting, collect:
- Product area: The surface or workflow being measured (e.g., onboarding, checkout, search, notifications)
- Team goal: What the team is trying to achieve, in plain language
- User segment: Who this is for (new users, power users, free vs. paid, a specific persona)
- Time horizon: When success is judged — a launch window, a quarter, a year
- Business objective it ladders to: Revenue, retention, engagement, activation, cost, or trust
- Current baseline (if known): Where the primary metric stands today
- Known constraints: Instrumentation gaps, low traffic, or metrics that can't be captured
If baseline or time horizon is missing, propose a reasonable default and label it as an assumption.
Instructions
Step 1: Classify the Goal Type
Map the team goal to its underlying objective, because the metric family depends on it:
- Acquisition: New users, signups, activation of first value
- Activation: Reaching the "aha" moment or first meaningful action
- Engagement: Frequency, depth, or breadth of use
- Retention: Users returning over time (N-day, rolling, or cohort retention)
- Revenue: Conversion, ARPU, expansion, LTV
- Efficiency/Cost: Time-to-value, support load, operational cost
- Trust/Quality: Error rates, satisfaction, safety, reliability
State the classification explicitly and note if the goal spans two families.
Step 2: Select the Primary Success Metric
Choose exactly one metric that best expresses the goal for this segment. Apply these tests:
- Movability: The team's work can plausibly move it within the time horizon
- Attributability: A change is more likely caused by this initiative than by noise or other teams
- Directional clarity: Everyone agrees which direction is "good"
- Prefer a rate or ratio (e.g., activation rate) over a raw count when comparing across segments or time
- Avoid vanity metrics (total signups, page views) unless they directly ladder to the objective
Define it precisely: numerator, denominator, population (the user segment), and measurement window.
Step 3: Define 3-5 Supporting / Input Metrics
Identify the leading indicators and drivers that move the primary metric. These give the team something to act on before the primary metric fully resolves.
- Break the primary metric into its input drivers (e.g., if primary is activation rate, inputs might be step-completion rates and time-to-first-action)
- Include at least one early signal that moves faster than the primary metric
- For each: name, precise definition, and why it drives the primary
Step 4: Define 2-4 Guardrail Metrics
Identify what could break if the team over-optimizes the primary metric. Guardrails protect against local wins that cause global harm.
- Cover the common failure modes: engagement quality (are we driving hollow clicks?), retention (did we win the moment but lose the user?), cost/support load, revenue leakage, and trust/error rates
- For each guardrail, state the direction it must not move and a rough threshold that would trigger a stop or review
- At least one guardrail should protect a segment outside the target segment (e.g., an onboarding change shouldn't hurt existing power users)
Step 5: Run the Counter-Metric / Gaming Check
For the primary metric, answer: "If someone were rewarded only on this number, what's the laziest way to move it that hurts the business?" Name the gaming risk and confirm a guardrail covers it; if not, add one.
Step 6: Set Targets and Rationale
For the primary metric and each supporting metric, propose a target:
- Anchor to the baseline where provided; otherwise state the assumed baseline
- Recommend a target range (conservative / expected / stretch) rather than a single point
- Give a one-line rationale grounded in the horizon, effort, and typical magnitude of change for that metric type
- Flag if the segment traffic is likely too low to reach statistical significance in the horizon
Output Format
- Structure: Framework document with a metric hierarchy — primary at top, supporting and guardrails below, followed by targets and risks
- Length: 700–1,000 words
- Format: Structured document with labeled sections; metric definitions as bullets; targets in a compact table
- Sections: Goal Classification → Primary Success Metric → Supporting Metrics → Guardrail Metrics → Counter-Metric Check → Targets & Rationale → Open Risks / Instrumentation Notes
- Tone: Analytics lead — precise, skeptical of vanity, opinionated about tradeoffs
Quality Checklist
Before delivering output, verify:
- [ ] Exactly one primary metric is named — not a list of co-equal metrics
- [ ] Every metric is defined with numerator, denominator, population, and window — not just a name
- [ ] Between 3 and 5 supporting metrics and between 2 and 4 guardrail metrics are present (count them)
- [ ] At least one guardrail protects a segment outside the target segment
- [ ] The counter-metric / gaming check names a specific way the primary could be gamed and confirms a guardrail covers it
- [ ] Targets reference the baseline (real or assumed) and are given as ranges, not single points
Notes
- The most common failure is choosing a raw count as the primary metric — it makes cross-segment and cross-period comparison meaningless. Push for a rate whenever possible.
- If the primary metric and business objective don't obviously ladder together, surface that gap explicitly rather than papering over it.
- For low-traffic segments, recommend a longer horizon or a proxy metric that resolves faster, and say so plainly instead of promising significance that won't arrive.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills