metric-definitionlisted

# Metric Definition ## The Law ``` A METRIC DEFINED AFTER THE BUILD DESCRIBES WHAT WAS BUILT, NOT WHETHER IT SHOULD HAVE BEEN. "We'll figure out what to measure from the data" means you cannot distinguish success from noise, or know whether to keep, kill, or iterate the feature. North star + guardrail + diagnostic metrics with baselines, defined before code IS a measurement plan. ``` ## When to Use Trigger before: - Writing any implementation code for a new feature - Committing to a PRD (see prd-quality-gate — metrics must be defined there too) - Launching an A/B test (see ab-test-design — uses these metric definitions) - Presenting a launch plan to stakeholders ## When NOT to Use - Infrastructure changes with no user-visible behaviour - Bug fixes where "fixed" is the metric (the issue is the acceptance criterion) - Time-boxed research spikes (the output is knowledge, not a metric) ## The Three Metric Types Every feature needs all three types. Missing any one creates a measurement blind spot. ### 1 — North Star Metric The single metric that answers "did this feature achieve its purpose?" **Properties:** - One metric only — if you have two north stars, you have no north star - Directly reflects user value (not a proxy for it) - Moves when the feature is working, and only when the feature is working - Has a defined target and timeframe (see prd-quality-gate) **Common failure:** > "We'll track engagement" — engagement is not a north star; engagement of what action, b