5 reasons why many Design Sprints fail
and what you can do about it
A Design Sprint is costly if it fails. But if you have done your homework, it can be an extremely good investment.
Let's be honest. Design Sprints are an expensive affair. A handful of valuable resources across departments clear the calendar and come together for one week to solve one problem. Nevertheless, it can be an extremely good investment if you prepare correctly. And this is exactly where there are far too many mistakes. Although Design Sprints are in the true sense of the word a sprint, the work that happens in advance is critical for a successful process.
For the past 15 years, I have worked with product and service development in larger companies and organisations. I also organize seminars about design sprints through Design Sprints Global Chapter Oslo and thus talk to many who have participated, been initiators or facilitated Design Sprints. About 30 to 40 percent of them have “failed”. The reasons are almost always the same.
1. Wrong problem
Image by pch.vector on Freepik
Let's do the first thing first: the problem to be solved. A mistake many people make is to try to solve a problem that is not suitable for Design Sprints. The result is rarely good. What is important to remember is that the problem should be complex, not just complicated, in order to use the Design Sprint format.
A complicated problem usually has a clear cause and effect. To find the solution, you usually only need time and a maximum of 1-2 professional skills. For example: we see that we lose 30 percent of customers in the checkout process, can we increase this by improving the user experience on mobile? Through analysis, you find areas for improvement and can use best practice to plug the holes.
A complex problem, on the other hand, looks at several solutions where you depend on many skills to find the best one - and you don't know what the best choice looks like in advance. This could be, for example: How can we increase market share through a new product or service? Here, the range of possibilities is much larger and the proposed solutions more numerous. It is often difficult to agree on one direction, because there are many trade-offs to balance, and then you need more skills and focus to land a solution.
2. We are in a hurry: cut corners
Image by pikisuperstar on Freepik
In order to find the "correct" problem, and what is actually to be solved, good and thorough insight work is required. One must look at the needs and the values it can create for the company and its customers.
In order to get the most out of the participants time and ensure that it becomes an investment rather than a cost, at least as much time should be spent in preparation as in the design sprint itself. A Design Sprint should not replace the insight work, it should be an extension of it.
3. Poor planning and poor scope
Image by pch.vector on Freepik
The eagerness to get started without planning, and thus not prioritising issues ahead of time. The reason is often because you suddenly are in a hurry when you have decided to run a Design Sprint. A company I know suddenly brought completely different issues into a Design Sprint. The result was enormous amounts of insight that had to be reviewed on the first day.
This made it very difficult to find a clear topic that the team could agree on. Instead of working focused on one problem, they set a sprint goal that was too broad and general. This resulted in further errors in the sprint; the scope of the prototype was too large and it did not test the problem they set.
The company learned something along the way, but could have benefited much more from the sprint if they had defined the problem area in advance, e.g. through a "problem mapping and scoping" workshop.
4. Bad or lack of research
Another frequent occurrence is not having deep and fresh enough insight directly from the customer or end user. In larger organisations, you are often not directly exposed to those who use the product or service, but you have many ideas for what you think the problem is.
An example: A product owner believed that he and the organisation knew the needs so well that they did not need to do any additional insight work up front. They knew very well what the problems were. It was only when the team got to the customer interviews and the user test on the last day of the sprint that they realised the concept wasn't working. And that was because the solution concepts were poorly founded.
The proposed solution answered the wrong problem. They could have avoided this by doing something as simple as customer interviews with the target group in advance. These interviews provide a good background and basis for discussion in addition to all the quantitative and experience-based data the organisation already has.
5. Not after though on what to do next
It is no understatement to say that the biggest risk moment in a Design Sprint is preparation. If this is not done well enough, you often end up with the same solution that you started with or no solution at all. But the follow-up work is also a significant element of risk for whether a design sprint actually leads to real results. Often time is only set aside for the Sprint week itself, and nothing for what will happen afterwards. This is where the process and solution will live on.
The Design Sprint dies and loses value without a plan for how to work with the solutions you arrive at. A week outside the normal working day means that things pile up, and you have to recover. It is therefore important that someone takes ownership of the progress even after the sprint is finished, and that this is agreed in advance.
As mentioned, a Design Sprint is costly if it fails. But if you make sure you have a suitable problem and do the preparatory work correctly, the probability is high that it will be an extremely good investment and something that both the company and the customers will greatly benefit from.