Harvard Business Review has published an argument most product organizations still cannot execute: managers need to get better at killing digital products. The publication's headline verdict lands on a real weakness in product practice. Teams launch readily and retire rarely, and the portfolio fills with offerings that consume engineering, support and roadmap capacity without earning their keep.

What is the core claim?

The article's premise, stated in its title, is that termination is a skill managers have failed to develop. Digital products are cheap to keep alive relative to physical goods, which removes the natural forcing function that kills unprofitable catalog items in traditional businesses. A physical product with weak sales shows up in inventory costs and write-offs. A digital product with weak adoption hides inside an engineering budget line, and nothing forces a decision.

That structural difference is the mechanism behind the problem. Because sunsetting a digital product carries visible costs — annoyed users, internal political friction, a perceived admission of failure — while keeping it alive carries only diffuse costs, the default is survival. The diffuse costs compound. Every retained zombie product draws maintenance sprints, security patches, support tickets and design debt away from the initiatives that actually move the business.

The takeaway: underperforming digital products persist not because anyone defends them on the merits, but because the accounting of their true cost never reaches the person with authority to shut them down.

Where does the discipline usually break down?

The article's framing points to managers as the accountable role, not the team. A few failure modes follow from that framing:

• Sunk-cost reasoning. Once a product has absorbed quarters of investment, managers treat shutdown as wasting that spend rather than stopping future waste.
• Success metric inflation. Products kept alive often report on activity or uptime rather than outcome, so no metric ever triggers a kill decision.
• No exit criteria at launch. Teams define launch criteria carefully and retirement criteria almost never, so there is no pre-agreed threshold for shutdown.
• Reputational risk. Killing a product reads internally as failure, so managers protect their own track records by keeping weak offerings technically alive.

The takeaway: the kill decision fails before it is made — at the point where nobody defined what would count as failure.

What should product managers actually do?

The HBR argument implies a portfolio discipline rather than a hero decision. Practical translation for a Monday morning:

• Write sunset criteria into the launch document. If the product misses an adoption, revenue or retention threshold within a defined window, it goes to a shutdown review automatically.
• Charge each product its fully loaded cost — engineering maintenance, support load, security surface, opportunity cost of the team — so the ledger reflects reality.
• Treat shutdown as a managed customer process, not a silent decay: migration paths, notice periods and data export make retirement defensible.
• Separate the decision from the people. If ending a product reads as ending a team, managers will keep bad products to protect good people. Decouple the two explicitly.

None of this works without executive cover. A PM who proposes sunsetting a product while leadership rewards shipped features and punishes closed ones will learn the lesson once and stop proposing it. The framework works only when leadership treats a well-executed shutdown as a result, and fails whenever the incentive system counts closures as losses.

The takeaway: killing products well is an incentive problem as much as a judgment problem.

Why this matters now

Product organizations are exiting the growth-at-any-cost era, and capacity discipline is replacing expansion as the operating default. In that environment, the ability to retire a digital product cleanly — with criteria, migration paths and without career damage — becomes a core managerial competency rather than an occasional housekeeping task. Expect portfolio reviews to start asking not what to build next, but what to stop.