Define what success looks like in numbers. Work through each step — don't jump to a list of metrics without grounding them in the goal first.
Step 1: Identify the Goal
Before picking metrics, answer:
- What job does this feature serve? What progress is the user trying to make? (Reference the jtbd skill if available.)
- What outcome matters to the business? Revenue, retention, efficiency, expansion — pick one.
- What behavior change are you expecting? Users should do more of X, less of Y, start doing Z.
If you can't state the goal in one sentence, the metrics will be unfocused. Push for clarity.
Step 2: Define a Primary Metric
Pick the ONE number that best represents success. This is the metric the team checks every morning.
How to choose — the 3 A's:
| Test | Question | Bad example | Good example |
|---|---|---|---|
| Actionable | Can the team change this number with their work? | Total registered users (too broad) | Weekly active users of this feature |
| Accessible | Can everyone on the team understand and check it? | Custom composite score | % of users who complete core action |
| Auditable | Can you verify the data is correct? | Self-reported satisfaction | Event-tracked completion rate |
Common primary metrics by goal:
| Goal | Primary metric |
|---|---|
| Adoption | % of eligible users who use the feature in first 7 days |
| Engagement | Weekly active usage (sessions, actions, or time) |
| Retention | % still using after 30 days |
| Efficiency | Time to complete task (before vs. after) |
| Revenue | Conversion rate or revenue per user |
| Quality | Error rate or task success rate |
State it precisely: "% of users who create at least one invoice within 7 days of first seeing the feature" — not "adoption."
Step 3: Define Supporting Metrics
Leading indicators
Predict future success. Move before the primary metric does. Use these to course-correct early.
| Example | What it predicts |
|---|---|
| Activation rate (completed setup) | Future retention |
| Feature discovery rate (saw the entry point) | Future adoption |
| Time to first value | Future engagement |
| Onboarding completion | Future active usage |
Lagging indicators
Confirm past success. Move slowly. Use these to validate that early signals were real.
| Example | What it confirms |
|---|---|
| 30/60/90-day retention | Sustained value |
| Net revenue retention | Business impact |
| NPS / CSAT change | User sentiment shift |
| Support ticket volume (down) | Reduced friction |
Guardrail metrics
Things that should NOT get worse when the feature launches. Set these before shipping.
| Guardrail | Threshold |
|---|---|
| Page load time | Must stay under current p95 |
| Error rate | Must not increase >0.1% |
| Existing feature usage | Must not drop (cannibalization check) |
| Support ticket volume (up) | Spike is okay for 1 week, not 4 |
| Unsubscribe rate | Must not increase after announcement emails |
If a guardrail breaks, investigate before celebrating the primary metric.
Step 4: Anti-Metrics — What NOT to Track
Vanity metrics feel good but don't inform decisions. Ignore these:
| Vanity metric | Why it's misleading | Track this instead |
|---|---|---|
| Total signups (all time) | Only goes up, tells you nothing | Weekly new active users |
| Page views | Traffic without context | Conversion rate from page |
| Total features shipped | Output, not outcome | Adoption rate per feature |
| App downloads | Acquisition without activation | Day-7 retention |
| Time on page (alone) | Could mean engaged or confused | Task completion rate |
Rule of thumb: If a metric can only go up and never triggers action, it's vanity.
Step 5: Instrumentation Plan
Metrics are useless without reliable tracking. For each metric, define:
| Event name | Trigger | Properties | Where tracked |
|---|---|---|---|
feature_viewed | User sees the feature entry point | user_id, source, timestamp | Analytics (e.g., Amplitude, Mixpanel) |
feature_activated | User completes core action for first time | user_id, time_to_activate, timestamp | Analytics |
feature_used | User completes core action (any time) | user_id, session_id, timestamp | Analytics |
feature_error | Something fails | user_id, error_type, timestamp | Error tracking (e.g., Sentry) |
Instrumentation checklist:
- Events fire in both frontend and backend where appropriate
- User ID is attached to all events (for cohort analysis)
- Timestamps are consistent (UTC)
- Properties include enough context to segment (source, plan, cohort)
- Events are tested in staging before launch
- Dashboard or report is built before launch day
- Team knows where to check metrics and how often
Metrics Template
Use this table as the deliverable:
| Metric | Type | Target | How to Measure |
|--------|------|--------|----------------|
| [Primary metric] | Primary | [specific number] | [event/query] |
| [Leading indicator 1] | Leading | [specific number] | [event/query] |
| [Leading indicator 2] | Leading | [specific number] | [event/query] |
| [Lagging indicator] | Lagging | [specific number] | [event/query] |
| [Guardrail 1] | Guardrail | [must not exceed X] | [event/query] |
| [Guardrail 2] | Guardrail | [must not exceed X] | [event/query] |If You Can Only Track 3 Things
When instrumentation budget is tight, track exactly these:
- Adoption — did users find and try it? (
feature_activated/ eligible users) - Completion — did they succeed at the core task? (
task_completed/task_started) - Return — did they come back? (
feature_usedwhereusage_count > 1within 14 days)
These three form a funnel: discovered it, got value, came back. Everything else is refinement.
Output
Deliver the metrics plan as a document with:
- Goal — one sentence
- Primary metric — name, definition, target
- Supporting metrics — leading, lagging, guardrails in table format
- Instrumentation plan — events, properties, where tracked
- Anti-metrics — what you're deliberately not tracking and why