How to Recognize Failure Patterns: How HP Quit and Apple Won

Recognizing failure patterns is the closest thing an innovator has to seeing the future.

If you can recognize the patterns, you can change the future, because most failures are not original. They repeat, and that repetition is the pattern: the same handful of patterns reappearing in one organization after another, decade after decade.

This one stings a little.

In 2011, Bill Geiser told me, almost word for word, how the project we had spent the past two years building was going to fail. He saw the pattern before I did; I heard him say it, and I never forgot it.

The failure still happened.

This is not a pre-mortem. A pre-mortem imagines new ways your plan could fail. Recognizing failure patterns means learning from failures that have already happened elsewhere and spotting the early signals before you repeat them, while there is still time to act.

By the end of this episode, you will have four patterns in your own library, a five-minute way to check any project against them, and the four steps to take when you find one.

Let's get into it.

... or listen to the podcast:

The Smartwatch We Killed

In 2004, Fossil hired a watch-technology executive named Bill Geiser to help build innovative technology for their watches. A few years later, he and I started spending real time together, me as HP's CTO, him running watch technology at Fossil. Between us, we had an idea we both believed in: a connected wearable, years before anyone used that phrase, co-innovated by HP and Fossil, with each bringing its expertise.

Fossil named the resulting platform the MetaWatch. It ran an ultra-low-power processor with a 96 by 96 display, an accelerometer, and Bluetooth. It was designed to last a week on a charge, and it shipped with a full developer kit so anyone could build apps for it. We revealed the partnership in March 2011, at an HP event in China. And between us, we had the one thing Apple did not have in 2011: distribution. HP held roughly ten percent of consumer-electronics shelf space. Fossil sold through twenty thousand retail stores that carried its watches.

Bill saw the ending before anyone. He told me in 2011: "Phil, I wouldn't be shocked if Apple evolved the Nano to take advantage of this space. They'll legitimize it in consumers' minds worldwide."

So the man building the watch spotted the failure in advance, out loud. And naming it changed nothing.

The signs kept arriving in plain sight. HP went through three CEOs in thirteen months. In August 2011, Leo Apotheker killed HP's consumer mobile strategy and WebOS, which removed the platform that made a smartwatch matter to HP at all. The battery lasted three to four hours against the original target of a week. We ran month-long approval cycles for changes that startups could implement in days.

Then I went out on medical leave. When I came back six weeks later, HP had killed Palm, WebOS, and the connected wearable project.

Here is what the ignored warning turned into. The Apple Watch shipped in April 2015. It sold 4.2 million units in its first quarter, and by that fall Apple was selling three out of every four smartwatches on the planet. The market we walked away from grew from three hundred thousand units in 2012 to forty-five million by 2018, and Apple held fifty-one percent of the market share.

The idea was never the hard part. It never is. The hard part is committing.

What Recognizing Failure Patterns Means

Nothing that killed the MetaWatch was new, and none of the signals were faint. They were loud; they were ignored, and each one was a pattern that has killed projects for decades.

Recognizing failure patterns has two halves. The first is building a library of how failures repeat. The second is matching the situation in front of you against that library, and forcing what you find into an actual decision while the fix is still cheap. Bill did the first half. Neither of our companies did the second, and the gap between those halves is where the Apple Watch came from.

Here are four entries for your library, straight from this one failure. Each one ends with a test question. By the end, you will have a four-question checklist, and then I will show you what to do when a pattern shows up.

Pattern 1: Success Protects Itself

Fossil's traditional watch business grew from $950 million in 2004 to $3.25 billion by 2013. It was tripling while we were building the thing that might replace it, and that growth made cannibalizing it politically impossible. Fossil never had to kill the MetaWatch outright. Fossil positioned the watch as a two-hundred-dollar development platform, something no ordinary customer would ever be handed at a retail counter.

When we constrain what we're innovating so it doesn't risk the present, we've lost the future.

Test it: Is the new thing priced, staffed, or positioned so that it cannot hurt the current thing? If the answer is yes, this pattern is already running.

Pattern 2: The Warning That Changes Nothing

Bill's warning was specific, early, and exactly right, and it still changed nothing. I heard it directly, and hearing is not the same as deciding: nobody re-ran the plan with "Apple arrives and legitimizes the category" as an input, no roadmap changed, and no budget moved.

Test it: What decision changed after the warning? If the honest answer is none, the warning was never acted on, no matter how many people remember hearing it.

Pattern 3: The Problem Nobody Owns

A week of battery life was the MetaWatch's central promise, and it shipped at three to four hours. Both companies saw the gap. No one owned fixing it. The hardest problem on the project sat on the seam between two companies, and problems that sit on seams get reported, tracked, and carried forward without ever belonging to anyone who can be asked why the problem is still there. We ran that partnership for two years and never settled whose job it was to lose sleep over the one number that mattered most.

Test it: Who owns the hardest problem, by name? If the answer is a partnership, a committee, or a pause, then nobody owns it.

Pattern 4: The Pace Mismatch

Earlier, I shared that we ran month-long approval cycles for changes a startup could implement in days. That is a pacing problem: the organization's internal pace versus the market's. A smartwatch in 2011 was a fast-moving product running through slow-moving machinery, and no amount of talent inside the project could close that gap. The delay was structural, not personal.

Test it: How long does one small change take to approve, against how fast the market moves? Time a real one. Do not estimate it.

Five Minutes on a Project That Died

The four patterns are the start of your library. Before you use it on a live decision, test it on a dead one.

You have a dead project in your past. Everybody does. Pick the one that still stings and give it five minutes against the four test questions.

1. Was an existing success being protected while the project starved, in pricing, staffing, or positioning?
2. Did people raise a warning, and what decision changed after it was said?
3. Who owned the hardest problem, and can you name the person?
4. And how long did a small change take to approve, against how fast the market was moving?

When I run the MetaWatch through those four questions, I find all four patterns. Your project will probably show fewer. Every pattern you find is one you will now recognize as it happens on the project you are working on right now.

The Four Steps When You Spot a Failure Pattern

Which brings up the harder half of the skill, because recognition alone did not save us. Suppose you had been standing next to me in 2011, holding all four of these patterns. It would not have been enough. Being right about the future means nothing without the organizational machinery to act on that insight.

So when a failure pattern appears on a live project, follow this sequence.

Step one: Say the failure pattern out loud, in the room where the decision lives. Not in the hallway afterward. Use the pattern's name.

Step two: Get it onto the decision memo. A warning that lives only in conversation changes nothing. Write the pattern and what it costs into a document that will drive a decision.

Step three: Attach an owner. If you identify a critical problem, assign it to one person. Not a team or an organization. Someone you can ask next sprint why the problem is still there.

Step four: Attach a date. Being early provides an advantage, and a failure pattern without a date on it fades unnoticed.

Bill was right for four years, and Apple was the one who acted on it. That could have been us if we'd had the organizational courage to back our vision with meaningful resources.

Conclusion

You now have what nobody handed me in 2011: four patterns of failure, a five-minute check, and the four steps to run when you spot one. What you do in the room where the decision lives is the part Bill's warning never got. Don't waste it.

Additional Resources

How HP and Fossil Handed Apple the Smartwatch Market: The inside story of vision without execution: why being right about the future means nothing without the courage to act on breakthrough insights. https://www.philmckinney.com/how-hp-and-fossil-handed-apple-the-smartwatch-market/

The story of MetaWatch with its founder, Bill Geiser: https://www.philmckinney.com/the-difference-between-a-good-idea-and-a-great-idea-is-the-timing-s11-ep25/