GuidesHow to2 min
How to kill a project that is not working
Use the stop rule you wrote on day one. A clean kill is a result. A zombie project is how next month disappears.
Identity attached to a bet will ignore a dead metric. Separate the person’s worth from the prototype’s worth or you will ship pride. A clean kill is a result. A zombie project is how next month disappears.
SINLE writes the stop rule on day one of a Spark. If the evidence shows up — no adoption, demo-only data, a blocking claim — we stop in the same week and change the statement of work. We will not renegotiate the rule because time was already spent. The time is already gone. The next month is not.
Use the sequence below on any live bet, including ours. Treat a kill as a result, not a scandal.
A kill you can say out loud
Bring the original page. If adoption is a visit, if it only works on demo data, or if the people who do the job will not touch it, stop the same week. Say it in the room: this bet is dead, the learning stays, the next month is not already spent. Do not average it with a live bet so a slide can say 50%.
Sunk cost is a bad judge. The time is gone. The invoice for next month is not.
The sequence
Do these in order. Skip a line and you are back to a workshop.
- 01
Bring the original page
Job, unknown, stop evidence. If that page never existed, write it now — then obey it.
- 02
Look at adoption, not activity
Hours returned and whether people kept the new way. Patents and workshops do not count.
- 03
If the prototype only works on demo data, stop
Pretty results that need the inventor are not a product.
- 04
If the people who do the job will not touch it, stop
You visited. Keep the learning. Do not keep the project.
- 05
Kill it in public
One dead project and one live one is not “50% success.” Averages are how bad bets hide.
- 06
Leave the time already spent in the past
Sunk cost is a terrible judge. The next month is not already gone.
Keep these
- A team that cannot kill will only ship theatre.
- Treat a kill as a result, not a scandal.
Do this before you spend
- 01Put the original stop rule next to this month’s numbers.
- 02If the rule fired, kill it in writing this week.
- 03Cancel the next slice. Do not renegotiate the rule because time was spent.
If you want a stop rule written before the money goes in, that is what Spark is for. We will obey it later, including against our own build.
Questions
- How do you know an innovation project should stop?
- The evidence you named on day one showed up, the prototype only works in the demo, or the people who do the job will not use it. Stop in the same week. Do not renegotiate the rule.
Next how-to
- How to stand up an R&D podDo not hire a chief of innovation first. One unknown, two or three people, a kill rule on day one, and a door into the real work.
- How to test an idea before you buildA test is a user, a thin lie, and a number. If you cannot fake it this week, you are not ready to spend on the real thing.
- How to measure whether the new way stuckOne outcome metric, one adoption metric, a date. Ideas and patents measure activity. Friday measures innovation.
Next
Write the stop rule before the next invoice.
Spark puts the kill rule on the same page as the hope. $750. If the evidence shows up later, the scope changes.