Your KPI tree is probably a graph

Every product team I’ve worked with has, at some point, sat down and built a KPI tree. North Star at the top, two or three driver metrics under it, leading indicators branching out from those. It’s a useful exercise. It produces a chart you can put on the wall.

The problem is that the metrics under your North Star are almost never an actual tree. They’re a graph — with cycles, shared dependencies, and edges that change direction depending on the cohort you’re looking at. And the moment you commit to drawing them as a tree, your roadmap starts optimizing for the wrong joints.

The simplest version of the problem

Take a subscription app. North Star: revenue. Drivers: paying users × ARPPU. Under paying users: trial starts × trial-to-paid. Under trial starts: installs × install-to-trial.

Drawn that way, the team’s leverage on revenue runs cleanly from the bottom up. Improve install-to-trial 10%, push that gain up the tree, watch revenue climb.

Except the cohort you optimized install-to-trial on probably has a worse trial-to-paid rate than the cohort you were getting before. Because the easiest way to lift install-to-trial is to lower the trial’s friction, which means more people start it who weren’t going to pay. The “leading indicator” eats the “lagging indicator” from below.

The metrics weren’t a tree. They were a feedback loop, and the team optimized the loop in the direction that made the dashboard look good for two weeks.

What I do instead

I draw the metrics as a graph, on purpose. Every node has edges going both into it and out of it. Then I label each edge with the elasticity I’d expect: if I lift this metric by X, how much does that metric move, and over what window?

The labelling is the boring part. It’s also the part that catches the loops. You’ll find at least two pairs of metrics where the elasticities go opposite ways depending on which cohort you slice on — and those are the ones to argue about, not the headline lift numbers.

The cheap fix

You don’t need a new dashboard tool to do this. You need:

1. A whiteboard or a Figma frame.
2. The honest list of every metric your team actually uses to make decisions. (Not the ones in the deck. The ones in Slack.)
3. Forty-five minutes with the two people who run the experiments.

Draw the edges. Argue about the elasticities. The first version will be wrong. The second version will save your team a quarter of roadmap energy.

The tree was always a story you told a board. The graph is the model you’re actually shipping against.

Build the graph. Keep the tree for the board deck.