Here are eight ways to succeed at failing…
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 .. 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.
“Experience is the name everyone gives their mistakes.”

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.)

How do you view / handle failure?
I would love to hear your experiences, as well as your thoughts on failure, and how it can hurt or benefit.