Growth · 10 min read · 2026-10-17
Metric Trees: Turn a North Star Into Levers You Own
Most SaaS companies can recite their north-star metric and almost none can act on it directly. "Grow weekly active teams" or "increase net revenue retention" is a destination, not a lever — no single team can pull it, and when it moves, nobody can say which of a dozen things caused the move. The missing piece between a north star and a decision is the metric tree: the arithmetic decomposition that turns one strategic number into the owned, measurable inputs that produce it.
This is a playbook for building that tree. The blog's north-star selection framework covers how to pick the top-line number; this post is about what you do next — breaking it into drivers you can assign, instrument, and act on — and the two rules (reconciliation and no double-counting) that separate a real driver tree from a tidy-looking org chart of metrics.
A north star alone is not operable
The north-star framework gives you a compass, and a compass only tells you the direction, not the next step. Mixpanel frames the relationship exactly this way: the north star is the strategic compass that tells you where you want to go, while the metric tree is the detailed map for execution beneath it. The gap between the two is where most measurement programs stall: the top-line is agreed, reported, and put on a dashboard, and then it sits there, because no individual contributor owns "NRR" and no sprint ships "weekly active teams."
A metric tree closes that gap by making the north star the root of a hierarchy whose leaves are things a specific team can change this quarter. It is the structural expression of the same principle behind choosing actionable over vanity metrics: a number only earns its place if someone can move it. The tree forces that test at every level, because every node has to resolve into child nodes closer to an actual lever, until the leaves are operational inputs with an owner.
Decompose by arithmetic, not by theme
The step that makes a metric tree useful — and the step most teams get wrong — is that the decomposition has to be arithmetic. Each parent is written as an equation of its children, which combine by multiplication or addition to reproduce it. New revenue is not "related to" traffic, signup, activation, and conversion; it equals traffic multiplied by signup rate multiplied by activation rate multiplied by paid-conversion rate. A guide to designing metric trees makes the rule explicit: the decomposition must be arithmetic, not just categorical, with drivers that reconcile to the parent.
The difference is not pedantry. A thematic grouping — "acquisition, engagement, monetization" with assorted metrics under each — looks like a tree but cannot tell you how much a change in one node moves the top, because the nodes do not combine into anything. An arithmetic tree can: if activation rate rises 10% and nothing else changes, you can read the exact effect on new revenue straight off the multiplication. That property is what lets the tree answer the question executives actually ask — "if we improve X, what happens to the north star?" — which depends on the same denominator discipline as any rate metric with a well-chosen base.
The reconciliation rule keeps the tree honest
An arithmetic tree gives you a free, powerful correctness check: at every level, the children must combine back to the parent within a small margin. If your drivers multiply or sum to a number several percentage points off the north star you measured, the tree is wrong — you are missing a driver, mis-defining one, or double-counting. One metric-tree guide states the test plainly: the tree is unfinished if the drivers do not reconcile with the north star's change within a few percentage points. Reconciliation is not a one-time build step; it is an ongoing monitor that tells you when your model of the business has drifted from the business.
This is also what makes a metric tree a diagnostic instrument and not just a diagram. When the north star moves and the tree reconciles, you can walk down the branches to find which driver actually changed, instead of guessing. It is the structured version of the reconciliation work the blog describes when two analytics tools report different numbers: you do not trust a top-line until its components add up, and when they fail to add up, the failure itself is the most useful signal you have.
No double-counting: nodes must be mutually exclusive
The most common way a tree fails reconciliation is double-counting: the same user, event, or dollar is attributed to more than one branch, so the children overcount the parent. A revenue tree that credits an expansion both to "upsell" and to "retention," or a traffic tree where a visitor appears under two channels, sums to more than the real total and quietly breaks every downstream read. The discipline that prevents it is to make each level mutually exclusive and collectively exhaustive — every unit rolls up through exactly one child, and the children together cover the whole parent with no gaps.
Getting that right is a definition problem, not a math problem, and it is the same hazard that produces double-counted conversions across a hybrid PLG and sales motion. The fix is shared, single-source definitions for every node rather than each team computing its branch its own way. When "activated user" means one thing in the activation branch and another in the retention branch, the tree cannot reconcile, because the same people are being counted under two incompatible rules. Pinning each node to a definition in a single source of truth is what keeps the branches from silently overlapping as the org grows.
Assign every leaf to an owner
A metric tree earns its keep when its leaf nodes are operational inputs each owned by a specific team. The practical structure most guides land on is three to four levels: the north star at the top; two to four components that multiply or add to it; the operational inputs beneath those, owned by individual teams; and an optional fourth level of leading indicators. The depth target is not a number of levels but a property — you stop when every leaf is something a named team can measure and move in a sprint. If a leaf is still too abstract to assign, it is a driver, not a lever, and it needs one more level of decomposition.
Ownership is what converts the tree from an analysis into an operating system. Each team can see exactly how its input rolls up to the north star, which makes prioritization an arithmetic argument rather than a political one: a team can show that moving its leaf 15% moves the top-line by a computable amount, and compare that to another team's lever on the same scale. That is the difference between a dashboard people glance at and a model people plan with — and it depends on the leaves being genuine leading indicators that move before the north star does, not lagging restatements of it.
Build your first tree this sprint
Start with the north star you already have and write it as a single equation of its two-to-four immediate inputs — resist the urge to list themes, and insist on operators that combine the children into the parent. Then recurse one level: break each driver into the operational inputs a team controls, and stop when every leaf has an owner. Finally, run the reconciliation check with last quarter's real numbers: do the leaves, combined up the tree, reproduce the north star you actually measured? If they miss by more than a few points, you have found a missing driver or a double-count, and fixing it is the highest-value thing the exercise produces.
The first version will be imperfect, and that is fine — the tree is a model of how you believe the business works, and reconciliation tells you where the belief is wrong. Maintain it as a living artifact: when a node stops reconciling, your understanding has drifted and the tree is telling you to look. Done well, it turns the north star from a slogan on a wall into a map every team can navigate, the same way decision-first analytics turns a pile of events into measurements someone will actually act on.
Frequently asked questions
The questions below cover what a metric tree is, how it differs from a north-star metric, how to decompose a north star into drivers, how to avoid double-counting, and how many levels a tree should have.
FAQ
What is a metric tree?
A metric tree, also called a driver tree, is a hierarchy that breaks a single north-star metric into the input metrics that mathematically produce it. At the top sits the strategic metric you are trying to move; below it sit two to four drivers that combine — by multiplication or addition — to equal it; below those sit the operational inputs that each team actually controls. The structure turns an abstract goal like 'grow ARR' into a map of the specific levers that feed it, so a movement at the top can be traced to the node that caused it. The defining feature is that it is arithmetic, not just thematic: the children of every node must combine to reproduce the parent.
What is the difference between a north-star metric and a metric tree?
The north-star metric is a single number that captures the core value your product delivers and where the company wants to go; the metric tree is the map of how you get there. The north star is a strategic compass — it tells you the direction but not which lever to pull. The tree decomposes that compass reading into the drivers and inputs beneath it, each owned by a team and each measurable, so the organization can act. You need both: a north star without a tree is a goal nobody knows how to influence, and a tree without a north star is a pile of metrics with no agreed top-line to roll up to.
How do you decompose a north-star metric into drivers?
Write the north star as an equation of its immediate inputs, then recurse. New revenue, for example, decomposes to traffic multiplied by signup rate multiplied by activation rate multiplied by paid-conversion rate; retained revenue decomposes to prior base multiplied by retention rate plus expansion. Each driver then breaks into its own operational inputs owned by a specific team. The rule that keeps it honest is that the decomposition must be arithmetic: at every level the children must multiply or add back to the parent within a few percentage points. If they do not reconcile, the tree is wrong or incomplete — you are missing a driver or double-counting one.
How do you avoid double-counting in a metric tree?
Double-counting happens when the same user, event, or revenue is attributed to more than one branch of the tree, so the drivers sum to more than the parent. Prevent it by making each node mutually exclusive and collectively exhaustive at its level: every unit that rolls up should belong to exactly one child branch, and the branches together should cover the whole parent with no gaps and no overlaps. The arithmetic reconciliation check catches most violations automatically — if the children overcount the parent, a branch is counting something another branch already counted. Shared definitions in a single source of truth, rather than per-team metric logic, are what keep the boundaries clean over time.
How many levels should a metric tree have?
Most useful metric trees run three to four levels. Level one is the north-star metric. Level two is the two to four components that multiply or add to produce it. Level three is the operational inputs owned by individual teams — the levers people can actually pull in a sprint. An optional fourth level holds leading indicators that predict movements in the inputs above them. Going deeper than four levels usually produces a tree nobody maintains; going shallower leaves the drivers too abstract to assign to an owner. The right depth is the one where every leaf node is something a specific team can measure and influence directly.