When should we kill a product?

The strongest signals are behavioral: planning cycles pass without anyone advocating for it, new customers stop choosing it so the base only ages, your best people ask to move off it, and sales routes around it. Countervailing signals matter too — if the product anchors renewals or there is no migration path ready, the time is not yet, whatever the strategy says.

How do we sunset a product without losing customers?

Most of the trust is won or lost in sequencing. Work out who hears from a named human before anything is published — the accounts with the deepest dependency should not find out from a press release or a rival's sales team. Settle the contract questions first so the announcement can answer them: whether existing terms run to their end date, when new sales stop, and what happens to renewals already in flight. Give the transition one owner, so questions land somewhere rather than bouncing between support and sales. And keep the documentation and the data export working past the shutdown date, since customers remember whether they could retrieve their own work long after they have forgotten the timeline.

What does keeping a zombie product cost?

The costs are real but rarely assigned to it: leadership attention in every planning cycle, support load that concentrates in the oldest products, engineering drag from dependencies that go untouched, positioning blur across the portfolio, and recruiting drag when strong engineers see pure maintenance as the job. Because none of these appear as line items, zombie products can survive long after the case for them has ended.

Is selling the product an alternative to sunsetting it?

Sometimes. A divestiture can hand the installed base to an owner with a real reason to invest in it, which may serve those customers better than a shutdown. It brings its own diligence and transition costs, and it does not remove the obligation to manage customer trust through the change — it relocates it.

When to sunset a product

Guide · Founder · 4 min read · last verified 2026-07-28

Reviewed before publication Editorial board Independent commercial review

In shortThe full cost accounting on both sides of a sunset: what a zombie product consumes in attention, support, and positioning, what killing one costs in installed-base trust, the signals in each direction, and how to leave well.

Sunsetting a product means deciding to stop selling it, stop developing it, and — on a stated schedule — stop supporting it. It tends to be the decision founders defer longest, not because the analysis is hard but because the product is old enough to have customers, revenue, and sentiment attached. The deferral feels like safety. It is actually a decision in its own right: choosing, by default, to keep paying costs that never appear anywhere anyone looks.

Two adjacent decisions are covered elsewhere and deliberately not restated here: when to add a second product (when to build the second product) and when to shut down a marketing channel (when to kill a marketing channel). Removing a product from the world is harder than either, because customers built on it.

What keeping it costs

An unloved product still consumes. Leadership attention, first: every planning cycle has to steer around it, and every strategy conversation carries an asterisk. Support load, which tends to concentrate in the oldest products and versions. Engineering drag from dependencies that no team will volunteer to upgrade. Positioning blur — a portfolio that needs a paragraph to explain where it once needed a sentence. And a recruiting cost that is easy to miss: strong engineers ask what they would be working on, and maintenance of a product with no future is an answer they hear clearly. None of these costs appear as line items attributed to the product, which is precisely how zombie products survive — the costs are real but unassigned, while the remaining revenue is visible and defended.

What killing it costs

The exit is not free either. Your installed base — the customers actually running their work on the product (what is an installed base) — took a bet on you, and a sunset is the moment they learn how that bet ends. Handled badly, the damage does not stay contained: customers of your other products watch how you retire this one and quietly update their expectations for their own. Competitors will make your announcement part of their pitch. And some products earn strategically beyond what their own reporting shows — anchoring renewals, completing multi-product deals, holding a segment your newer offerings cannot yet serve. A sunset analysis that counts only the product's own revenue is answering a smaller question than the one being asked.

Signals the time has come

The persuasive signals are behavioral rather than financial:

Planning cycles pass without a single advocate; the roadmap receives only keep-alive work.
New customers stop choosing it even when it is offered, so the installed base only ages.
Your strongest people ask to move off it, and staffing it starts to feel like an apology.
Sales stops demoing it and solutions teams route around it.
Its architecture blocks work on the products that do have a future.

The current AI cycle is producing fresh examples: assistants, copilots, and AI add-ons shipped quickly during the platform rush, some of which never found sustained use and are now being quietly retired across the industry. The lesson is not that shipping them was wrong. It is that retirement is a normal part of the product lifecycle, not a confession of failure.

Signals it should live

Sometimes the reading points the other way. If the product anchors renewals or completes deals for the rest of the portfolio, its value is partly invisible in its own reporting. If it serves customers your successor product cannot yet absorb, a sunset transfers pain directly onto your most loyal accounts. And if no migration path exists yet, the timing is wrong regardless of the strategy: announcing an ending before the destination exists converts a portfolio decision into a trust incident. Keep-decisions made on these grounds are legitimate. The only failure mode is the keep-decision made by silence — the one nobody argued for because nobody raised it.

Leaving well

The mechanics of a good exit are mostly about the base. A schedule generous enough for real migration, communicated to affected customers before the market hears it from anyone else. A named destination: your newer product, a managed downgrade to a simpler arrangement (what is a managed downgrade), or the concession that another vendor now serves this need better than you will. Migration help that is honest about its own weight — moving customers is genuinely expensive in effort and goodwill, which is why free-migration promises deserve scrutiny of their own (free migrations cost more than the discount you avoided giving). The installed base will usually forgive the decision far more readily than it forgives discovering the decision late.

The deferral is the decision

Founders defer sunsets for humane reasons. It is often the founding product; the people who built it are still in the room; the revenue, though flat, is real. But zombie status is not neutral ground. Every additional quarter spends attention, blurs the story, and ages the base further, while the eventual ending gets harder rather than easier. The useful reframe is that there is no option marked "decide later" — there is a sunset on your schedule, with a migration path and a message you control, or a sunset on the product's schedule, arriving eventually as an emergency. Choosing the first is not ruthlessness. It is the last act of stewardship the product gets.