Planned obsolescence has a reputation problem. Critics frame it as pure cynicism: companies deliberately cripple products to force upgrades, sacrificing user trust for quarterly revenue. That story is satisfying and partially true. But it misses the deeper reason why entire product lines are built with expiration dates baked into their architecture from day one.
The hidden driver is not greed. It is organizational survival. Building a product you know will become obsolete is, counterintuitively, the most rational thing a technology company can do.
Platform Lock-In Requires a Moving Target
A static product cannot sustain a platform. The economics of platform businesses depend on continuous switching costs, and switching costs require continuous change. If your product reached a stable, finished state, users could rationally evaluate whether to leave. Perpetual incompleteness forecloses that evaluation.
Consider how Microsoft handled Office. For decades, the product introduced file format changes with each major release, creating compatibility friction that punished anyone who did not upgrade. The features themselves were often marginal. The format changes were not. They reset the switching cost clock and kept enterprise buyers tethered. This is not a company failing to finish a product. It is a company treating incompleteness as infrastructure.
The same logic applies to hardware. Apple’s annual iPhone releases do not exist because the engineering team has a breakthrough every twelve months. They exist because the upgrade cycle trains consumers to treat their current device as inherently provisional. That training has a corollary: older devices that feel slower make the next device feel necessary, regardless of what the specifications actually say.
Obsolescence Funds the Next Generation of R&D
The revenue from planned replacement cycles is not simply profit extraction. In capital-intensive technology sectors, it is the primary mechanism for financing research that cannot be justified on its own terms. Semiconductor fabrication plants cost tens of billions of dollars. Consumer electronics margins at scale fund those plants. Those plants produce the chips that enable products three generations out.
Intel’s tick-tock development model made this explicit. Each “tick” shrunk the manufacturing process; each “tock” introduced a new microarchitecture. The cycle was engineered, not emergent. Consumers buying today’s processor were, without knowing it, subsidizing the research that would make today’s processor feel slow in four years. The obsolescence was load-bearing.
This is genuinely different from simple rent-seeking. The revenue from obsolete products is often the only funding mechanism for research with no obvious near-term payoff. Without the iPhone upgrade cycle, Apple’s silicon team, which has since produced chips that materially advanced the state of the art in personal computing, would have been a much harder internal budget fight.
Organizational Incentives Make Completion Dangerous
Inside technology companies, finishing a product is a career risk. A team whose product is “done” is a team whose headcount is at risk. Product managers who declare victory have no roadmap. Engineers who ship a stable, low-maintenance codebase lose their justification for the next hire.
This is not a conspiracy. It is the predictable output of how technology organizations measure value. Velocity is visible. Maintenance is not. Features ship; stability is assumed. The result is a structural bias toward perpetual incompleteness that mirrors, and reinforces, the commercial logic of planned obsolescence.
The products that escape this dynamic are typically the ones built under unusual constraints, often for a single demanding internal client before being externalized. When a tool is built to solve a specific, concrete problem rather than to sustain a product team, the incentive to keep adding unnecessary complexity disappears.
Obsolescence as Competitive Moat
Here is the argument that rarely gets made explicitly: planned obsolescence protects smaller competitors as much as it threatens consumers. A technology product that reached genuine completion would be immediately commoditized. Any competitor could replicate a finished, stable product. The moving target of continuous change is expensive to follow, and that expense is a moat.
This is why dominant platforms accelerate their release cycles when they sense competitive pressure. Faster obsolescence means faster investment requirements for anyone trying to keep up. The pricing strategy mirrors this logic: subsidize entry, then ensure that staying current requires ongoing investment that only incumbents can afford to sustain.
The Counterargument
The obvious pushback is that some technology does reach completion. TCP/IP has not had a major revision in decades. SQLite has been described by its author as nearly finished. Git has not changed its core data model since 2005. These tools are stable, widely used, and not subject to planned obsolescence.
This is true, and it reveals the limits of my argument. The dynamic I am describing applies specifically to consumer-facing, platform-dependent, commercially competitive products. Infrastructure software that solves a bounded problem and faces no commercial pressure to generate upgrade revenue behaves very differently. The difference is not engineering culture. It is incentive structure. When there is no revenue model attached to the upgrade cycle, the upgrade cycle disappears.
That distinction does not undercut the argument. It sharpens it. Planned obsolescence is not a natural law of technology development. It is the specific output of commercial incentive structures applied to platform products. Which means it is a choice, even when it does not feel like one.
The Conclusion That Follows
Tech companies build products they know will become obsolete because their organizational survival, their R&D funding mechanisms, their competitive moats, and their internal incentive structures all depend on it. Greed is too simple an explanation. The real explanation is that the entire system, not just the companies but the investment models and the org charts and the product review processes, is optimized for perpetual incompleteness.
Understanding that does not make planned obsolescence less frustrating. But it does clarify where the pressure for change needs to be applied. Blaming product managers is useless. The incentive structure is the product.
