What needs to be finished first
A North Star Metric or a comparable top-level metric with a clear definition (numerator, denominator, source) is available.
Funnel or AARRR data from the last 90 days is available, so sub-metrics are verifiable.
What needs to be ready before start
Whiteboard or Miro board with hierarchical structure (root at top, sub-nodes below); top metric with current value; list of data sources; pens; tool for persistent maintenance (Notion, Looker Studio, dbt).
A facilitator with analytics understanding; a Product Lead or Growth Lead; Data Analyst for metric definitions; 2-4 additional team members; a scribe for owners and data.
Top metric with definition (numerator, denominator, aggregation period); current value; funnel data; known leverage hypotheses; owner candidates for sub-metrics.
90-180 min initial, then continuous
Set the top metric at the top of the board as the root. Node template: name, definition, current value, owner, lever. Limit hierarchy depth to 3 levels for visibility.
The one question this method answers
How does the top metric decompose into controllable sub-metrics, which one contributes how much, and who is responsible for each lever?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Define top metric | 15 min | Capture the top metric with numerator, denominator, aggregation period, and source. Document current value. Set target value (for example quarterly or annual target). | If the top metric is unclear, the tree is fragile. The definition must be repeatable in one sentence. Anyone asking "what do we mean by Y" reveals an unclear root. |
2Phase 2: First-level drivers | 30-45 min | Decompose the top metric mathematically or causally into 2-5 sub-metrics (for example Active Users = New Users + Returning Users; Revenue = ARPU * Active Users). Define each node. | Mathematical decomposition is the gold standard. Causal decomposition (for example "Activation drives Retention") needs stronger rationale. A mix is allowed, but mark it clearly per node. |
3Phase 3: Second-level levers | 30-45 min | For each level-1 node, further decompose into levers and sub-metrics. Typically 2-4 child nodes per node. Add owner and current value for each node. | The second level is often the action level with the levers teams can influence. Deeper than 3 levels becomes hard to read; move detail to separate subtree sessions. |
4Phase 4: Owners, data, and review cadence | 15-30 min | Assign owners by name per node, data source (dashboard link), and review cadence (typically weekly for operational metrics, monthly for strategic). | A node without an owner becomes wall art. Each node should have a concrete person accountable for movement. Name one primary owner when multiple owners are involved. |
What comes out at the end
KPI tree diagram (board export or Mermaid tool), plus a table of nodes with definition, current value, target, owner, data source, and review cadence.
Re-evaluate tree structure quarterly. Keep current values updated continuously (dashboard integration). Structural changes with date and rationale. Archive previous versions.
Compact working template for KPI Tree with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Top metric: Monthly Recurring Revenue (MRR). Definition: Sum of recurring monthly contributions of all active paying customers, source: Stripe dashboard.
Current value: EUR 14,700. Quarterly target: EUR 22,000.
Level 1 drivers
Level 2 levers
Review cadence
Top leverage hypotheses Q2
Recognize symptoms and steer against them
The tree is cleanly structured with the same number of nodes per level, but causality is forced.
Asymmetry is valid. Some nodes have two sub-metrics, others five. Structure should follow causality, not aesthetics.
The tree exists, but nobody feels responsible, so values are not updated.
Assign one named owner per node. The owner is accountable for movement, not just reporting. If a node has no owner, either remove it or find an owner.
A node has a current value, but no one can name dashboard link or SQL query.
Data source is mandatory for each node. If source has to be built, that work becomes its own initiative with an owner.
The tree has 5+ levels and nobody can keep the structure in mind; operational control is lost in detail.
Use a maximum of 3 levels per main tree. Create separate subtrees for detailed levers. Visibility is value; detail is for a separate view.
The tree is built once and sits in the wiki without values being updated.
Connect data to dashboards (Amplitude, Mixpanel, Looker). Add live link per node. Manual maintenance should be the exception, not the rule.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.