The products most likely to get axed at a large software company are not the failing ones. They’re the profitable ones that don’t fit anymore.
This sounds irrational until you understand how large technology companies actually allocate capital. A product generating $40 million a year in net revenue sounds like a keeper. But if that product requires 30 engineers, demands a dedicated infrastructure team, and sits on a codebase that doesn’t share DNA with anything else in the portfolio, that $40 million starts to look expensive. The decision to kill it is not a failure of business judgment. It’s often a precise expression of it.
The opportunity cost that never shows up on the income statement
Profitable products get killed because accounting doesn’t capture what they cost. The formal financials show revenue, cost of goods sold, and contribution margin. They don’t show the alternative uses of the engineers maintaining that product, the infrastructure headcount locked to its operations, or the organizational attention its roadmap consumes every quarter.
Google Reader had a loyal user base and no obvious revenue problem when Google shut it down in 2013. What it had was a maintenance burden, a team, and an opportunity cost in an era when Google was trying to consolidate its social efforts. The product was profitable in the narrow accounting sense. It was expensive in every other sense.
Microsoft’s frequent culling of products that carry real users follows the same logic. Groove Music, Microsoft Band, and others weren’t shut down because they lost money. They were shut down because the resources underneath them were worth more somewhere else.
Peak users create peak maintenance burden
There is a specific timing pattern here worth naming. Products tend to get killed near their usage peaks because peak usage is when the operational burden is highest. The servers are most loaded. The support tickets are most numerous. The edge cases are most prevalent. A product with 2 million active users is dramatically more expensive to maintain than the same product with 200,000 users, even if revenue per user has stayed flat.
This is the trap product teams fall into. They interpret “we’re growing” as safety. Growth, without a corresponding growth in strategic importance to the parent, actually increases the probability of shutdown by making the product harder to maintain and more expensive to eventually migrate away from. The longer you wait, the worse the eventual data migration problem becomes.
Adobe killed several products in its Creative Suite rationalization not because those tools lacked users, but because each one was a full maintenance obligation that complicated every platform update, every licensing change, and every infrastructure upgrade.
Internal competition is ruthless and mostly invisible
Large software companies run internal capital markets that most outsiders never see. Product teams compete for engineering headcount, infrastructure budget, and executive attention. A profitable-but-static product is perpetually vulnerable to a growing product that needs those same resources and can show a higher projected return.
The profitable product’s defenders face an impossible argument. They can point to current revenue but cannot easily argue that their product deserves resources over something newer with a higher ceiling. The internal competition isn’t fair and isn’t supposed to be. It’s designed to direct resources toward future growth, not present profitability.
This dynamic explains why acquiring companies often kill the products of their acquisitions even when those products work well. The acquisition was usually about technology, talent, or market position, not about running the acquired product indefinitely. The product’s profitability is a secondary consideration that loses to resource reallocation almost every time.
The counterargument
The reasonable pushback here is that companies kill products all the time for bad reasons: short-term thinking, executive ego, poor acquisition integration. This is true. Many product shutdowns are genuine mistakes that destroy customer trust and abandon revenue that would have compounded. Killing something that users depend on creates the kind of brand damage that is hard to measure but very real.
There’s also a survivorship problem in this argument. We see the products that were killed. We don’t see the ones that weren’t killed and quietly drained resources for years. The companies that are disciplined about shutting down profitable-but-costly products may simply be harder to criticize because their balance sheets look cleaner.
But none of this changes the core calculus. The decision to kill a profitable product is sometimes wrong. It is never automatically wrong. Treating profitability as a shield against shutdown is a misreading of how resource allocation actually works inside large technology companies.
What this means in practice
If you’re running a product inside a larger company, profitability is necessary but not sufficient for survival. The real question is whether your product’s strategic value to the parent organization is growing alongside its revenue. A product that generates reliable cash while becoming less central to the company’s future direction is a candidate for shutdown regardless of its income statement.
The companies that do this well are explicit about it. They set sunset criteria in advance, communicate to users with reasonable lead time, and treat the shutdown as a planned operation rather than an emergency. The ones that do it badly let products linger until they become so expensive to maintain that the shutdown becomes chaotic.
Profitability buys time. It doesn’t buy permanence. Knowing the difference is how you plan for both.
