Why Design Sprints Are The Right Kind Of Wrong Sometimes?
What are intelligent failures and why are they "good failures"?
I wrote here more about what Design Sprints are and what they are good for.
The first design sprint I ran was a blind one. I did not know where it went. The initial scope was different than what the outcome was. The team looked at it as a success.
It was a success as the prototype was created there was then created in a real implementation environment at a 95% rate which is an excellent rate.
As a facilitator I took it back then as a “smart failure” and I knew we learned a lot from it and what we learned, but I did not know back then why it was “the right kind of wrong”.
The initial hypothesis we had before the sprint, in the preparation week, was that the scope was to decide which tool would be chosen for running a specific risk management process.
The outcome of the sprint was that we got feedback from real users on one part of the process and knew exactly how to implement it. This saved us months of work and trials. The decision on the tool was also taken, as a consequence. Why as a consequence? Somehow the dimension of the discussion was raised to another level once we thought about the two-year goal and what is important for the team to achieve.
And in this case, this design sprint, considering the initial scope, was the “right kind of wrong”.
What is the “right kind of wrong” and why is it an intelligent failure?
Amy Edmondson defines in her book “Right Kind Of Wrong”, failure as an outcome that derives from desired results.
And she splits failures into three types.
One of them is intelligent failures. These are thoughtful hypotheses not supported by data. They are also praiseworthy because they are necessary building blocks of discovery.
Here are some additional attributes of an intelligent failure, as described in Amy's book:
it takes place in a new territory (the level of uncertainty is very high)
the context presents a credible opportunity to advance toward a desired goal
it is informed by available knowledge (hypothesis-driven)
the failure is as small as it can be to still provide valuable insights
Example: experimenting with a new recipe that looks delicious qualifies as an intelligent failure when it turns out to taste awful :)
Why are some design sprints intelligent failures?
Because they have some or all the attributes above.
And I say “sometimes” even though in my opinion they all are.
A Design Sprints is a discovery phase where there is all the time a hypothesis, you have a high level of uncertainty (otherwise it would not make sense to make a design sprint), there is a goal to achieve and a high opportunity there, failures are small as they are happening in a controlled environment, with low stakes.
What is the “perfect” intelligent failure design sprint? The one where the decision is NOT to build that product for example. Imagine how much time, effort, money, and energy are saved after 4 days of work compared with losing months or even years of work developing a product that is not useful for the end client.
Bottom lines:
Reframing failure is a life-enhancing skill that helps us overcome our spontaneous aversion to failure. Having a context where intelligent failures are allowed and people have the psychological safety to learn from them is the key to creating great products. Design Sprints offers the right framework for this.
Resources:
Book “Right Kind Of Wrong” by Amy Edmondson
Design Sprints Bring Product Teams In 105% Performance Phase - The Optimum Stress