Kill criteria: decide in advance when to stop an idea
Run this method in IdeaHone
Creates a space with the entities and scoring criteria of this method, ready for your next session.
Ideas rarely die of a clear no. They fade: the pilot keeps its budget line, its board and a monthly update nobody reads, and a year later it is still "in testing". Kill criteria end this. Before the test starts, you agree on the condition that stops it and write it down with a date, so stopping is a decision made in advance rather than an argument made later.
Why pilots run on long after they should stop
A pilot can run for well over a year because nobody wants to be the one who stops it. The sponsor liked the idea, the team has put evenings into it, and every review ends with "give it one more quarter". Nothing in that meeting is designed to produce a no.
A kill criterion moves the no into the past. The team agreed in January what failure looks like, so in April the question is "did the number arrive", not "do we still believe in this". It also protects the proposer: the idea missed the bar, nobody lost a fight.
What a kill criterion is
Three parts: a measurable condition, a date and a consequence. "If fewer than 20 of 100 invited customers use the refill station by 31 March, we stop and record why." Without the number you argue about what "not working" means. Without the date the test never ends. Without the consequence the number arrives and nothing happens.
Good criteria come from three places: the riskiest assumption of the idea (the one belief that, if wrong, makes the rest irrelevant), the number that would make the sponsor say no (ask directly, most sponsors have one in mind and have never said it out loud), and the cost line you will not cross.
How to set kill criteria
- Name the one assumption that would kill the idea. Not the five things that could go wrong, the one thing that must be true. For a refill station it is "customers will walk to it", not "the supplier delivers on time".
- Turn it into a number and a date. "Customers will use it" becomes "20 of 100 invited customers use it at least once by 31 March". Pick a number the team would be embarrassed to miss.
- Agree the number with the sponsor before the test. Once data is on the table every number looks negotiable. Get the yes in the meeting that approves the budget.
- Write it into the decision log next to the go. Go and stop belong on the same line of the decision log. Tools like IdeaHone record decisions with their reason, which is where the criterion belongs.
- Name who checks it and when. One person, one date in the calendar. If nobody owns the check, the date passes and the pilot continues by default.
- At the date, decide in ten minutes. Three exits: stop, continue, or change the criterion once, with a written reason. Longer means someone is arguing with the number.
- Record the stop with the reason. "Stopped 2 April: 11 of 100 used it, the walk was too far." Without the reason the idea comes back unchanged in the next workshop.
Three examples
| Idea | Kill criterion | Date | Who checks |
|---|---|---|---|
| Refill station in the flagship store | Fewer than 20 of 100 invited customers use it at least once | 31 March | Product owner |
| Internal chatbot for IT requests | Fewer than 30 % of the pilot team's tickets start in the bot in week four | 15 May | Service desk lead |
| Supplier self-service portal | Fewer than 5 of 12 pilot suppliers upload an invoice without calling support | 30 June | Procurement lead |
Pair every kill criterion with a continue criterion. "Fewer than 20 means stop, more than 40 means we scale, in between we extend once by six weeks." The review then has two clear exits and a narrow middle, not a debate.
A criterion changed twice is no criterion. The first change can be an honest correction. The second means the idea is being kept for other reasons, and those belong in the log by name: a sponsor's public commitment, a promise to a customer, the money already spent.
Mistakes that make kill criteria toothless
- Criteria set after the first data. Once you have seen 11 of 100, every threshold below 11 looks reasonable.
- Vague conditions. "If it does not work" cannot be met or missed. No number and no date, no criterion.
- Nobody assigned to check. A criterion without an owner is a wish. The date passes in silence.
- Stopping without recording why. The idea returns in six months with the same assumption untested, one of the ways ideas die after the workshop twice.
- Treating a stop as the proposer's failure. If stopping costs reputation, the next criteria will be set to pass. Saying "stopped, criterion missed, well run" out loud in the decision workshop fixes this faster than any policy.
Never lose an idea between sessions
IdeaHone follows every idea from first mention to decision, across all your workshops and teams.
What are kill criteria?
Conditions agreed before a test or pilot starts that end it if they are met. Each has a measurable condition, a date and a consequence, such as "fewer than 20 of 100 invited customers by 31 March".
When should you set kill criteria?
When the idea gets its go, in the same meeting and the same log entry as the budget. Set after the first data arrives, every threshold becomes negotiable.
What happens when a kill criterion is met?
The named owner brings the number to a ten-minute review with three exits: stop, continue, or change the criterion once with a written reason. A stop is recorded with its reason so the idea does not come back unchanged.
