KPI tree
Also known as: KPI cascade, goal tree
A KPI tree is a diagram that breaks one top-level goal, such as revenue, down into the smaller metrics that drive it, so each team can see which number they own.
At the top sits one number the company is trying to move, usually revenue or a close proxy for it. Below that, the tree branches into the metrics that multiply or add up to the top number, and each branch belongs to a named person, not a department.
Example
A revenue goal of $500,000 for the quarter might branch into new customer revenue and expansion revenue. New customer revenue branches further into leads, the lead-to-deal conversion rate and average deal size: 2,000 leads at a 5% conversion rate produce 100 deals, and 100 deals at an average size of $4,000 produce the $400,000 the branch needs to contribute. The marketing lead owns the lead count, the sales lead owns the conversion rate, and the product lead owns average deal size through packaging.
Every number in this example is a placeholder to show how the branches multiply out, not a target from any real company.
How to use it
Build the tree from the top number down, not from a list of metrics someone already tracks. Stop branching once a metric has one clear owner who can move it without asking three other teams for help, since a tree that goes too deep just recreates the org chart. Review it in the same meeting every month, so the owners see how their branch moved the top number, not just their own metric in isolation.
A KPI tree also exposes double counting fast. If two branches both claim credit for the same 100 deals, the tree does not add up, and that mismatch is usually more useful than the tree itself.
Common mistakes
The most common mistake is building a tree with metrics nobody owns, which turns it into a reporting exercise rather than a management tool. A second is mixing lagging and leading indicators on the same branch without labelling which is which, so a team optimizes the wrong one. A third is rebuilding the tree every quarter from scratch instead of updating the same structure, which makes it impossible to see whether a branch actually improved over time.
A KPI tree works best next to revenue operations, since RevOps is usually the function that keeps the underlying data consistent enough for the tree to be trusted.