Keep a kill ledger or lose the only data you have

Ask a team what it shipped last year and you will get a list within a minute. Ask what it stopped, and why, and on what date, and you will get a pause, then three examples, then a story that has clearly been smoothed by retelling. The shipped work is documented because it is visible. The stopped work is undocumented because nobody has decided it is a result.

This is a strange asymmetry, because the stopped work is where the information density is. A shipped feature confounds a dozen decisions; you cannot tell which one mattered. A killed bet is clean: here is what we believed, here is what we saw, here is the line we said we would not cross. That is a complete record of a single judgement, and it is the only material from which calibration can be built.

The ledger itself is unglamorous — five fields, written the week the decision is made rather than at quarter-end when the reasoning has already become a narrative. What was believed, in the original words. What was observed, and when. The criterion as written before the result was known. What would have to change to reopen it. And then, quarterly, you read the whole thing for pattern rather than for verdict.

The patterns arrive faster than expected. Kills clustered after launch mean criteria are being written after the spend. Kills that all cite 'deprioritised' rather than an observation mean the team is running a backlog and calling it experimentation. No kills at all means either nothing is being tested or nothing is being finished — and either way, the absence is the finding.

One caution, learned the hard way by anyone who has tried this inside a large organisation: the moment a kill ledger becomes a performance-review input, it stops being true. People stop killing things, or they kill only the small safe things, and the record becomes a second layer of narrative on top of the first. The ledger has to be for learning or it should not exist.