Lester Leong
How to Build a Metric Tree That Connects Daily Work to Revenue
A Dashboard Is a Pile. A Metric Tree Is a Structure.
Most dashboards are an unstructured pile of numbers. Revenue sits next to active users sits next to NPS sits next to a churn percentage sits next to a funnel chart, and nothing on the screen tells you how any of these relate to each other. You can stare at twenty metrics for an hour and still not be able to answer the only question that matters: if I want revenue to go up, which number do I push, and who pushes it. The dashboard shows you the outputs of the business. It does not show you the math of the business.
A metric tree fixes this. It takes a single top-level output metric, revenue or net revenue retention or the north star, and decomposes it into the input drivers that produce it, by identity, all the way down to metrics an individual contributor can move this week. Every node in the tree either multiplies or sums into its parent. That constraint is the entire point. It makes the arithmetic of the business explicit, it lets every team own a specific node, and it closes the two gaps that quietly kill analytics functions: the gap where your best analysis never drives a decision, and the gap where leadership stares at output metrics nobody knows how to influence.
I have built or rebuilt this structure in three very different environments. Working with 20+ SMBs and startups through Gradient Growth, the most common engagement opener I see is a dashboard with thirty metrics and no spine connecting them. At a financial social media startup before its acquisition, we replaced a flat KPI deck with a tree that let three teams each own a branch and stop fighting over the same blended number. And now on a GenAI squad at a major finance technology company, where the scale is large enough that the decomposition has to be exact, because an approximate tree at that scale silently routes effort to the wrong leaf. In every case the value was not a prettier dashboard. It was that work at the bottom of the org could finally be traced to revenue at the top.
Why a Pile of Metrics Fails
The failure mode of an unstructured dashboard is not that the metrics are wrong. Each one might be measured correctly. The failure is that they have no declared relationships, so the dashboard cannot tell you what causes what, and therefore cannot tell you what to do.
When revenue drops, a flat dashboard gives you a wall of numbers that all also moved, and no way to know which movement was the cause and which were symptoms. You end up in a meeting where one person blames pricing, another blames churn, a third blames the top of the funnel, and the debate is settled by seniority rather than arithmetic. I have written before about why [your best analysis so often fails to drive any action](/insights/data-analysis-doesnt-drive-action). A large part of the answer is structural. If the metric is not connected to a lever someone owns, the analysis terminates in a slide, not a decision.
There is a second, subtler failure. Flat dashboards overweight output metrics because outputs are what leadership cares about, but outputs are precisely the metrics no single person can move directly. Revenue is not a lever. It is the result of pulling many levers. A team told to "grow revenue" with no decomposition has been handed a goal, not a job. The distinction between the lagging results you report and the leading drivers you actually control is the heart of the [input metrics versus output metrics](/insights/input-metrics-vs-output-metrics) problem, and a metric tree is the cleanest way to make that distinction operational rather than philosophical.
The Identity: Why Nodes Must Compose Into Their Parent
The discipline that separates a metric tree from a mind map is one rule: every child node must compose into its parent through arithmetic, multiplication or addition, with no hand-waving in between. If you cannot write the parent as a function of its children, the children are not really children. They are just nearby metrics, and you have drawn an org chart of vibes.
Start at the top with revenue and decompose it by identity:
``` Revenue = Active Users x Conversion to Paid x ARPU ```
Read this as a literal equation. The number of active users, times the share of them who convert to paid, times the average revenue per paying user, equals revenue. This is not a model with error terms. It is an identity. It is true by construction, which means the moment you change one factor and hold the others constant, revenue moves in a way you can predict exactly.
Now expand a node. Active users is itself a flow, and the cleanest identity for it is the accounting of how a user base changes period over period:
``` Active Users (this period) = Retained + New + Resurrected ```
Some share of last period's base is retained, new users arrive, and previously lapsed users are resurrected. Sum those three inflows and you have this period's active base. Churn does not appear as a separate term because it is the mirror image of retention: every prior-period user either stays (Retained) or leaves (Churned), so churn is the force that shrinks the Retained term rather than a fourth addend. This is still an identity, not a forecast. Each flow is owned by a different motion: acquisition owns New, lifecycle and [reactivation programs](/insights/user-reactivation-rate) own Resurrected, the core product loop owns Retained, and the entire retention apparatus owns what suppresses it, Churned.
Keep going on any branch until you reach a node an individual contributor can actually move. Retained, for example, is still too abstract for a single person. Decompose it toward something ownable:
``` Retained = Activated Users (reached first value) x Week-4 Activation Survival ... Activated Users = New Users x Activation Rate (completed the core setup step) Activation Rate = Users completing step 3 / Users entering step 1 ```
At the bottom of that chain sits activation rate, defined as the share of new users who complete the core setup step, expressed as a step conversion. That is a leaf an individual contributor owns. A growth engineer can run an experiment on the onboarding flow this week and watch that single number move, and because every node above it composes by identity, the engineer can also see the path by which a five-point lift in activation rate propagates up through retained users, through active users, and into revenue.
A Worked Numeric Example
Numbers make the leverage concrete. Take a business with these values:
``` Active Users = 50,000 Conversion to Paid = 4.0 percent ARPU (monthly) = 80 dollars
Revenue = 50,000 x 0.04 x 80 = 160,000 dollars per month ```
Now suppose the activation team, working at the very bottom of the tree, lifts activation rate from 25 percent to 30 percent. Trace it up. Assume new users run at 8,000 per period and the activation lift carries through to retained users such that the active base grows by roughly 6 percent, to 53,000. Hold conversion and ARPU constant:
``` Revenue = 53,000 x 0.04 x 80 = 169,600 dollars per month ```
A five-percentage-point move on a single leaf metric, owned by one team, produced a 9,600 dollar per month gain, about 6 percent of revenue, and the tree shows you exactly why. Compare that to a different team improving conversion to paid from 4.0 percent to 4.4 percent on the original base:
``` Revenue = 50,000 x 0.044 x 80 = 176,000 dollars per month ```
A 0.4-point conversion gain is worth more here than the activation gain, 16,000 versus 9,600. That is not obvious from a dashboard. It is obvious from the tree, because the tree lets you compute the marginal revenue value of each leaf and rank where effort should go. This is the planning conversation a flat dashboard can never host: not "which metric looks bad" but "which movable leaf returns the most revenue per unit of effort."
Building the Tree in Four Steps
The construction is mechanical once you accept the identity discipline. Four steps.
Step 1: Start From a Single Output
The apex of the tree is exactly one output metric. Not three, not a balanced scorecard. One. This is usually revenue, net revenue retention, or your [north star metric](/insights/north-star-metric-framework) if you have defined one properly, since a good north star is already a proxy for durable revenue. If you cannot agree on the single number at the top, stop and resolve that first, because every decomposition below it is a decomposition of something, and the something has to be settled. A tree with two roots is two trees, and teams will optimize whichever root flatters their work.
Step 2: Decompose by Identity, Not by Vibes
Expand the apex into the two to four factors that multiply or sum into it, and verify the arithmetic before you move on. The test is brutal and simple: can you write the parent as an equation of the children. Revenue equals active users times conversion times ARPU passes. "Revenue is driven by brand, product quality, and sales effort" fails, because you cannot multiply brand by product quality and get dollars. Vibes-based decomposition feels insightful and produces a tree that cannot be used for arithmetic, which means it cannot rank leaves, which means it is decoration. Decompose each level the same way until you hit metrics granular enough for one team to own.
Step 3: Assign Ownership to Every Leaf
A node nobody owns will not move. Walk the leaves and assign each one to a specific team or, better, a specific person. Activation rate belongs to growth. Step-three funnel conversion belongs to whoever owns that step. Churn in a particular cohort belongs to retention or to customer success. If two teams claim a leaf, the leaf is under-decomposed; split it until each piece has a single owner. If no team will claim a leaf, you have found either an orphaned metric or a gap in your org, and both are worth surfacing. Ownership is what converts the tree from an analysis artifact into an operating system, and it is the step most teams skip, which is why their trees end up [as decoration on a dashboard nobody acts on](/insights/why-dashboards-fail).
Step 4: Instrument Every Leaf
A leaf you cannot measure cannot be owned in practice, only in theory. For each leaf, confirm there is event instrumentation that produces the number on the cadence the owner needs, daily or weekly, segmentable by cohort. If activation rate is a leaf, you need events for entering step one and completing step three, joined per user. If a leaf turns out to be uninstrumentable, you either instrument it or you re-decompose the parent into leaves you can measure. An owned-but-unmeasured leaf is the worst of both worlds: a team is accountable for a number that does not exist.
The Discipline That Keeps It Honest
The single thing that degrades a metric tree over time is drift away from the identity. Someone adds a node because it feels related, not because it composes. Someone redefines active users in one branch but not another. Someone slips a ratio in where a count belongs. Each small violation breaks the arithmetic, and once the arithmetic is broken the tree can no longer rank leaves or trace movements, which was the entire reason it beat the flat dashboard.
Guard it with a recurring audit. For each parent, recompute it from its children and confirm the numbers reconcile within rounding. If they do not, a node is mis-defined, double-counted, or measured over the wrong window. At the major finance technology company, where the active base is large enough that a one-percent definitional mismatch hides a meaningful number of users, this reconciliation runs as a standing check rather than a one-time build step, because at scale an approximate tree quietly misallocates real headcount toward leaves that look high-leverage but are not. A tree whose nodes reconcile is a tree you can plan with. A tree whose nodes do not is a diagram.
The tree also has a natural relationship to the rest of your metric stack that is worth making explicit. The apex is your output, the lagging result you report to the board. The leaves are your inputs, the leading drivers your teams actually pull. The layers in between are the transmission. When people debate whether a given metric is an input or an output, the answer is usually "it depends on where you stand in the tree," and the tree makes that relative position concrete. A node is an output to its children and an input to its parent. That framing dissolves most of the [input-versus-output arguments](/insights/input-metrics-vs-output-metrics) that consume planning meetings, because the tree shows that nearly every metric is both, depending on the altitude you are looking from.
What Changes When You Have One
The first thing that changes is the planning conversation. Instead of arguing about which metric looks worst, the team computes the marginal revenue value of each movable leaf and ranks them. Effort flows to the leaf with the highest return per unit of work, and that ranking is defensible because it is arithmetic, not opinion.
The second thing that changes is accountability. Every team can see its node, see what its node multiplies into, and see the path from a number they move this week to the number leadership reports this quarter. The analyst who improves a funnel step is no longer producing a slide that dies in a meeting. They are moving a leaf with a known revenue coefficient, and the tree proves it.
The third thing that changes is diagnosis. When revenue drops, you do not start a debate. You walk the tree, recompute each node, and find the branch where the arithmetic broke. The cause is the node whose change, propagated up through the identities, accounts for the drop. Diagnosis becomes a traversal instead of an argument.
None of this requires new data. Most teams I work with can build a first usable tree in a week from event data they already have, because the hard part was never instrumentation. The hard part is the discipline of the identity: insisting that every node compose into its parent, refusing to add a node that does not, and auditing the reconciliation so the tree stays honest. Do that, and you replace the pile with a structure that connects the work an individual contributor does on a Tuesday to the revenue the company reports at the end of the quarter. That connection is the whole job of an analytics function, and a metric tree is the cleanest way I know to build it.
---
I help teams replace flat dashboards with metric trees that connect daily work to revenue. [lester@gradientgrowth.com](mailto:lester@gradientgrowth.com)