Product metrics

Product metrics

A metric earns its place by changing decisions. The architecture: one north star that proxies delivered value, a small tree of input metrics teams can actually move, and guardrails that catch the damage optimization causes elsewhere.

Method

1. Pick a north star that means value delivered. Not revenue (lagging, hides user harm) and not signups (vanity): a usage moment tied to the product's promise: orders delivered, documents collaborated on weekly, rides completed. Test: if this number doubles while everything else holds, is the business genuinely healthier? (see saas-metrics for the financial layer beside it).
2. Decompose into input metrics teams own. North star = f(activation rate, frequency, retention, capacity...): each team owns inputs it can move with shipped work (see user-activation, churn-analysis for two of the big ones); a team goaled on the north star alone has a metric it can only watch. The decomposition is the strategy made arithmetic (see okr-cascade).
3. Define every metric once, precisely. Numerator, denominator, time window, population, exclusions: written where dashboards link to it (see warehouse-modeling's metric-definition rule; saas-metrics for the canonical financial definitions). "Active user" with three definitions across three dashboards is how companies argue about reality instead of deciding.
4. Stand guardrails beside every goal metric. Optimizing checkout conversion can torch refund rates; engagement pushes can burn notification opt-outs and sleep: name the 2-4 metrics each initiative must not degrade, and check them in every experiment readout (see ab-test-design's guardrail arms). A goal metric without guardrails is an invitation to strip-mine.
5. Instrument events as a designed schema. Track the behaviorally-meaningful events (activation milestones, core actions, failure moments) with stable names and properties, versioned like any contract (see schema-evolution); ad hoc event sprawl produces dashboards nobody trusts (see data-quality-checks for keeping them honest). Wire the funnel from first touch through activation so drop-off is visible per step (see user-activation).
6. Review metrics as decisions, not weather. A cadenced review (weekly operating, monthly deep-dive) where each owned metric gets: trend vs target, diagnosis if off, and the action being taken: dashboards without a deciding forum are decoration (see dashboard-design, infrastructure-monitoring's same rule for systems). Retire metrics nobody has acted on in two quarters.

Boundaries

• Metrics proxy value; they are not value. Goodhart applies: every proxy optimized hard enough diverges from the thing it proxied: rotate scrutiny, keep qualitative channels (support tickets, interviews: see customer-interviews) beside the numbers.
• Small products and new bets lack statistical mass; use cohort inspection and direct user contact before dashboard-driving (see mvp-scoping).
• Privacy boundaries constrain instrumentation (consent, PII in events: see pii-handling); measurement design includes what you deliberately do not collect.