North Star Metric vs. Input Metrics: The Metric Tree

The North Star Metric is the single lagging output that captures the core value your product delivers — deliberately chosen so that no one team can move it directly. Input metrics are the three to five leading, ownable levers sitting underneath it. A metric tree connects the two, so a team can walk down from the scoreboard to the lever they actually control and do something about it.

The short version

Your North Star is the scoreboard, and your inputs are the levers. You watch the scoreboard to know whether the game is going your way. You pull the levers to change the score. Confuse the two and your metrics framework ends up decorative — a slide nobody acts on.

Sean Ellis, who coined the term, defines the North Star Metric as "the single metric that best captures the core value that your product delivers to customers." That's the whole idea in one line. Amplitude, via former Product Evangelist John Cutler, extended it into a fuller framework that pairs the metric with a small set of inputs. Cutler's sharpest test is worth memorizing: "If you can move your North Star directly, it's probably not a good North Star." Move it directly and you've named an input, then mislabeled it.

Amplitude defines those inputs precisely: "a set of three to five influential, complementary factors that you believe most directly affect your North Star Metric and that your team can directly influence through your product." Mixpanel adds the ownership dimension, noting that inputs "are often owned by specific teams (and for L2 or L3 metrics, can even be the responsibility of specific people)." Hold on to that word, owned. It does most of the work later.

Why the NSM alone gets stuck on a slide

Here's the failure this article exists to fix. A company runs an offsite, picks a North Star, puts it on a slide with a nice arrow trending up. Then nobody can figure out what to do on Monday. The metric is real. It's also too abstract to plan a sprint against.

Reforge's Brian Balfour named this directly. An output metric, he argues, is usually too broad to set team goals against, so "you commonly need to break it down into a slightly more granular set of input metrics or levers, so that if you improve those inputs, you will end up seeing the results in the output metric over time." Reforge's own writing goes further, treating the North Star as a scoreboard by design: "although you should monitor North Star Metrics to ensure you're driving the right outcomes, your strategy needs to focus on the input metrics you can directly influence."

The NSM tells you whether you're winning. It never tells you what to do. That's not a flaw. It's the job. Trouble starts when a team stops at the scoreboard.

The test for a good input metric

Every candidate input has to pass three questions. Miss one and it isn't an input — it's noise dressed up as a lever.

Is it movable? Can a team change it through work they can actually schedule? Ship a feature, run an experiment, fix an onboarding step. If the honest answer is "sort of, indirectly, if the market cooperates," it's too far from the team's hands.

Is it ownable? Can you write one person or one team's name next to it? Mixpanel's framing is the practical bar here: a good input has an owner who checks it and answers for it. Metrics without owners drift.

Is it leading? Does it move before the North Star does, so you can act while there's still time to change the quarter? A lagging input is just a second scoreboard.

Now the industry disagreement I promised. There's a school of thought that wants one number to rule everything, on the theory that focus beats complexity. I side with Reforge's caution against oversimplifying. A single number with no tree beneath it gives you nothing to act on, and worse, it invites teams to juice the headline while a guardrail quietly rots. You want the number and the tree. The number keeps everyone pointed the same way. The tree is where the actual work lives.

Generating inputs with breadth, depth, frequency, efficiency

Brainstorm inputs from a blank page and you'll get an arbitrary list shaped by whoever talked loudest. Amplitude offers a cleaner starting point: "One heuristic we've found helpful when teams are determining inputs is considering breadth, depth, frequency, and efficiency." Four lenses, and each asks a different question about how value accumulates.

Breadth asks how many distinct users or accounts get value. Depth asks how much value each one gets per use. Frequency asks how often they come back. Efficiency asks how well the product converts effort into that value — think activation rate, or time-to-first-value.

Run those four lenses across one product and inputs fall out almost by themselves. Take a note-taking app whose North Star is weekly active note-takers. Breadth points you toward number of new users who create their first note. Depth points toward notes created per active user. Frequency points toward days active per week. Efficiency points toward percent of signups who reach three notes in week one. Four lenses, four candidate inputs, none plucked from the air. You'll cut some later, but at least the starting set is principled.

The metric tree, structured

Here's the reusable shape. A metric tree has exactly three layers, and once you've seen one you can build one for any product.

NORTH STAR METRIC          (1 lagging output — the scoreboard)
├── Input 1                (leading, movable, owned)
│   ├── leaf metric        (the specific number a team moves)
│   └── leaf metric
├── Input 2
│   ├── leaf metric
│   └── leaf metric
└── Input 3
    ├── leaf metric
    └── leaf metric

The recipe for any product: write the one output that captures core value at the top, name three to five inputs that pass the movable/ownable/leading test, then hang the concrete leaf metrics each team actually instruments underneath. That's it. The tree is a hierarchy of "what moves the thing above it."

Real decompositions fit the same mold. Amplitude's own North Star is Weekly Learning Users, defined as a user "who is active and shares a learning that is consumed by at least 2 other people in the previous 7 days" — the top node, with inputs feeding it below. Netflix in 2005, back in the DVD-by-mail era, tracked the number of movies in a member's queue as a leading signal of future engagement and retention, so the queue sat as an input beneath the retention outcome. Airbnb's nights booked works the same way. The booked-nights output sits on top, with inputs like available listings, search-to-book conversion, and repeat booking rate hanging underneath. Same three-layer shape every time.

Worked example: a vague NSM becomes an owned tree

Let me build one end to end with real numbers. Fictional product: a developer tool for scheduling database migrations. Twelve teams on it, tracked over three weeks. Small enough to hold in your head, which is the point.

We start where most teams start, with a vague North Star: "engaged users." That fails the Ellis test immediately, because it doesn't name the core value. What does this product actually do for people? It runs migrations safely. So we sharpen the NSM to weekly teams that run at least one successful migration. That's an output. No single team can move it directly, which is exactly what Cutler's test wants.

Now decompose using breadth, depth, frequency. Breadth gives us new teams reaching their first successful migration, owned by Onboarding. Depth gives us migrations run per active team, owned by Core Product. Frequency gives us weeks active per team per month, owned by Retention. Three inputs, three owners, each passing all three questions.

Here's the tree with week-3 numbers:

NSM: Weekly teams w/ ≥1 successful migration → 7 of 12
├── Input A: New teams reaching first migration (Onboarding)
│     leaf: signup→first-migration rate = 4 of 6 new teams
├── Input B: Migrations per active team (Core Product)
│     leaf: avg migrations/active team/wk = 3.1
└── Input C: Weeks active per team (Retention)
      leaf: teams active ≥3 of last 4 weeks = 8 of 12

Now the walk-down, which is the whole reason you built the tree. Week 1 the NSM was 9 of 12. Week 2, still 9. Week 3 it drops to 7. Panic on the slide. But we don't stare at the slide. We walk down.

Input A held steady: onboarding converted 4 of 6 new teams both weeks, so new-team acquisition isn't the culprit. Input C also held, with 8 teams staying active. Input B is where it moved. Migrations per active team fell from 4.4 in week 2 to 3.1 in week 3. Drill into that leaf and the story appears: two of the heaviest teams cut their migration volume after a failed run spooked them. Not acquisition, not retention. It's a reliability scare in Core Product's territory, and Core Product owns the fix.

That's the payoff. A two-point drop in an abstract scoreboard became one owned leaf metric and one named team, in about four steps. Without the tree, you'd have spent the standup arguing about "engagement."

Where this goes wrong

I've watched every one of these happen, usually more than once.

Picking an NSM you can move directly. If a growth team can spin up a campaign and move the North Star next week, it was never a North Star. It was an input wearing a crown. Cutler's line is the smell test: directly movable means it belongs a layer down.

Naming inputs nobody owns. You draw a beautiful tree, and three of the input boxes have no name beside them. Those boxes will not move. An input without an owner is a hope, not a lever. Run the ownable test hard, and if you can't assign a name, either the metric is wrong or your org chart is.

Collapsing to a single number and dropping guardrails. The one-number crowd tends to forget tradeoff metrics. If your NSM is migrations run and you have no guardrail on migration failure rate, you'll happily celebrate a number that's quietly hurting users. Reforge's warning against oversimplifying is really a warning about this. Keep at least one guardrail visible next to the tree.

A tree drawn once and never wired to anything. This is the quiet killer. The tree lives in a slide from the offsite, the dashboard lives somewhere else, and the two never meet. Six weeks later nobody remembers what Input B was supposed to be.

Wiring the tree to a live dashboard

A tree earns its keep only when every node maps to a real number someone checks on a regular cadence. Each leaf metric needs to exist as an actual query against actual event data, and each input needs an owner who looks at it weekly. The walk-down I did above only worked because those numbers were sitting in a dashboard, not in a doc.

You can wire this by hand — most teams start there, with a dashboard tool and a set of saved queries mirroring the tree structure. Or you can generate the views from a question. One such tool is Kixo, which builds dashboards from plain-language prompts, so "show migrations per active team by week" becomes a chart you can drop under the right input node. Either path is fine. What matters is that the tree and the dashboard are the same object, not two artifacts that drift apart. If you're still shaky on which underlying metrics belong at the leaf level, it's worth grounding yourself in the core growth metrics before you wire anything.

Quick reference: NSM vs. input metric

Dimension	North Star Metric	Input Metric
Signal type	Lagging output	Leading
Direct movability	No (by design)	Yes
Ownership	Whole company	A team or a person
How many	One	Three to five
Example	Weekly teams with a successful migration	Migrations per active team

The definitions behind this table trace to Ellis (core-value output), Amplitude's Cutler (not directly movable), and Mixpanel (leading, controllable, team-owned).

What to do this week

Three moves. First, write your North Star as one sentence naming the core value your product delivers, and check it against Cutler's test — move it directly and it's an input. Second, list four candidate inputs and run each through the three questions: movable, ownable, leading. Cut anything that fails even one. Third, write a name next to every surviving input. If you can't, you've found your first real problem, and that's a good week's work.

Then build the little three-layer tree from the example above with your own numbers. Twelve users and three weeks is plenty to prove the walk-down works before you scale it.