Loop

To make sure the thing you are about to build is answering a question somebody wrote down. A loop is one turn of assumption, test, result and decision, and teams that skip the first and last steps tend to build continuously and learn nothing.

Use it when a team is busy but cannot say what it has learned this quarter. Writing the assumption before the work turns a feature release into an experiment, and it makes the result usable whichever way it goes.

Write the assumption as a sentence that could be wrong. "Users will pay for this" cannot be tested. "Ten of the next fifty trial accounts will upgrade without being contacted" can.

Then choose the smallest test that could change your mind, and decide in advance what result would make you stop. That last part is the one teams skip, and it is the one that stops a disproved assumption turning into another round of tweaks. Close the loop by writing what you decided, not just what happened.

The assumption gets written after the result. It is rarely deliberate: the test runs, the number is ambiguous, and the question quietly reshapes itself into one the number answers. Writing it down first, dated, is the whole defence.

The second failure is a loop with no stopping condition, which turns a disproved idea into an indefinite series of adjustments. The third is confusing shipping with learning. A release that nobody measured is not a turn of the loop, it is work. Close each loop with a written decision, even when the decision is to carry on unchanged.