A metric tree you can actually defend

The problem

The first tree I drew in January 2026 had eleven nodes on the first level. Each node had a chart. The weekly slide looked busy and therefore serious. In the review, nobody could say which number would change a decision that week. When a number moved, the conversation jumped to a different node that had also moved. The tree was a trophy wall. It could not be defended because it did not make a single argument.

A defendable tree has one outcome, a short set of inputs that could move that outcome, and guardrails that tell you when an input is being gamed. Diagnostics exist, but they do not sit on the weekly slide. The test of the tree is not whether it is complete. Completeness is how dashboards die. The test is whether someone who disagrees with your priority can still use the same tree to argue the other way, because the definitions are stable and the ownership is a role, not a personality.

This note is the shape that replaced the eleven-node drawing. It has been applied to a retention outcome, an activation outcome and a reliability outcome. The node names below are a worked example, not a claim about a named product. If you want the blank tree and the definition sheet, they are in the Library. The rules for what is allowed on the tree stay public.

The structure

1. Name one outcome that a reasonable adult could disagree with. “Be data-driven” is not an outcome. “Weekly retained teams” is an outcome, because someone can argue that new-team activation matters more this quarter. If nobody could disagree, you have written a slogan. The outcome gets a definition, a refresh cadence and an owner role before any input is added. Without those three, the rest of the tree is decoration.
2. Add at most three input metrics that could move the outcome. Inputs are causes you are willing to work on, not every correlate in the warehouse. Three is a ceiling, not a target. Each input needs a definition that does not mention a vendor field name. “Activation rate” means a specific event in a specific window. If the definition only makes sense inside one BI tool, you framed the tool, not the measurement — the same failure listed on the method page.
3. Add two guardrails that would stop you celebrating a bad win. Guardrails are the numbers that, if they worsen while an input improves, mean the input is being gamed or the system is being harmed. Support tickets per hundred accounts and p95 query time are typical shapes. A tree without guardrails invites local optimization. A tree with eight guardrails is another trophy wall. Two is enough to make the review honest.
4. Keep diagnostics off the weekly slide. Funnel step completion, cohort slices and “why it moved” charts are diagnostics. They are allowed in a teardown. They are not allowed to sit next to the outcome as if they had the same status. The moment a diagnostic is promoted because it is interesting, the tree stops being an argument and becomes a magazine. The monthly Library teardown is where diagnostics earn a page; the tree stays small.
5. Give every node an owner role and a refresh that matches use. Daily refresh of a weekly decision is theatre. Quarterly refresh of a weekly decision is negligence. Match the refresh to the meeting that uses the number. Owner roles are functions — measurement lead, product operations, reliability — not named people. When the org chart moves, the role remains and the roster is updated once. This is the same rule as the decision log, applied to numbers.

The tree in a table

One outcome, three inputs, two guardrails. The last row is a diagnostic that is defined so it cannot sneak onto the weekly slide without someone noticing the level label.

Where it breaks

It breaks when the outcome is a sum of vanity totals — accounts created, emails sent, page views. Those numbers always go up if the system is merely on. A tree rooted on a vanity total cannot be defended because there is no serious counter-argument. The refusal list in a later note exists for this case. If the outcome cannot change a decision when it falls, it is not an outcome.

It breaks when inputs are owned by the same role that presents the slide. There is then no one in the room whose job is to protect the definition. Drift starts as a “small SQL tweak” and ends as a new metric with the old name. The counter is a written definition with a dated edit, the same editorial rule as the rest of this notebook. Silent changes are treated as a new node.

It breaks in cross-functional programmes that demand every group see itself on the first level. That demand rebuilds the eleven-node drawing. The honest move is a second tree with its own outcome, not a wider first level. Two small trees can be compared. One large tree can only be admired. The method does not merge trees to make a steering group feel included.

Template

The Library file is a one-page tree worksheet: outcome, three input slots, two guardrail slots, a diagnostic parking lot, and a definition sheet with refresh and owner role. It also has the “what this dashboard should refuse to show” checklist so leftover charts have a place to be rejected. You can rebuild the table from this note; the file is for teams that want the blank version without redesigning the headers.

Get the template in the Library

Related notes

• The decision log that survives a reorg — decisions without a tree still guess at outcomes.
• Counting the things that resist counting — what to do when an input has no clean numerator.
• What a dashboard should refuse to show — the refusal list that keeps diagnostics off the weekly slide.