◀ Course contents Part 1 · Module 1-04

KPI Trees

Break a big goal metric into the levers you can actually pull

A single top-line number like revenue is too blunt to act on. A KPI tree breaks it into the drivers that feed it, turning a vague goal into a map of specific levers, and showing exactly where a metric moved when it does.

Ready?

1

What a KPI Tree Is

Your leadership team sets the goal for the year: grow revenue. You agree it matters. Then you sit down on Monday morning and try to work out what to actually do, and the goal gives you nothing at all. You cannot ship revenue.

This is the problem a KPI tree solves. (KPI just means Key Performance Indicator — a number you track to see how you are doing. The jargon is heavier than the idea.) A KPI tree takes one big goal metric and breaks it into the smaller metrics that mathematically combine to produce it, then breaks those down again, until you reach numbers a team can actually influence this week.

Revenue, for instance, is not one thing. It is active users × conversion rate × average order value. Each of those splits again: active users comes from new sign-ups and retained users; conversion comes from traffic quality and checkout friction. Four levels down, you are looking at things like “page load time on the payment step” — which somebody can own and change on Tuesday.

The rule that makes a tree honest is arithmetic: the children of any node must actually combine to produce the parent. If they do not multiply or add up, you have drawn a mind map of loosely related ideas and labelled it a model. A branch like “customer happiness” sitting between revenue and its drivers cannot be multiplied by anything, so nothing below it can be checked against anything above it.

Done properly, a tree does two things at once. It turns an untouchable goal into a set of owned levers — and it shows you, immediately and often uncomfortably, which branch nobody has looked at for a year.

A KPI tree A north star metric at the top, Monthly revenue, breaking into two branches: New customers, which is traffic multiplied by conversion rate; and Revenue per customer, which is plan mix plus expansion. Each pair of children sits side by side under its parent with the operator that joins them. Monthly revenue New customers Traffic × Conversion rate Revenue per customer Plan mix + Expansion
Each level resolves into the one above it by arithmetic — multiplied here, added elsewhere. That is the whole discipline: if the branches do not arithmetically produce the parent, the tree is a diagram of hopes rather than a model of the business.

Everyday example, the household budget

"We're spending too much money" is impossible to act on, there's no single knob for "spending." But break it apart: spending = rent + groceries + subscriptions + transport + eating out. Now you can see the levers. Maybe rent is fixed, but three forgotten subscriptions and daily takeout are the real drivers. A KPI tree does the same thing to a business metric: it turns a vague worry into a short list of things you can actually change.

Revenue, decomposed

"Grow revenue" is hard to act on. But:

Revenue = Active Users × Conversion Rate × Average Revenue Per User

Now you can see three distinct levers. A team can go after conversion while another grows active users, and you can tell which one actually moved the top line.

Revenue, taken apart

"Grow revenue" gave a team nothing to do on Monday. Decomposed into active users times conversion times average order value, the same goal produced three owners, three baselines, and an immediate discovery: conversion had been flat for eleven months while everyone had been working on traffic.

Quick check

What is the main thing a KPI tree gives you that a single top-line number doesn't?

2

Building the Tree

Building a tree is mechanical once you know the two moves, and almost everyone gets one of them wrong the first time.

Start at the top with a single goal metric — the number the business genuinely cares about this year. Then ask: what does this number multiply or add up from? Not “what affects it”, which lets anything in, but what it is arithmetically composed of. Revenue splits into new customers and revenue per customer. Those split again. Keep going until you reach something a team can move directly.

The two joins you are allowed are multiplication and addition. Multiplication is for rates and volumes chained together: visitors × conversion = customers. Addition is for parts of a whole: new revenue + expansion revenue = total revenue. If you cannot describe a join as one of those two, the branch does not belong there yet.

The common mistake is including things that influence the parent without composing it — brand awareness, customer satisfaction, team morale. These are real and they matter, and they are not tree nodes, because you cannot check them. The test to apply at every level: if I improve every child by 10%, can I calculate exactly what happens to the parent? If not, the level is decoration.

Keep it shallow, too. Three or four levels is usually enough to reach something actionable, and a tree with nine levels is a diagram nobody will open twice.

What may join two levels A checklist of valid and invalid tree joins. Multiplication and addition are allowed because they can be checked; influence and correlation cannot. Valid join Not a tree node Multiplication — visitors × conversion Addition — new + expansion revenue Children arithmetically produce the parent You can calculate the effect of a 10% change "Influences" — brand awareness "Correlates with" — satisfaction Overlapping branches that double-count Soft nodes wedged into a chain
The test at every level: if I improve every child by 10%, can I calculate exactly what happens to the parent? If not, that level is decoration — and nothing below it can be checked against anything above it.

Everyday example, slicing a pizza (MECE)

MECE stands for "Mutually Exclusive, Collectively Exhaustive." In plain words: cut the pizza so every bite belongs to exactly one slice (no overlaps), and the slices together make up the whole pizza (no missing bits). "New users + returning users" is a clean MECE cut of all active users, everyone is one or the other, and together they're everybody. "Happy users + users on iPhone" is not: someone can be both (overlap) and plenty are neither (gap). Good tree branches are always clean slices.

1

Start at the top

The one metric that matters most right now, often the North Star.

2

Decompose one level

Break it into the 2-4 inputs that mathematically produce it.

3

Repeat downward

Break each input into its own drivers until you reach something a team can act on.

4

Keep branches clean

Inputs at each level should be MECE, no overlaps, no gaps.

The branch that did not multiply

A tree had "customer happiness" sitting between revenue and its drivers. It could not be multiplied by anything, so the level below it could not be checked against the level above. Replacing it with renewal rate and expansion rate made the tree arithmetic again — and immediately showed that one of the two had been flat for a year.

Quick check

You're decomposing "monthly active users." Which is a valid next level of the tree?

3

Finding the Best Lever

A finished tree gives you twenty or thirty numbers. The obvious next question is which one to work on — and “the one that looks worst” is a surprisingly bad answer.

Three things decide the value of a lever, and you need all three together. Size: how much room is there to improve? A conversion rate at 2% has more headroom than one at 61%. Reach: how much of the business does this node touch? Improving something that applies to every customer beats the same improvement on a fifth of them. Effort: what would it cost to move it?

Reach is the one people forget, and it is often decisive. Lifting conversion from 2% to 3% and lifting average order value by 10% can look like similar wins on a slide. If conversion touches every customer and order value only applies to the fifth who buy the add-on, the first is worth roughly five times the second for the same work — and you can only see that when both numbers sit in the same structure with their volumes attached.

This is the real payoff of building the tree. Not the diagram, but the fact that it makes two proposals comparable that were previously just two opinions. Someone can still disagree, but now they have to disagree with an arithmetic statement rather than with your enthusiasm.

One caution: the biggest lever is not always the right one this quarter. A node with huge potential and a twelve-month build may lose to a smaller one you can move in three weeks — especially if you need evidence that the tree is right before anyone will fund the big bet.

Why reach usually decides it Two levers compared by the customers they touch. A conversion improvement applying to every customer beats a larger-sounding order-value improvement that applies to a fifth of them. Conversion 2% → 3% 100% of base touches every customer Order value +10% 20% of base touches the fifth who buy the add-on
These look like similar wins on a slide. With volumes attached, the first reaches five times as many customers as the second for the same work. The tree makes two proposals comparable that were previously two opinions — you can still disagree, but now with an arithmetic statement.

Everyday example, fixing up a house

Say you want to raise your home's value. Repainting a doorknob is easy but changes almost nothing (low impact). Adding a second floor would change a lot but is wildly expensive and slow (low feasibility). Refreshing the kitchen is both meaningful and doable, that's the sweet spot. In a KPI tree you're hunting for the "kitchen refresh" branch: a real driver of the top number that you can actually move with the time and resources you have.

Chase this

High impact + high feasibility

A big driver of the top metric that you can realistically influence. Your prime target.

Maybe later

High impact, low feasibility

Matters a lot but hard to move (e.g. market-wide pricing). Note it; don't start here.

Skip

Low impact

Even if easy, moving it barely nudges the top line. Easy wins that don't matter are still a waste.

Choosing the lever by size and reach

Two branches looked equally attractive: lifting conversion from 2% to 3%, or lifting average order value by 10%. The tree showed conversion touched every customer while the order-value work applied to a fifth of them. Same effort, and one reached five times as many customers as the other — visible only once both sat in the same structure.

Quick check

Your tree shows two levers: (A) checkout conversion, a huge driver of revenue and clearly fixable, and (B) footer link clicks, easy to boost but a tiny driver. Where do you start?

4

Vanity & Broken Branches

Two failures turn a KPI tree from a decision tool into wall decoration, and both are easy to spot once you know the shape of them.

The first is the vanity metric: a number that only ever goes up. “Total registered users, all-time” is the classic. It rose every week for two years at one company, including the six months when they were losing more accounts than they gained, because a cumulative count cannot fall. A metric that cannot go down cannot carry information — it is a counter, not an indicator. The fix is to make every node capable of moving in both directions: active users this month rather than users ever.

The second is the broken branch: a level whose children do not actually produce the parent. Sometimes this is a soft node like “engagement” wedged into an arithmetic chain. Sometimes it is subtler — two branches that overlap, so improving both double-counts the same customers and the tree promises a gain that never arrives.

Both failures share a symptom worth watching for: the tree stops being consulted. If a team built one in January and nobody has opened it by March, it is almost always because someone tried to use it to settle an argument, found the arithmetic did not hold, and quietly went back to opinions.

A tree is only worth building if you intend to check it against reality. When a branch improves and the parent does not move, that is not an annoyance — it is the tree telling you your model of the business is wrong, which is the most valuable thing it will ever say.

Two ways a tree stops working Two panels. A vanity metric can only rise, so it carries no information. A broken branch has children that do not produce the parent, so improvements never arrive. Vanity metric can only go up "Total registered users, all-time" Rose during six losing months A counter, not an indicator Fix: make it able to fall Broken branch arithmetic does not hold Soft node in a hard chain Branches that overlap Promises gains that never arrive Fix: re-derive the level
Both share one symptom worth watching for: the tree stops being consulted. Usually because someone tried to settle an argument with it, found the arithmetic did not hold, and went back to opinions.

Everyday example, the odometer vs. the speedometer

A car's odometer (total miles ever driven) only climbs, it never tells you how fast you're going right now or whether you're about to crash. The speedometer moves both ways and reflects your current state. "Total sign-ups ever" is an odometer: it always goes up, even while the product is falling apart. "Weekly active users" is a speedometer, it can drop and warn you. Build your tree from speedometers, not odometers.

The vanity trap

"Total registered users, all-time" only ever goes up and never goes down, it feels great and tells you nothing about whether the product is healthy today. That's a vanity metric.

Prefer actionable metrics: ones that a specific decision can move, and that can go down as well as up. And check every branch actually composes its parent.

The number that only went up

A weekly report led with total registered users, all-time. It rose every week for two years, including the six months when the product was losing more accounts than it gained. The metric could not fall, which meant it could never carry information.

Quick check

Which of these is a vanity metric you should be wary of putting at the heart of a KPI tree?

Drill what you learned
Scenario 1 easy

Revenue is down 10% this quarter and leadership wants to know why. You have a KPI tree: Revenue = Active Users × Conversion × ARPU.

How does the tree help you diagnose it?

Scenario 2 easy

A teammate proposes making "total lifetime registered accounts" the team's headline metric because "it always goes up and looks great to investors."

What's your response?

Scenario 3 easy

You want to grow your North Star. Two levers sit in the tree: (A) improving activation — a major driver you can influence — and (B) adding more social-share icons, easy but a minor driver.

Which do you prioritize, and why?

Scenario 4 easy

A colleague draws a tree: "Revenue = Marketing spend + Number of features + Team happiness."

What's fundamentally wrong with this tree?

Scenario 5 easy

You split "active users" into "users who log in via email" and "users who are happy with the product."

Why does this split break MECE?

Scenario 6 medium

Revenue is flat, but your tree shows active users up 20% while conversion rate dropped 18%. Everyone is confused about whether things are good or bad.

What does the tree tell you?

Scenario 7 medium

Two levers have equal impact potential. Lever A requires a six-month platform rebuild; lever B is a copy-and-layout change your team can test next week.

Which do you start with, all else equal?

Scenario 8 medium

Your team obsesses over "cumulative app installs," which is now 5 million and rising. Meanwhile monthly active users has quietly fallen for three straight months.

What's the diagnosis?

Scenario 9 medium

A stakeholder wants the KPI tree taken down to twelve levels of depth "so we capture every possible sub-metric."

What's the practical caution?

Scenario 10 medium

Your North Star is "weekly active teams." You decompose it as: New teams activated + Existing teams retained + Churned teams reactivated.

How good is this decomposition?

Scenario 11 hard

The exec team wants ONE North Star metric, but sales wants revenue, growth wants signups, and the CS team wants retention.

How can a KPI tree resolve this?

Scenario 12 hard

Conversion rate is your chosen lever. A designer suggests boosting it by auto-checking an "add premium add-on" box by default, which users often miss.

What's the systems-aware caution before celebrating a conversion bump?

Scenario 13 hard

You need to raise "orders per month." The tree splits it into Traffic × Conversion × Repeat-purchase rate. Data shows traffic is huge, conversion is average, and repeat-purchase is far below industry benchmark.

Where's the most promising lever?

Scenario 14 hard

A teammate insists "average revenue per user" is meaningless because your users are wildly different — some pay nothing, a few pay thousands.

What's the sharpest response?

Scenario 15 hard

Leadership asks you to prove that last quarter's onboarding project "worked." You have a full KPI tree in place.

How does the tree let you answer cleanly?

Drilled it. Now apply it to a real situation.

Put it to work
From lesson 1

Amazon's flywheel, drawn as a tree

Amazon

Amazon is well known for managing on controllable input metrics rather than output ones. Jeff Bezos's shareholder letters describe goals set on inputs the team can act on directly — selection, price, in-stock availability, delivery speed — on the argument that the outputs, revenue and free cash flow, follow from them.

The famous napkin flywheel is the same idea drawn as a loop: selection improves customer experience, which grows traffic, which attracts sellers, which improves selection.

Why steer on inputs rather than the output everyone actually cares about?

Select all that apply — there are 3 to find.

From lesson 2

Decomposing without double-counting

A ticketing marketplace

Top of the tree: gross ticket revenue. Four proposed second-level branches. Two of them break the arithmetic.

Proposed decomposition
#Branch
1Buyers × tickets per buyer × average ticket price
2Mobile revenue + desktop revenue
3New buyer revenue + returning buyer revenue
4Marketing spend × conversion rate

Which of these are valid decompositions of gross ticket revenue?

Select all that apply — there are 3 to find.

From lesson 3

Which branch is worth the quarter

A subscription audiobook service

Goal: grow monthly revenue. The tree bottoms out in four levers. The team can seriously move one.

The four levers
LeverCurrentRealistic moveRevenue effect
Trial-to-paid conversion24%+3 pts+£142k / mo
Monthly churn6.1%-0.8 pts+£310k / mo at steady state
Average revenue per user£9.20+£0.40+£88k / mo
Trial starts61,000+8%+£117k / mo

Rank the four by where the quarter should go, best first.

Drag the rows, or use the arrows, then check.

  1. Churn — 0.8 points is worth £310k a month at steady state First, and by more than the table shows. Churn is a multiplier on every other branch: it raises the value of every conversion and every trial start, now and in future quarters.
  2. Trial-to-paid conversion — 3 points, £142k Second. Real money on people you have already paid to acquire, and the effect is immediate rather than compounding over a year.
  3. Trial starts — 8% more, £117k Third. Comparable size, but it is the branch that costs money to move — the others are product work, this one is largely spend.
  4. ARPU — 40p, £88k Last. Smallest effect, and price changes carry churn risk that could cancel out the gain from the branch above it.
From lesson 4

A branch that could not be moved

A charity donations platform

The tree is well built and reconciles cleanly. One branch — "average donation size" — has been on the roadmap for three quarters and has not moved despite five separate attempts.

Work out what is wrong.

  1. Step 1 of 3

    The five attempts were all interface changes: suggested amounts, defaults, a slider, framing copy, a progress bar. What might that pattern suggest?

    So the branch is real, and it is not controllable. Those are different properties and a tree must distinguish them.

  2. Step 2 of 3

    What should happen to that branch on the tree?

    Marked as context, the tree's remaining levers got the attention that branch had been absorbing.

  3. Step 3 of 3

    One more check on the same tree: "number of shares on social" sits as a lever under donor acquisition. Is it one?

    Checked, a share produced 0.02 donations. Real, tiny, and nowhere near worth the branch it occupied.

Notification