A hierarchical diagram that decomposes a single north-star metric into the driver and input metrics that explain its movement, giving every team a clear line from their daily work to the outcome the business cares about most.
What are the driver and input metrics that together determine the value of our north-star metric?
A metricsMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → tree is a hierarchical diagram that starts from a single top-level metric and breaks it down into the driver and input metrics that together determine its value. It gives a team a clear, shared account of how their daily work connects to the outcomeOutcomeStrategyA desired business or user outcomeView reference → the business cares about most.
The practice of decomposing a top-level business measure into its constituent drivers has a long history in management accounting. The DuPont model, developed in the 1920s, decomposed return on equity into a tree of contributing financial ratios, establishing the basic logic that a high-level metric is the product of lower-level factors, each of which can be acted on separately.
That financial logic was carried into product and growth analytics gradually. The concept of a single north-star metric, the one number that best captures the value a product delivers to its users, was popularised in the growth community in the early 2010s. Sean Ellis, credited with coining the term, argued that a company orienting every team around a single shared metric could avoid the fragmentation caused by teams optimising local numbers that did not add up to anything meaningful.
Amplitude extended this into the North Star Framework, published in their playbookPlaybookCustomer SuccessA standard operating procedure for CSView reference → and widely adopted through the mid-2010s and beyond. Their framing combined the north-star metric concept with an explicit input-metric layer: a small set of driver metrics that together predict movement in the north star. John Cutler, then at Amplitude, was a prominent voice in developing and communicating this structure.
There is no single inventor of the metrics tree as a visual artefact. The tree shape is a natural expression of the decomposition logic, and teams in analytics-heavy organisations arrived at similar diagrams independently. What Amplitude's North Star Framework provided was a shared vocabulary and a practical discipline for choosing which metrics belonged in the tree and why.
A metrics tree has three levels.
At the top sits the north-star metric: a single number that reflects the core value the product delivers to users. Spotify's north-star has been described as time spent listening. Airbnb's was nights booked. Slack's has been daily active users among teams with more than a threshold number of seats. The north-star is not a revenue metric, though it should correlate with revenue. It is a leading indicator of whether users are getting value.
At the second level sit the driver metrics, the three to five factors whose combined movement explains most of the variation in the north star. For a music streaming service these might be new subscribers activated, sessions per active user per week, and session length. Each driver is something a team can directly influence through product work.
At the third level sit input metrics, more granular measures that track specific product interactions or behaviours that drive each second-level metric. For "sessions per active user per week" the inputs might include playlist completion rate, share of sessions triggered by a recommendation, and return-visit rate after a playlist ends.
A worked example. A B2B project management tool sets "weekly active teams" as its north star: the number of teams where at least three members used the product in the past seven days. Driver metrics are new teams activated this week, teams retained from the previous week, and average sessions per active team. Under activation, input metrics include time to first shared project, completion of the onboarding checklist, and number of team members who logged in within the first 48 hours. The product team can now connect any proposed featureFeatureProduct SpecificationA product capability or featureView reference → to the part of the tree it should move, and the analytics team knows which inputs to instrument.
A metrics tree is most useful when a product has reached the point where multiple teams are working in parallel and there is a riskRiskComplianceA risk to the product or businessView reference → that each team optimises a local metric without understanding how it connects to the company's primary measure of progress. The tree makes the connection explicit and gives teams a shared frame for prioritising work.
It is also useful during planning cycles, as a way to surface which driver metrics have the most room to move and therefore which investments are likely to move the metric most.
The tree works less well in very early-stage products, where user behaviour is so sparse that most metrics are statistically meaningless and the team's main jobJobUserJob To Be Done: what the user is trying to accomplishView reference → is to find out whether their basic premise is right. Premature metric decomposition can give a false sense of analytical clarity when what is needed is qualitative discovery.
A common failure mode is a tree with too many second-level drivers. If the north star has eight or nine inputs, teams cannot focus, and the tree stops being a prioritisation aid and becomes a comprehensive list of things the product team cares about, which is not the same thing. Three to five drivers is the practical limit.
The metrics tree is a tree framework in the data_analytics category. Its levels map onto entity types in the Unified Product Graph, so measurement connects to the rest of the product graph and lives alongside the work it tracks.
metricoutcomedashboardreportModelling a metrics tree this way means a decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → to change the north-star metric, or to swap out a driver, is a graph event with a visible rationale, not a change that happens in a spreadsheet and loses its context within a week.