Metrics Design

The metric that almost killed a product

A growth team at a consumer app was measured on daily active users (DAU). They hit their targets consistently — but the product was slowly dying. Retention was falling. Revenue per user was flat. The team had found many creative ways to drive DAU: aggressive push notifications, dark-pattern re-engagement flows, even counting a user as "active" if they opened a notification without touching the app.

The metric was going up. The business was going down. They had optimized for the measure, not the thing the measure was supposed to represent.

This is Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." It's not a corner case — it's the default outcome of poorly designed metrics systems.

The three-layer metrics framework

Most strong product teams organize their metrics into three layers that answer three different questions:

1. North star metric

The single number that best captures whether your product is delivering value to users and to the business. It's your long-term health indicator. Moving it should feel meaningful, and it shouldn't be easily gamed.

Good north star metrics sit at the intersection of user value and business value. Spotify's is time spent listening. Airbnb's is nights booked. Notion's is weekly active editors (not just viewers). Each captures the core value exchange.

2. Input metrics

Also called leading indicators or driver metrics. These are the upstream behaviors that, when they move, tend to cause the north star to move. They're more actionable than the north star because teams can directly influence them.

If Spotify's north star is listening time, input metrics might include: new playlist creates per user, podcast starts in first week, search-to-play conversion, discovery feature engagement. Each of these, when it improves, tends to cause listening time to grow.

3. Guardrail metrics

Metrics you're not trying to move, but that you'd care deeply about if they moved against you. They protect against teams optimizing input metrics in harmful ways.

If the podcast team is growing listening time by making it harder to skip episodes, the guardrail is user satisfaction (measured via rating, cancellation rate, or NPS). If the notification team is growing DAU by spamming users, the guardrail is unsubscribe rate.

Leading vs lagging indicators

Lagging indicators measure outcomes — they confirm what already happened. Revenue, churn, NPS. They're important but slow. By the time they move, the cause is often weeks or months in the past.

Leading indicators predict future outcomes — they're correlated with where the lagging metric is heading. They move earlier and give you time to act.

Vanity metrics: the ones that feel good but don't decide anything

Vanity metrics are numbers that go up and make people feel good, but don't change any decision you'd make. They're usually easy to move, hard to connect to outcomes, and beloved by stakeholders who want to report wins.

The test for vanity: "If this metric doubled tomorrow, what would we do differently?" If the answer is nothing, it's a vanity metric. Cut it from your review deck.

How teams game metrics — and how to prevent it

Goodhart's Law is automatic. The moment a metric becomes a team's goal, people find ways to hit it that don't require doing the underlying thing. This isn't malice — it's how incentives work. Your job as a PM is to design metrics that are hard to game without doing the real work.

Click below to see common gaming scenarios and their consequences:

The HEART framework

Google's HEART framework is a structured way to think about user experience quality at scale. It's not a replacement for a metrics tree, but it's a useful lens for making sure you're not missing entire categories of user health.

HEART is most useful early in planning. Running through the five letters will often surface a category of user health you'd otherwise ignore — particularly Happiness and Task Success, which product teams frequently skip in favour of purely quantitative metrics.

Counter metrics: the PM's safety net

A counter metric is a metric that should move in the opposite direction if you're gaming your primary metric. The idea is simple: pair every metric you're optimizing with one that catches the failure mode.

Defining "active" — the decision most teams skip

"Active user" is the most-cited and least-defined metric in product. Before you can track it, you need to answer:

• What counts as active? Opening the app? Completing a core action? Using a specific feature?
• Over what time window? Daily, weekly, monthly? The right window depends on your product's natural usage frequency.
• Which users are included? All users? Paying only? Above a certain age or region?

A project management tool with one login per week is highly engaged. A news app with one login per week is churning. "Active" means different things for different products — and using the wrong definition produces metrics that look healthy and aren't.

PM Playbook — Questions to ask

• What's our north star? — one number that captures user value and business health simultaneously
• What are the input metrics that cause the north star to move? — run the analysis; don't assume
• What's the counter metric for each thing we're optimizing? — pair every driver metric with a guardrail
• If this metric doubled, what would we do differently? — if the answer is nothing, cut it from the deck
• How is "active" defined? — never accept an active user number without knowing the definition
• Are we measuring leading or lagging? — your review deck should have both
• What are the 5 ways someone could hit this target without improving the product? — name the gaming scenarios before you set the goal