Verified impact: closing the loop

Most organisations are good at the first half of this loop and blind to the second. A metric drops, someone is assigned to fix it, the work gets done, and the task is marked complete. Everyone moves on. The question nobody returns to is the only one that matters: did it work?

The problem is not effort. Teams ship plenty of work. The problem is that the work is rarely connected back to the outcome it was supposed to produce. A completed task and a recovered metric are treated as the same thing, when in fact one is an input and the other is a result. Verified impact insists on keeping them separate, and on checking that the input produced the result.

Picture the standard sequence. A weekly review surfaces a metric that is off target. Someone takes the action item. A fortnight later the action item is closed. The review notes record it as resolved. But the metric was never checked again against the action, because the moment the task closed, attention moved to the next problem.

This is an open loop. Work flows in one direction, from decision to task to completion, and never feeds back. Over months, a team accumulates hundreds of closed tasks and almost no knowledge about which of them mattered. The completion rate looks healthy. The learning rate is close to zero.

The cost is subtle because nothing visibly breaks. The reviews still happen, the tasks still close, the dashboards still refresh. What is missing is the feedback that would let the team get better at choosing actions. A team can be busy and disciplined and still learn nothing, simply because it never closes the loop.

Closing the loop is not complicated, but it has to be deliberate. The key is to make the attribution at the moment you decide to act, not after the fact when the connection has already been lost. An action that is linked to a target metric and an expected effect can be checked. An action that is only described in prose cannot.

1. 1

   Name the metric the action is meant to move

   Before the work starts, attach the action to a specific metric in the tree. Not a theme, not a goal, a single measurable node. If you cannot name the metric, you cannot later check whether it changed.

2. 2

   State the expected direction and a rough size

   Record what you expect to happen: this action should raise activation rate, and a meaningful move would be two or three points within a month. A prediction made in advance turns the later check into a clean yes or no.

3. 3

   Set the window for the check

   Decide when the metric should have responded. Some actions move a number within days, others take a quarter. Without a window, the loop stays open indefinitely because there is never a natural moment to look back.

4. 4

   Assign the action to the accountable owner

   The action belongs to the person accountable for the target metric, so the same person who will be measured on the outcome is the person who decides on and runs the intervention. This is where attribution meets ownership.

5. 5

   Check the metric against the prediction

   When the window closes, compare what the metric did to what you said it would do. Mark the action as verified if the metric moved as expected, and as no observed effect if it did not. Either result is useful.

Attribution is only reliable when the metric the action targets sits inside a model of cause and effect. A metric tree gives the loop its anchor points. The action targets a driver, the driver feeds a parent, and the verification asks whether the change at the driver propagated upward the way the tree predicted. Without that structure, you are checking a number in isolation and hoping nothing else explains the move.

In this tree, an action aimed at lifting feature adoption is not a free-floating task. It targets a named driver of expansion revenue, which in turn drives net revenue retention. When the window closes, verification works at two levels. Did feature adoption rate move as predicted, and did the expected lift show up in expansion revenue above it? If adoption rose but expansion did not follow, the loop has surfaced something worth understanding, perhaps the causal link in the tree is weaker than assumed.

This is the difference between checking a metric and verifying an impact. Checking asks whether a number changed. Verifying asks whether the action caused the change to propagate the way the model said it would.

The reason verified impact matters is not bookkeeping. It is behavioural. People change how they work when they can see the consequences of their work, and the verification loop is what makes those consequences visible. When an owner knows that the action they choose this week will be checked against the metric in a month, the choice of action gets sharper. Vague work that cannot be measured becomes unattractive, because there is nowhere for it to be marked verified.

A dashboard asks you to look. A verification loop asks you to commit to a prediction and then face the result. That small act of committing in advance does most of the work. It moves the conversation from opinion to evidence, and it removes the comfortable ambiguity where every action is assumed to have helped because no one ever checked.

It also changes the tone of a review. Instead of relitigating whether something worked from memory and instinct, the team reads the verification. The action was taken, the metric was predicted to move two points, it moved nothing. That is not a debate, it is a finding. Reviews get shorter and more useful because the loop has already answered the question the room would otherwise argue about.

A single verified action is useful. A hundred of them is a different kind of asset. Once a team has been closing the loop for a while, it owns something most organisations never build: a record of which interventions move which metrics, and by how much. That record compounds. Each new action is chosen against the evidence of every action that came before it.

The compounding is what turns the loop from a process into an advantage. Two teams can run the same number of experiments in a year. The team with an open loop ends the year roughly where it started, a little busier. The team that verified its impact ends the year knowing which of its levers are real, which are weak, and which were illusions. That asymmetry grows every quarter, because the verified team keeps narrowing in on the actions that work while the other keeps guessing from scratch.

The hardest part of verified impact is not the idea, it is the follow-through. The check happens weeks after the decision, by which point the original prediction has usually been forgotten and the person who made it has moved on to other work. A loop that depends on someone remembering to look back will stay open most of the time. So the loop has to be carried by the system, not by memory.

1. 1

   Store the prediction with the action

   The target metric, the expected direction, the rough size, and the check window all live on the action itself. The commitment is recorded at the moment it is made, so there is nothing to reconstruct later.

2. 2

   Let the metric movement trigger the check

   When the target metric moves, push the change to the accountable owner rather than waiting for the next review. The metric itself reopens the question, which is what closes the loop reliably.

3. 3

   Make the verdict a first-class state

   An action is not simply done. It is verified, partially verified, or shows no observed effect. Completion and outcome are kept distinct, so a glance tells you which actions actually earned their place.

4. 4

   Surface the record where decisions are made

   When the next action is being chosen for a metric, show the history of what was tried on that metric before and how it fared. The library of past verifications becomes an input to the next decision, not an archive nobody reads.

This is the work KPI Tree exists to make routine. Every action is attached to a metric in the tree, the accountable owner is pushed the change when the metric moves, and the verified impact loop checks that the action did what it was meant to do. The loop runs because the platform runs it, not because someone remembers to. What a team is left with is the thing that actually compounds: a growing, honest account of which decisions moved the business, ready for the next decision to learn from.