A Kill Criterion Has to Be Readable the Day It Is Set

The case for writing a stop condition before a project begins is familiar to most leadership teams by now, and it is the subject of an earlier note in this series: the decision is cheapest before anyone has a sunk cost to defend. Fewer teams look closely at what happens in the meeting where the condition is actually set. That meeting is short, it comes at the end of an approval discussion, and everyone in it wants the project to start.

The setting meeting

The pattern is consistent enough to describe. The sponsor proposes a criterion. The approvers, who have just agreed that the work is worth doing, have little appetite for making it harder to continue. The wording is adjusted until nobody in the room expects it to bite, and then it is recorded. Nothing dishonest has happened. Everyone present wants the work to succeed, and a condition that might stop it feels, in that moment, like a vote against it.

A kill criterion set by people who want the project to start tends to describe a failure nobody expects to see. The rest of this note follows one pattern, seen in more than one digital banking product team, through the places where a criterion loses its force at the moment it is written.

A case from a payments team

A product team in a digital bank proposed a redesigned payment-request feature for small business customers. The premise was that business customers who sent invoices through the app would come back to it more often. The criterion agreed at approval read well: if repeat use among business customers had not risen by the end of the second quarter after launch, the work would stop and the team would return to the core payments roadmap.

On the review date, nobody could read it. Repeat use was not tracked by customer segment. The analytics events for the new flow had been moved to a later release to protect the launch date. The figure that did exist covered all customers, so any change among business customers was diluted beyond recognition. The review produced a request for better data and a quarter's extension, and the extension produced a second request for better data.

Three ways a criterion goes soft at birth

The payments case shows the most common failure, but it tends to travel with two others, and a criterion set in a hurry usually carries at least one of them:

• The measure does not exist yet. Reading the criterion depends on instrumentation the project has not built, so the reading waits on the project's own backlog.
• The threshold is the forecast. The criterion restates the target in the business case, so missing it reads as a delivery shortfall rather than as evidence about the premise.
• The signal arrives after the money is spent. The criterion names a lagging result, such as revenue or retention, that cannot move before most of the budget is gone.

A criterion that cannot be measured on its date is a postponement written in advance. In the payments case, the measurement work would have cost about two sprints. It was cut at approval because it did not move the feature forward, and that one cut settled the outcome of every review that followed.

Forecast and premise are different sentences

A business case contains two kinds of claim. The forecast says what the project will deliver: a revenue figure, an adoption curve, a cost saving. The premise says why it will deliver it: a belief about how customers, a partner or a process will behave. The forecast depends on execution, timing, pricing and some luck. The premise is narrower, and it can usually be tested earlier and more cheaply.

When a criterion copies the forecast, missing it opens an argument about execution. The team points to a late dependency or a slow launch, and the argument is often fair. When a criterion tests the premise, the reading is harder to dispute. In the payments case, the premise was that invoicing would bring business customers back. A usable criterion would have asked whether customers in a named pilot group who sent an invoice in their first month sent another in their second, read from a single event the team built before launch. The premise can be checked in weeks; the forecast takes the whole budget to disprove.

Signals that arrive in time

The working test is whether the signal can move before most of the money is spent. If it cannot, the criterion is a post-mortem rather than a stop condition. Leading signals look less impressive on an approval slide, which is part of why they are dropped. They are also the only ones that arrive while there is still something to save.

The dry-run reading

The repair is mechanical. Before the project starts, the criterion is read once, against current data, by the person who will read it on the review date. Where the measure needs a baseline that does not exist, building it becomes the first piece of work, scheduled ahead of the feature rather than behind it. If the reader cannot produce a number today, the criterion is not finished.

This step changes the setting meeting more than it appears to. It turns an abstract agreement into a practical task with a name and a date attached. It also removes the most common defence at review time, that the number was never available, because everyone agreed in advance that it was.

A criterion nobody has measured yet is a promise to find out later whether it was a criterion at all.

Who writes which part

The second change concerns authorship. A sponsor drafting their own stop condition is in the same position as a sponsor deciding their own cancellation, which is why the kill decision needs an owner who is not the sponsor. The sponsor proposes the premise. A finance partner or the lead of an adjacent team writes the measure and the threshold. The portfolio owner agrees the date. Each part is then held by someone with a reason to keep it honest, and the record that comes out of the meeting is short:

• the premise in one sentence, kept separate from the forecast
• the measure, its reading today, and the person who will read it again
• the threshold and the review date, in the regular review cadence
• what is kept if the project stops

Most of the work happens in one session per project, at approval, and it takes less time than the business case did. For projects already running, the starting point is the current initiative list: beside each item, the premise, the measure, and whether anyone can read that measure today. The items where nobody can are running without a stop condition, whatever the approval paper says.

That review sits inside our consulting work on growth discipline, and it often leads into a capacity ledger for the portfolio as a whole. A stop condition that can be read on the day it is set is the cheapest control a portfolio will ever have.