Seven Patterns of Technology Failure That Repeat Across Decades

Founders are rebuilding Google Reader, MongoDB-as-default, and Microsoft Bob this year, without knowing why those failed the first time. The names change. The patterns do not.

I spent the better part of a year writing obituaries for dead consumer and enterprise technologies at Tech Graveyard, and the most useful output was not the individual stories. It was the pattern catalog. Seven failure modes recur with very little variation across decades, across categories, across hardware and software, across consumer and B2B. If you can name them, you can spot them in your own roadmap before they kill you.

Each pattern below: a name, two or three named historical examples, and a how-to-spot-it-now field guide.

Pattern 1: Premature scaling without product-market fit

The product reaches a small group of devoted users. The team mistakes that signal for product-market fit, raises money, hires aggressively, and scales the cost base ahead of the revenue base. When growth flattens (because the addressable market is smaller than assumed), the cost structure cannot be unwound fast enough.

Named examples:

• Palm Pilots and PDAs: a real category with real users that scaled past its ceiling before the smartphone collapsed it.
• Windows Phone and BlackBerry: scaled investment into a platform whose addressable market was being eaten by a different category.

How to spot it now: your growth model assumes the next 10x is in the same shape as the last 10x. It rarely is. The marginal user at 10x scale is qualitatively different from the user that gave you the first signal.

Pattern 2: Building for the analyst, not the user

The product roadmap is shaped by what wins category recognition in a Magic Quadrant, what scores well on G2 feature checklists, or what the procurement RFP asks for. The result is feature breadth that nobody uses and an experience the user hates.

Named examples:

• Internet Explorer 6 through 11: optimized for enterprise procurement and standards-body politics, while Chrome optimized for the user.
• On-prem Active Directory as the user-facing identity layer: built for IT administration, not for the human logging in.

How to spot it now: when you describe your roadmap, you list categories you are entering, not problems you are solving. The category framing is for the analyst. The problem framing is for the user.

Pattern 3: Ignoring distribution physics

The product is genuinely better than the incumbent. The team underestimates how distribution actually works: existing partner channels, pre-installed defaults, retail shelf space, integrations with already-installed software, switching costs that have nothing to do with product quality.

Named examples:

• Standalone digital cameras: better optics, worse distribution. The camera that is always in your pocket beat the camera that takes better pictures.
• Google Reader and RSS: technically superior to social feeds for the use case. Distribution was concentrated in a single product that the company killed.
• Skype: dominant in 2010, beaten by products that distributed inside platforms where users already lived.

How to spot it now: your go-to-market plan assumes users will switch from a bundled-by-default solution to your point product on quality merits alone. They will not. The default is the distribution. Beating the default requires either an order-of-magnitude product gap or a distribution channel of comparable scale.

Pattern 4: Over-indexing on technical correctness

The product is technically more correct than the alternatives. It has better architecture, better protocols, better extensibility, cleaner abstractions. Users do not care. They pick the slightly-worse product that solves the problem with less friction.

Named examples:

• The fax machine outlived superior digital alternatives in healthcare and legal for two decades because it solved a workflow problem the technically-correct alternatives did not bother to solve.
• Adobe Flash: technically richer than early HTML5 for years. HTML5 won because it was "good enough" and zero-install.

How to spot it now: your pitch leads with architecture, protocols, or technical purity. The user does not care. The user cares about the problem in front of them today, solved in the next 15 minutes, with the tools they already have open.

Pattern 5: Monetisation incompatible with the use case

The product works. The pricing model does not match how value is created. Either the user gets no leverage from the pricing (forced ad model on a tool they would have paid for), or the vendor gets no leverage from the user's value (flat fee on a use case where one customer drives 80% of the cost).

Named examples:

• The DVD rental store: per-rental fees were incompatible with subscription streaming's economics. Netflix did not just have a better product. It had a fundamentally different monetisation that the incumbents could not match without cannibalising themselves.
• Cable TV set-top boxes: bundled-channel pricing in a world where users wanted to pay for the three shows they actually watched.

How to spot it now: your pricing model is the same as the legacy incumbent's, with a discount. That is not a monetisation strategy, it is a margin compression strategy. Either find a structurally different monetisation, or accept that you are competing on price in a category with structural floor prices.

Pattern 6: Network effects without escape value

The product locks users in via network effects (everyone is on it because everyone is on it). When something shifts, users defect rapidly because they had no individual reason to stay, only a collective one. Network effects look like a moat from inside the company. They look like a coordination problem from inside the user base.

Named examples:

• Skype again: every contact you had was on Skype. When the contacts moved to WhatsApp and FaceTime, the network effect ran in reverse with no friction.
• RSS: never had per-user lock-in. The substrate was open, so when the dominant client disappeared, the audience scattered.

How to spot it now: if you ask a user "why do you stay", and the answer is "because everyone else is here", you have a network-effect moat that is one product launch away from a network-effect cliff.

Pattern 7: Betting on a regulatory window that closes

The product's economics depend on a specific regulatory state, a specific tax treatment, a specific lack of regulation, or a specific platform policy. The regulation changes, the platform changes its mind, and the unit economics flip negative overnight.

Named examples:

• Third-party cookies: an entire ad-tech industry built on a tracking primitive that browsers and regulators removed without ceremony.
• Answering machines: a category killed by telecom regulation changes plus carrier-bundled voicemail.

How to spot it now: a competent regulatory or platform person inside your company can articulate the specific policy or rule your business depends on. If they cannot, you are taking the regulatory risk without pricing it.

The pattern behind the patterns

Every one of these is a failure of imagination about constraints. The team can see the constraint right now and optimizes for it. The team cannot see that the constraint is a function of a particular moment in time, and that a competitor will be unconstrained by it.

The mirror of this is the work I do in Future Tech: most predictions are wrong because they extrapolate present-day constraints forward. The technologies that survive are the ones whose architecture does not depend on constraints that are visibly weakening.

I have written about the prediction side at length, including the 18-month scoreboard on 47 predictions I made in late 2024. The scoreboard is unflattering in the same way: the predictions that aged worst were the ones that assumed the constraints of 2024 would still apply in 2026. They mostly did not.

The cross-piece, on a related theme, is The Future of Search Marketing, which is at heart an application of patterns 2, 3, and 6 to the SEO industry.

The questions to ask of your own roadmap

If you take seven questions from the seven patterns:

1. Is my growth model assuming the next 10x is the shape of the last 10x?
2. Am I building for the analyst, or for the user?
3. Am I assuming users will switch from a bundled-by-default solution on product-quality merits alone?
4. Is my pitch leading with technical correctness, or with the problem the user wants solved today?
5. Is my monetisation structurally different from the incumbent, or just discounted?
6. If you ask my users "why do you stay", do they say "because everyone else is here"?
7. Can my regulatory person name the specific rule my business depends on?

If you cannot answer any one of these, that is the failure pattern you have not yet noticed.

The systematic version

Each obituary above (and roughly forty more) lives at Tech Graveyard. The point is not nostalgia. The point is the pattern catalog. Read three obituaries from categories you do not care about, and you will see the pattern. Then read your own roadmap and see it again.

FAQ

Are these patterns specific to consumer technology?

No. The same seven patterns show up in B2B SaaS, developer tools, hardware, and enterprise software. The examples are concentrated in consumer because the consumer stories are better-documented, not because the patterns are different.

Can a company exhibit multiple patterns at once?

Almost every dead company exhibits at least two. BlackBerry hit patterns 1, 3, and 6. Skype hit 3 and 6. The pattern catalog is not mutually exclusive.

What is the most under-recognized of the seven?

Pattern 7, regulatory or platform dependence. It is the one founders almost never price. It is also the one that kills you fastest when it triggers.

How do you apply this to AI startups in 2026?

Patterns 1, 3, 5, and 7 are the obvious risk surface. Scaling on an addressable market that turns out to be small. Distribution dependence on a small number of foundation-model providers. Monetisation models that do not work when inference costs drop another order of magnitude. Regulatory windows on training data and copyright that have not closed yet but will.