Kill a whole project when the next unit of work costs more than the upside you can still measure, and when the people on it have a clearer use elsewhere.
When killing is the right call
A project kill is broader than removing a feature. You are ending a roadmap, a budget line, and usually a team's identity around the work. That is justified when retention and revenue tied to the project are flat or falling, when support and on-call load stay high, and when every quarter of continuance delays a bet the company already ranked higher. Sunk cost and founder attachment are not evidence. Neither is a single loud customer if their spend cannot cover the people you keep assigned.
Give the review a clear task
- Pull active usage by cohort, not only total events.
- Attribute revenue, margin, and support cost to the project.
- Price opportunity cost against the roadmap that would replace it.
- Count headcount, contractor spend, and on-call still tied to it.
- Name contracts, integrations, and data obligations that survive a kill.
- Write the shutdown sequence: notice, migration, archive, and team reassignment.
If usage, revenue, opportunity cost, and team capacity disagree, the kill is premature. Keep the project only if one concrete test could reverse the picture on a date you will honor.
Run the review
Open Pingpong with the kill proposal, the four evidence piles above, and the alternative use of the team. The models review the original question and earlier answers in sequence, so one pass can argue for continuance, the next can attack sunk-cost bias, and a later pass can stress-test the shutdown plan. Ask for the reasoning behind each proposed change, then verify the numbers and obligations before you announce anything.