Failure Is Not an Option—It’s a Requirement

It had been a difficult few months for the team. Not the usual we-busted-our-butts-and-finally-shipped difficult—that had happened months before.

No, this was a different type of difficult. Let’s just call it a we-launched-and-our-company’s-revenue-dropped-thirty-percent difficult.

The team took a gamble with a radically new design, something that was supposed to dramatically improve the shopper’s experience. It didn’t. It made it worse. Now, they were paying the price.

Is Failure Always Bad?

It’s easy to conclude that teams should avoid failure at all cost. After all, nobody wants to the be the ones who sit alone in the cafeteria, hearing the whispers of “those are the Ones who messed up.”

However, if you look at all the great innovation that’s occurred over the centuries, one pattern quickly emerges: failure played an integral role. We need to fail to learn.

When we succeed, we usually know we’ve succeeded, but we can’t pinpoint why. Which step or element was the key to our success? It’s very hard to learn from success. Especially the how-do-we-do-that-again lessons that are essential to long-term growth.

Failure helps us hone our skills much better than success. When we fail—and take the time to learn from our failures—we discover what we need to improve. As the saying goes, the largest room in the world is the room for improvement.

We want to fail. We just want to do it in a way where we’ve minimized the risk.

The Slow-And-Steady Approach

Amazon.com recently made a huge change to their system, one that could have had catastrophic consequences, had they not controlled the risk. Amazon sells almost $12 billion each year. A design change that doesn’t go right, even for a day, could be worth millions of dollars to them.

When the designers at Amazon decided last summer to launch their new navigation system (finally ditching the tabs they’ve had since they first launched), they were naturally cautious. All eyes were on the numbers and nobody wanted to see an “improvement” sink the company.

What resulted was one of the most conservative design launches we’d ever seen. It started by identifying the “least risky” customers. They picked folks who weren’t known to the system, because they didn’t have a cookie for the site. (Users with cookies get Amazon’s trademark personalized welcome message.)

When the team was ready to launch, they let only a small portion of the non-cookied visitors see the new navigation. Once they felt comfortable that these people were succeeding with the design, they slowly opened the valve, giving more visitors that were non-cookied access to the new navigation.

After weeks of only non-cookied visitors, Amazon started to slowly give access to the more loyal (and cookied) customers. Even here, they didn’t rush, taking several weeks to make the entire transition.

Mitigating Risk

While it took time, the Amazon design team minimized their exposure by slowly rolling out the new navigation. If a failure were to result, they could contain it early. Only when they were comfortable, did they open it up to more users.

A slow rollout is one way to mitigate risk. There are other ways too.

For example, paper prototyping is a great technique. By building the interactive model out of paper and trying it out with potential users, you collect solid feedback about the design early in the process. Here, the risk is building something you’re going to throw out or spending time on feature implementation that ends up not being important.

A fast iteration process is another risk mitigation technique. When done well, each iteration produces information about the users and their needs, which the team then feeds into the next version of the design. The faster the team goes, the sooner the design evolves into something the users will love.

Common Failure Mistakes

“Good judgment comes from experience and experience comes from bad judgments.”

“Experience is the name everyone gives their mistakes.”

As we’ve researched the design practices of teams, we’ve collected some mistakes—things teams do (or don’t do) that make it hard to fail productively.

Mistake #1: Operating without a clear vision. If the team doesn’t know what direction they are heading, it’s hard to know when they’ve made a misstep. With a clear, unified vision, everyone on the team can instantly detect a failure and make the necessary corrections to the course.

Mistake #2: No introspection after each failure. There’s a natural desire to quickly move on after something bad occurs. However, it’s important for the team to resist that urge and stop to ask, “What just happened?” and “What can we learn from this?”

Mistake #3: No communication of learned lessons. On larger teams, small mistakes (and some bigger ones) may escape attention by those team members who aren’t directly involved. It’s critical the lessons from the failure are communicated across the entire team, so everyone has a chance to learn.

Mistake #4: No time allocated for iteration or experimentation. The mantra, ‘Ready, Fire, Aim’ only works when repeated. Teams exhibiting excessive optimism without planning for failures find themselves backed into a corner when something does go wrong. As in the Amazon approach, leaving time to iterate and experiment will give the best results.

Mistake #5: Inflexible platform. We frequently hear comments such as “We’d love to try that, but we can’t make our content management system do it.” Teams that lock themselves into a platform that doesn’t give flexibility will have trouble reacting when a failure occurs. Teams that build on a flexible platform (and have the skills to take full advantage of that flexibility) are in the best position to recover from a failure.

Mistake #6: Building too much before a feedback cycle. Too much code locks teams into a direction that’s hard to change. The best teams get feedback early in the cycle using a variety of quick prototyping tools. They don’t start coding until they’ve collected substantial user feedback to know they are heading in a solid direction.

Mistake #7: Not instrumenting the design. Many teams don’t think about how they’ll tell if the design is working. They launch without measures in place. The best teams conceive and build in their instrumentation from the start of the project. We’ve seen some that start with the measures as part of their vision.

Mistake #8: Not enough depth in feedback. “Was this helpful? Y/N” is an interesting question, but what does it tell the team? If a large percentage say no, what should the team do differently? The best teams ensure they are going deep when collecting feedback from users. (For example, Netflix combines both live site A/B tests with in-lab usability testing, so they can see design issues from both a quantitative and qualitative viewpoint.)

A Culture for Failure

In our research, the most critical component for a productive approach to failure is the organization’s culture. A culture that accepts failure as a part of growth and celebrates every learned experience will always outplay a risk-averse culture. The organization’s management and reward structure needs to accommodate failure, regularly celebrating those who take risk and promote their insights.

One thing is clear from our research: Failing is hard work. All teams need to get better at it through regular practice.