Strategy · 5 min read

How to Decide Which Product to Shut Down

Compare each product's future contribution and strategic role with the capacity and complexity it consumes. Ignore sunk development spending when choosing the next investment, while accounting for obligations and transition costs. Choose explicitly among focused repair, maintenance, sale or transfer where feasible, and shutdown.

Define the decision you are actually making

Stopping new investment, stopping new sales, and ending support are different decisions. A product may deserve maintenance without further expansion, or a narrower customer segment without a complete shutdown. Write the alternatives with their operating consequences. A vague debate about whether the product is good can continue indefinitely because participants are defending different things. Clarify which future commitment is in question and what would change for customers, staff, and the rest of the portfolio under each option.

Look forward rather than defending sunk spending

Past development effort explains how you arrived here, but it cannot be recovered by spending more. Compare the costs and benefits that change from today onward. Include the real cost of keeping promises already made; those obligations are not sunk merely because the original sale happened earlier. This distinction prevents two errors: funding a weak product to justify its history, and pretending shutdown is free because future development work can simply stop.

Calculate contribution and scarce attention

Estimate receipts, costs caused by delivery and support, and the capacity consumed in the roles that constrain the business. Include recurring incidents, special tooling, sales explanations, and exceptions when they materially differ across products. Be cautious with overhead allocations that do not disappear after shutdown. A product with modest revenue may be economical to maintain; another with larger revenue may monopolize the team needed for a stronger opportunity. The question is the future use of limited resources.

Specify the strategic role with a falsifiable claim

A product can introduce customers to a larger offer, complete a workflow, or support a chosen market position. Write the mechanism and the evidence you would expect if that role were real. Track whether customers actually progress to the broader offer or whether the product is merely described as strategic whenever its economics are questioned. Do not require every product to be a standalone growth business, but do require the claimed portfolio benefit to be observable enough to evaluate.

Separate a repairable problem from a weak market

Poor onboarding, a confusing offer, and a missing feature are different from a lack of valued demand. Examine use, customer feedback, willingness to pay, and the reasons deals are lost. A repair should target a specific obstacle with a bounded cost and a decision date. Avoid an open-ended promise that one more release will reveal the market. Define what result would justify further investment and what result would support maintenance or exit.

Compare the portfolio under each alternative

Model how capacity moves after a product is stopped or simplified. Name the receiving initiative and verify that the released skills fit its needs. Removing a product does not automatically convert support specialists into developers or create demand for another offer. Account for transition work that temporarily uses the same people. A portfolio decision becomes concrete when it shows what the business will stop doing, what it will start or improve, and the sequence required to get there.

Plan the customer and team transition

Review contractual commitments, notice, data access, migration, refunds where applicable, and remaining support obligations. Obtain advice on the actual agreements when the consequences are material. Choose a communication owner and a schedule you can deliver. Do not sell new long-term commitments while privately assuming a near-term shutdown. A responsible transition can consume meaningful time and money; include it in the decision instead of presenting it as a cleanup task to handle after the announcement.

Record the decision and its reversal conditions

Write the evidence, assumptions, chosen option, owner, and dates for the next review. If you choose a repair, identify the stop condition before the team becomes attached to it. If you choose shutdown, specify which new evidence could legitimately change the plan and which would merely reopen a settled debate. Review the outcome afterward. Learning whether the expected capacity and portfolio benefits materialized is more valuable than declaring the decision brave or inevitable.

Try the decision

This fictional scenario makes the tradeoff concrete. Treat the details as a practice case and select the action that changes the relevant constraint.

Questions operators ask