The Simple Version
Tech companies sometimes build products they fully intend to kill, not because they’re incompetent, but because the product’s death serves a purpose the product’s life never could.
What’s Actually Going On
The standard story about product failure in tech is one of hubris and miscalculation. Engineers overestimate demand. Executives fall in love with their own ideas. Markets move. Products die. It’s a tidy narrative that absolves everyone of deeper accountability.
But a meaningful number of tech product deaths aren’t accidents. They’re conclusions. The product did exactly what it was supposed to do, and then it was shut down because its purpose was complete. Understanding which kind of failure you’re looking at requires asking a different question: not “what went wrong” but “what did this product actually exist to do?”
The answers cluster into a few distinct patterns, each with its own internal logic.
The Land-Grab Product
The most common version of intentional obsolescence is the category blocker. A large company identifies a space where a smaller competitor is gaining traction, builds a competing product quickly, and deploys it at a scale no startup can match. The goal isn’t to win the category. The goal is to deny the competitor enough oxygen to grow.
Google did this with Google Reader. The RSS reader was a genuinely useful product, beloved by its users, but it also functioned as a structural defense against any independent aggregator becoming the default way people consumed web content. When RSS itself declined as a format, Reader lost its strategic value. Google killed it in 2013. The move made sense internally even as it looked baffling externally.
This pattern plays out constantly at a scale most users don’t track. A feature that a startup was building a business around gets absorbed into a platform’s free tier. The startup either pivots or folds. The feature, now stripped of competitive necessity, gets quietly deprecated.
The Signal Product
Some products exist not to generate revenue but to send a message to investors, partners, or regulators. The product is a proof of capability, a stake in the ground that says: we could own this space if we chose to.
The life cycle here is predictable. Announcement generates coverage. Coverage generates investor confidence. Investor confidence gets priced into the stock or into partnership negotiations. The product, having served its signal function, either limps along under-resourced or gets killed in a quiet blog post about “focusing on core priorities.”
This is distinct from vaporware, which is a product announced with no intention of shipping. Signal products ship. They just aren’t designed to scale, and everyone internally knows it. The engineering investment is real but bounded. The marketing investment often dwarfs the engineering investment. That ratio tells you what the product actually is.
The AI feature buildout at many large companies follows exactly this logic. The feature exists to keep the company in the AI conversation during a period when being perceived as behind carries real cost. Whether users adopt it is secondary.
The Data Product
A third category is starker and less discussed. Some products exist to collect user data that feeds a more valuable adjacent product. The product’s financial performance is irrelevant because the product isn’t the revenue source. The data is.
This is the logic behind many free consumer tools that major tech companies release without obvious monetization paths. The tool attracts users who generate behavioral data. That data trains models, improves ad targeting, or sharpens recommendation algorithms in the company’s core product. When the data utility diminishes, because the model is trained, because the behavior has been mapped, the tool becomes genuinely optional.
The users who built routines around it experience this as betrayal. From the company’s internal accounting, it looks like a successful project that has simply reached the end of its useful life.
The Optionality Product
Perhaps the most sophisticated version of this pattern involves products built to preserve future choice rather than capture present value. A company sees two or three plausible futures for a technology space. It builds lightly into each of them. Most of those bets will be wrong, and the products will be shut down. But the company that explores several futures with small investments is better positioned than the company that bets everything on one.
Amazon runs this playbook more deliberately than most. The company has killed a significant number of products and services over the years, including Fire Phone, Destinations, Spark, and Dash Buttons. Most of these look like failures when measured on their own terms. Measured as cheap options on possible futures, they look different.
The Fire Phone, specifically, was a visible and expensive disaster. But it produced hardware and software capabilities, particularly around 3D sensing, that fed into later work. The product failed. The investment wasn’t entirely wasted.
Why This Matters to Ordinary Users
None of this makes tech companies uniquely villainous. Capital allocation decisions always involve building things that might not pan out. The problem is the asymmetry of information. Companies know which of their products are genuine long-term bets and which are blockers, signals, or data plays. Users don’t.
When a user builds a workflow around a product, migrates data into it, and recommends it to colleagues, they’re making an implicit bet that the product has a durable future. Companies have every incentive to encourage that bet while it suits them and quietly discourage further investment once the product’s internal strategic purpose is complete.
The tell is usually in the resources. A product that matters to a company’s long-term plan gets engineering investment, not just maintenance. It gets a roadmap that gets talked about publicly. When a product stops getting talked about, when updates slow, when the team shrinks, the product has usually already been written off internally. Users are just the last to know.
The honest takeaway is this: before building a significant dependency on any product from a major tech company, it’s worth asking what job the product is doing for the company, not just for you. If you can’t answer that clearly, you’re probably a user of a product that serves a purpose you haven’t identified yet.
