A KPI Tree Is a Theory. A Living Map Keeps It Honest.

A KPI tree is not a diagram. It is the company's theory of how value gets created: retention drives revenue more than acquisition does, onboarding drives retention, speed matters more than price in this segment. It gets argued into shape at a planning offsite by the people who have to live with it, and it might be the most honest thing the company produces all year.

The roadmap is the other document, kept in another tool, and every line on it is a bet on the first one. The onboarding revamp is a claim: onboarding moves retention. The pricing test is a claim: price moves conversion. A company shipping forty projects a quarter is running forty experiments on its theory of value. Nobody has ever checked whether the two documents agree.

The hypothesis has no home

Ask where those hypotheses are written down. The project tool records what shipped. The dashboard records what the numbers did. Nobody recorded "we expect this work to move that driver by roughly this much," and it is not because people are lazy. That sentence has no system that holds it. It lives in meetings, threads, and heads, which is to say it evaporates.

Science works for one boring reason: the hypothesis is written before the result arrives, so the result has something to correct. A lab without a notebook can run experiments forever and learn nothing. Most companies are that lab, with better snacks.

OKRs were supposed to fix this. They became a third document.

The gap between the theory and the work is not a new discovery, and OKRs are the industry's confession that it is real. Write the beliefs down as objectives, attach measurable results, put the work underneath, review on a cadence. The instinct is exactly right.

Watch what actually happens, though. In most companies the OKRs never touch the KPI tree. They come from a different lineage, they are run by a different function, and they are written in a different room. The objectives are aspirations, the key results are hand-picked numbers, and neither is bound to the tree above them or the roadmap below them. The merge never happens. The company now has three documents that do not agree.

OKRs rot for the same reason every written-down version of the business rots: a record maintained beside the work always loses to the record the work runs through. A document cannot hold a loop.

The merge exists. You rent it.

Here is the proof that connecting the theory to the work is worth doing, and it is hiding in the most expensive corner of the economy. When a company gets truly serious about this, usually in a crisis, it hires a transformation office.

Look at what that actually is. A quantified target, decomposed into a value driver tree. Every initiative chartered against a specific driver, with a named owner and an expected impact written down before the work starts. A weekly cadence that tracks captured value against the plan and kills what is not working. That is the two documents merged, at last, and companies pay millions for it. McKinsey even sells software for it; the other big firms have their own versions.

So the merge is not a fantasy. It is proven practice with three limits. It is manual: armies of consultants hand-wire the numbers every week. It is episodic: the discipline lasts as long as the engagement, and the cadence decays the day they leave. And it is reserved for emergencies: nobody operates this way on a normal Tuesday. The most valuable operating discipline a company can buy exists only as a rental, and when the rental ends, the company goes back to its documents.

Nothing on the standard stack makes that discipline permanent. So we are building it.

We call ours the Living Map

The name is meant literally: the same KPI tree, alive, running the transformation office's discipline as a system instead of a program.

The base ships today. The tree is persistent and versioned, so it has a memory instead of a lifespan. On our demo company's map, New MRR is not a label on a slide; it is a node bound to the warehouse measure that computes it, carrying its formula, its owner, and the history of who changed it and why. This is the quiet difference everything else stands on: the offsite tree and the data that would test it normally live in different worlds, so the tree can only ever be re-argued. A grounded node can be checked.

Checking it looks like this. Click retention and you are not opening a dashboard; you are opening the belief. How the number has actually moved across the last four quarters. Where the movement lives: enterprise holding, SMB sliding since March. Which branches beneath it claim to move it. The formula that computes it, the owner who answers for it, and the history of who changed it and why. One node, one story: what we believe, what the data says, who answers for it. The tree you argued about at the offsite becomes the thing you walk through when a number surprises you.

And a checkable belief invites the obvious question: which of these branches is actually moving the number above it? Ask, and a deterministic engine does the arithmetic nobody does by hand. It starts from the dimensions that Cartographer's scan of the warehouse says are actually connected to that metric, ranks the drivers by how much of the movement each explains, and puts a confidence interval around every claim. No language model computes any of it. One boundary stated plainly: this is statistical evidence, not dollars. It tells you where the movement lives and how sure you can be, not what a point of retention is worth.

None of this replaces the stack you have. Dashboards show state; project tools manage execution; both are good at their jobs. The Living Map holds the one thing neither records: why this work deserves to exist, and what the company learned when it was done.

What keeps it from rotting

A map that everything attaches to could fill with garbage, so one split does most of the work: automate the structure, govern the meaning. Structure updates itself. The warehouse gets re-crawled, so a renamed table surfaces as a change instead of a silent break. Meaning goes through a human. Each branch is kept by the team that holds its meaning, definitions go live when that owner blesses them, and a human verdict is never overwritten by a rescan. A belief nobody owns is a belief nobody corrects.

And when the map cannot anchor an answer, it refuses. On one production run it declined a breakdown outright, answering that the value "should not be interpreted until the underlying issue is corrected," instead of rendering a clean chart that lied. A map you can trust is mostly a map that knows when to say no.

One loop, and a quarter around it

Put the pieces in a row and the whole idea is one loop. The tree holds the belief. The engine ranks the drivers. Projects attach to the drivers they claim to move, with the expectation written down before the work starts. Outcomes come back and land next to what was expected, and where they differ, the map proposes a correction that a human blesses through the same gate that guards definitions. Around the loop again, with a truer map than last quarter.

Here is one quarter of that loop, and to be clear, this is the destination, not the demo. The tree says onboarding drives retention. So the onboarding revamp goes on the map with its hypothesis written down: two points of retention expected, owner named, confidence stated. It ships in week six. The outcome lands in week ten: 0.6 points, concentrated in enterprise, flat in SMB.

On a static tree, that result becomes a slide argument: did onboarding work? Depends who you ask. On a Living Map, it becomes a proposed correction, the onboarding-to-retention edge is weaker for SMB than believed, reviewed and blessed by the owner of that branch. Next quarter plans from the corrected theory, not the original guess. Nobody redrew the tree at an offsite. The work corrected it.

And the honest line through all of this: the top of the loop ships today; the return path is the roadmap. Evidence is computed per question, not yet standing on every branch. Projects arrive as ranked recommendations at the end of an analysis; the standing portfolio pinned to the tree is being built, and outcomes are not yet traced back to the work that produced them. We would rather draw that line ourselves than let a demo imply it away.

The two documents, agreeing

So, the two sentences this essay has been building. A KPI tree shows how the company thinks value is created. A Living Map updates that belief as work happens. Between planning cycles, a tree waits to be redrawn. A map is never done being right; it is only ever getting truer or staler, and everything above exists to make truer the default.

There is a hallway test for whether your company needs this. Pick any project that shipped last quarter and ask: which number was it supposed to move, and what did we learn when it did not? If the answer lives in someone's memory of a meeting, the theory and the work are still two documents, and nobody is checking whether they agree.

And a map like this is not only for people. The same node a person clicks is the context an agent reads: grounded definitions, ranked drivers, expectations with outcomes attached. That is what it takes to run the business with clarity, and to lend that clarity to anything, human or AI, that asks the company a question. An agent answering from the Living Map is answering from the company's checked beliefs, not its vibes.

It starts smaller than the ambition suggests: one North Star, and the tree of drivers beneath it. That first branch is the whole thing in miniature.

Redrawing the tree more often will not get you there, because the asymmetry was never about effort. A tree is updated by argument. A map is corrected by the territory. In a company, the territory is the work, and a tree becomes a map on the day the work is allowed to redraw it.