How to run a UA kill decision

UA teams take kill decisions badly because the people taking them have the most to lose from the answer. The buyer who has spent four months on a channel, the producer who soft-launched the game, the UA lead who defended the budget: each is now asked whether to stop. The evidence is usually clear weeks before anyone takes the decision. What delays it isn't the data. It is that the decision has no owner other than the people it embarrasses.

The remedy is not more analysis. It is a process that moves the kill decision out of the hands of the operators and into a structure everyone agreed before anyone had anything to defend. Most of what follows applies to a game in soft launch as much as to a channel test, and to a market expansion as much as to a creative programme. The mechanics differ; the failure mode is the same.

Why the evidence arrives before the decision

Three forces hold a kill back once the numbers have turned.

Sunk cost is the obvious one and the least interesting, because everyone knows about it and it persists anyway. Knowing a bias exists does not remove it from a room where the sunk cost has names attached.

The second is optionality framed as prudence. Another two weeks of data feels cheap relative to the decision's size, so the team takes it. Then another two. Each extension is individually defensible; collectively they double the loss, and the team ends up paying for information it has already received.

The third force, and the one most coverage misses, is asymmetric visibility. A kill is a single visible event with an owner. Continued spend is a diffuse cost spread across weeks with no owner at all. Organisations punish visible events and ignore diffuse costs, so the rational individual defers the visible event. People remember the person who kills a channel a month too early; nobody remembers the one who kills it two months too late, because nobody tallies the second month.

The structure: decide who decides, before there is anything to decide

The core move is to separate three roles that usually collapse into one person.

• The operator runs the thing and reports on it. The operator does not vote on the kill.
• The owner set the criteria before spend began, holds the budget, and takes the decision. The owner is not the operator's line manager if that can be arranged, because a manager shares the operator's embarrassment.
• The challenger is a peer from another team whose only job at the review is to argue for the kill using the pre-agreed criteria.
• The challenger role rotates, so nobody becomes the studio's executioner.

The criteria themselves must be written before spend starts and must be specific enough that reasonable people cannot disagree about whether the team met them. A target of positive ROAS by month six is not a criterion. A criterion is: if predicted day-ninety cost recovery, using the model we have agreed and the cohorts up to the review date, is below a stated floor at the week-eight review, the owner kills unless the operator can name a single specific change already live that the model has not yet had time to see.

That last clause matters. It permits one, named, already-shipped intervention to earn one extension. It does not permit a roadmap.

The review itself

Run the kill review on a fixed date set at the start, not when someone calls it. A review called because the numbers turned arrives with a defensive room; a review that was always going to happen on this date arrives with a neutral one.

The agenda is short. The operator presents the numbers against the criteria, and nothing else. No context slides, no roadmap, no competitor comparison. The challenger presents the case for the kill. The operator may respond with the one-change clause or not at all. The owner decides in the room and writes down the reason in two sentences.

If the decision is to continue, the owner also writes down what the next review date is and what would trigger a kill at that date. The continue decision must be as specific as the kill decision would have been. A vague continue is the most expensive outcome available.

A worked illustration

An illustrative hybrid-casual publisher soft-launches a merge title in two test markets with a stated week-ten criterion on projected recovery. At week ten the projection sits below the floor by a margin that is not close. The operator has a case: a new meta layer shipped in week nine and early retention on the week-nine cohort is better.

Under the one-change clause, that earns a single extension to week fourteen, with the criterion restated: the week-nine and later cohorts must project above the floor on their own. At week fourteen they do not; they are better than earlier cohorts but still short. The owner kills. The whole process took four weeks longer than the original date and about a quarter of the additional spend the team would have requested under an open-ended continue.

The important thing about this illustration is not the numbers. It is that at no point did anyone have to argue that the team had failed. The criteria went unmet. That is a different sentence, and it is the sentence that lets a studio keep the people who ran the thing.

The second-order effect

A studio that kills cleanly will kill some things that would have worked. This is unavoidable, and the honest position is that a good kill process raises the number of false kills in exchange for a larger reduction in slow deaths. Teams that cannot tolerate the first will keep paying for the second.

There is a way to make the trade cheaper. After every kill, keep the build and the creative library archived, along with the measurement setup, in a state that a fortnight's work could relaunch. Some kills are really pauses waiting for a market change, and a studio that treats them as such can revisit without the cost of rebuilding. The ironSource shutdown in April forced several teams to re-home channel budget in a hurry; the ones who had cleanly archived earlier channel tests knew within days where that budget could go.

The last point is about what the process says to the people running the next test. If operators see that a kill is a criteria event rather than a career event, they will write honest criteria and report honest numbers. If they see the opposite, the criteria will get softer every quarter, and the studio will not know why its kill decisions keep arriving late.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• Soft launch UA plans and kill criteria
• Dashboards make UA teams slower