All 29 modules are open from the start — nothing here is
locked, and nothing costs anything. Sign in so your progress, titles and
credentials stay with you, on every device you use.
Free forever, with your Google account. No password, no payment.
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.
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.
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.
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.
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.
What actually happened
The structural claim is the useful part: a KPI tree is only worth
drawing if the leaves are things a named team can change on Monday. A
tree that bottoms out in another output metric has stopped one level too
early.
Outputs tell you how it went. Inputs are what you can actually pull.
Keep decomposing until you reach something someone can pull.
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
1
Buyers × tickets per buyer × average ticket price
2
Mobile revenue + desktop revenue
3
New buyer revenue + returning buyer revenue
4
Marketing spend × conversion rate
Which of these are valid decompositions of gross ticket revenue?
Select all that apply — there are 3 to find.
What actually happened
They kept branch 1 as the tree and used 2 and 3 as separate views of it.
Branch 4 became a sub-tree under conversion rate, where the units
actually work.
Check the arithmetic at every level: children must sum or multiply to
the parent, and must not overlap. A tree that does not reconcile will
produce confident, wrong prioritisation.
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
Lever
Current
Realistic move
Revenue effect
Trial-to-paid conversion
24%
+3 pts
+£142k / mo
Monthly churn
6.1%
-0.8 pts
+£310k / mo at steady state
Average revenue per user
£9.20
+£0.40
+£88k / mo
Trial starts
61,000
+8%
+£117k / mo
Rank the four by where the quarter should go, best first.
Drag the rows, or use the arrows, then check.
Churn — 0.8 points is worth £310k a month at steady stateFirst, 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.
Trial-to-paid conversion — 3 points, £142kSecond. Real money on people you have already paid to acquire, and the effect is immediate rather than compounding over a year.
Trial starts — 8% more, £117kThird. Comparable size, but it is the branch that costs money to move — the others are product work, this one is largely spend.
ARPU — 40p, £88kLast. Smallest effect, and price changes carry churn risk that could cancel out the gain from the branch above it.
What actually happened
They took churn, and the follow-on effect was the part the table
understated: with churn at 5.3%, average lifetime rose from 16 to 19
months, which raised the value of the conversion work they did the
quarter after.
Size each branch in the currency of the root, then check whether it is a
multiplier on the others. Multipliers beat addends of the same size.
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.
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.
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.
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.
What actually happened
The redrawn tree had six levers instead of nine. Three quarters of
roadmap effort had been going into two nodes that could not move the
root, and the team had read that as failure rather than as a fault in
the model.
Every node earns its place twice: it must reconcile with its parent, and
moving it must demonstrably move the parent. A node that fails the second
test is context — keep it, label it, and stop planning against it.