The Kill Criteria Nobody Writes
Every product team writes success metrics. Almost none writes the metric that would tell them to stop. That asymmetry is why dead products keep getting funded.
Open any PRD or pitch deck. Find the success metrics section. It's there. Specific numbers, time horizons, sometimes a confidence interval. Teams take success metrics seriously.
Now find the kill metrics section. The numbers that would tell the team to stop building this feature, this product, this entire bet. Almost certainly not there. If it's there, it's a hedge — 'if metrics don't move, we will reassess.' That's not a kill criterion. That's a stalling tactic.
The asymmetry is everywhere. Every product organization writes the conditions for victory. Almost none writes the conditions for retreat. The result: products that should have been killed at month four limp on through year two because there was never a pre-committed threshold below which they would die.
Three reasons.
First, kill criteria feel pessimistic. Writing one feels like predicting failure. Founders, PMs, and engineers all selected into this work because they're optimistic. Asking them to write the failure condition feels like asking them to plant doubt in their own work. So they don't.
Second, kill criteria have a political cost. The PM who writes 'kill the feature if MAU < X by month six' is creating accountability for themselves. If month six comes and MAU is X minus one, the PM either has to defend why the original threshold was wrong or admit the bet failed. Both are uncomfortable. Vagueness is more comfortable.
Third, kill criteria are harder to write than success criteria. Success criteria can be aspirational. Kill criteria have to be specific enough to be unambiguous. 'Kill if traction is poor' is useless. 'Kill if weekly active users < 200 after twelve weeks of marketing' is a real kill criterion. Writing the second one requires you to know what the floor of viability actually is. Most teams don't know.
If you can't write the floor of viability, you don't understand the bet you're making.
Three lines. That's the whole format.
Line 1: the metric. Be specific. Not 'engagement.' Weekly active users, retention at week 4, completion rate on the core flow, etc.
Line 2: the threshold. A specific number. Not a range. Not a percentile. The number below which you would kill the work.
Line 3: the date. The point in time at which you will look at the metric and execute the kill. Not 'around month six.' A specific calendar date.
Example: 'Kill criterion: if we are below 500 weekly active users on August 31, we will stop further development on this feature and reallocate the team.'
That sentence does more for product discipline than a quarterly OKR review.
Permission. Kill criteria are a permission slip the team writes itself, before the team needs permission.
When August 31 arrives and weekly active users are 380, the team doesn't have to convince anyone to kill the feature. The decision was made in March. The team executes it. Resources flow to the next bet. The lost effort is mourned for one Slack thread and then nobody talks about it again.
Without a kill criterion, that same August 31 conversation becomes a multi-week debate about whether 380 is 'enough' to keep going, whether the team needs more marketing, whether the metric is even the right metric. Three months later, the team is still building, still under threshold, still hoping. Kill criteria are how product organizations cut their losses without psychodrama.