Killing a Product Without Killing Momentum
Deprecating a project is a skill. How to shut one down cleanly and carry the lessons forward.
By FGA Labs
If you run many bets, you will kill many products. That is not failure — it is the system working. But how you shut something down matters enormously, both for your own morale and for what you carry into the next thing. Done badly, a shutdown feels like a loss. Done well, it feels like closing a chapter and keeping the notes.
Decide the criteria before you are attached
The reason killing products is so hard is sunk cost — you can always tell yourself one more feature will turn it around. The antidote is to decide, early and in writing, what 'this is not working' looks like. When you hit those markers, the decision is already made; you are just executing it. That is far easier than trying to be objective about something you have poured months into.
Shut down cleanly
- Be honest with any users — a clear wind-down beats a product that silently rots.
- Preserve the reusable parts; a dead product often leaves live, useful components behind.
- Mark it deprecated plainly rather than pretending it is still active.
Harvest the lessons
Every product that did not work knows something. Before you move on, write down what you learned — about the market, the idea, or your own process. The failed project's real output is often that knowledge, and it compounds into the next attempt if you bother to capture it.
A product you killed cleanly is not a loss on the books. It is tuition you already paid — collect the lesson.
Protect the momentum
The danger in a shutdown is letting it become a referendum on the whole studio. It is not. One bet ending is how a portfolio is supposed to work. Name what you learned, bank the reusable pieces, and point the freed-up attention at something with more life in it. Momentum comes from moving on cleanly, not from clinging.
