My controller, Shivaun, is on a quest this month to find a new accounting system for us. We need to change systems because our current provider experienced a major product failure. They needed to replace some obsolete technology in their software to make them compatible with the latest Mac operating system — and they worked on that project for years. But ultimately, they were forced to admit that they simply could not get the new version out the door.

Sometimes people come to Rapid Learning Cycles because they have either experienced such a catastrophic failure or they see that they are at risk of one. Yet some innovation thought leaders think we should embrace failure to achieve speed. Why can Rapid Learning Cycles promise faster innovation — and fewer failures?

Most Products Fail

Some researchers estimate that more than 75% of product launches fail to achieve their revenue or sales targets. That is a staggering number. Yet most of the conventional wisdom about how to address this, including the advice given in the linked article, falls into two categories:

• Failure should be accepted — even embraced — as part of the cost of innovation.
• Failure is the result of people who have done a bad job — they’ve missed the market, didn’t listen to customers and generally didn’t do things they should have done to either release a better product or recognize that they don’t really have a product.

Both of these ideas are actually destructive to innovation programs, causing them to take longer to get to market on average, and also making them more likely to fail.

Most Products Fail — For the Wrong Reasons at the Wrong Time

Nothing good happens when a product makes it all the way to launch — and then delivers disappointing results. Amy Edmundson, who researches team dynamics at Harvard, calls this a “dumb failure”  — dumb because it is entirely preventable.

We know a lot about how to test ideas for new products and validate our assumptions long before we get to product launch to ensure that we’re meeting a genuine customer need. We know a lot about how to prevent the quality problems that can cause poor reviews and high warranty costs, and how to manage the flow of development and testing to get development work done. Products should not have failed launches for these reasons.

But companies sometimes respond by punishing the people who worked to get the product to market, even firing people. Sometimes a company does have a person who has gone rogue, with disastrous consequences. But punishing the people who are trying to be innovators is the fastest way to shut down innovation, and it doesn’t actually eliminate the cause of the failure.

Product development is risky, so even the most mature product development organization can still have an occasional disappointing product launch. But two is probably not a coincidence and three or more is a pattern that Edmundson calls a “complex failure” rooted in the system, not the people. There was nothing in the product development system that encouraged the team and its leaders to challenge their assumptions and forecasts.

The Root Causes of Late Products and Failed Launches Are the Same

Teams release products late because they have to spend time fixing problems that were introduced into the product in much earlier phases of development. Product launches fail because they have problems that were also introduced into the product early — in the concept phase — that were never fixed.

Sometimes, it’s a lack of vision. The company doesn’t know what the product is, or who it’s for, or what customer value it’s supposed to deliver so it wanders around looking for a purpose, as the development team struggles with constantly shifting priorities.

Sometimes, it’s tunnel vision. The technology does cool things that should be valuable to some customer out there. But the team or even the whole company is so much more comfortable refining the technology than they are with understanding customer needs, or they are so attached to their solution that they can’t hear the warning signs from customers who are not as enthusiastic about it.

Sometimes, it’s a failure to respond to a dynamic environment. Decisions have been made, plans approved, and revenue put into forecasts that are not reviewed and updated as the competitive landscape shifts.

Teams using Rapid Learning Cycles are much more likely to identify these types of fundamental flaws, because they will quickly run into Knowledge Gaps they cannot close, and Key Decisions they cannot make. If they identify a problem like this, and they can get a rational leader’s attention, then their program will be cancelled — but this type of failure is the opposite of a dumb failure.

Smart Failure Builds Knowledge

Edmundson contrasts dumb, preventable failures with “smart failures” — the failures that we have wherever we push the boundaries of the known. These failures build knowledge. Scientists know that such failures generate far more new information than successes. The disproven hypothesis leads to new insights that brings the researcher closer to the answer. These types of failures fuel innovation by building knowledge that teams and leaders need to challenge their assumptions and make better decisions.

Teams using Rapid Learning Cycles in the earliest stages of development actively seek smart failure — by defining the Core Hypothesis, identifying the Key Decisions that need to be made to fulfill the Core Hypothesis and the Knowledge Gaps they need to close to make those decisions with confidence.

If a Key Decision cannot be made, that’s a red flag. If an assumption that’s embedded in the Core Hypothesis is disproven, that’s a red flag with flashing lights and a blaring siren. “Will we go forward?” is always a Key Decision to make when it’s time for the next level of investment. “No” must be an option.

These smart failures are much earlier, much cheaper and much faster than a failed product launch. A good innovation system encourages and celebrates this type of failure — because it prevents both the risk of a catastrophic failure at product launch and the stagnation that comes from lack of innovation.

If Failure Is a Problem, Call It Something Else

It’s hard to celebrate smart failure if teams have experienced failed product launches, or if people have been punished in the past after embarrassing failures. Some cultures also encourage everyone to project an image of inevitable success, where “failure is not an option.” If the word failure itself triggers fear, doubt or bad behavior, leaders can always use a different word for the failures they want.

Personally, I like the word “experiment.” Over the Christmas holidays, I had a wild idea for a business — something I could do on the side, that would be fun to do, and create deeper connections with a community I wanted to know better. So I ran an experiment, using a Business Model Canvas, a prototype web site and a few emails. It was interesting, but more work than I wanted to invest.

Was that a smart failure? Absolutely, if the only definition of success is a released product. I failed to do that, fast, early and cheap. But that assumes my goal was a product or a new business.

A Quick No Is Not a Failure

The goal of an early-stage innovation team’s exploration is not a released product. The goal of such a team is an answer to the question, “will we proceed with this idea?” The goal of the innovation team overall is to identify potential new products and even new businesses that help the company achieve its strategic objectives and grow revenue. They don’t need every exploration to result in a “Yes” — they just need one. The better they are at eliminating ideas faster, earlier and cheaper, the more likely they are to find that one idea that should be accelerated into development.

Teams in Advanced Development should be running lots and lots of fast, cheap experiments like this, knowing that only a handful will succeed. The ones that do succeed in getting past this first stage may still fail later on, as new problems emerge. When teams define and validate the Core Hypothesis, pull learning forward and push decisions later, they also pull forward the knowledge that will identify problems earlier, so that these programs can be stopped long before they become catastrophic dumb failures.

Rapid Learning Cycles delivers faster innovation — with fewer failures — by eliminating the root causes of dumb failures and encouraging more of the exploration that leads to smart failures — or, as I like to call them, successful experiments.