Design Sprints Can Be Dangerous
As I’ve mentioned previously, Design Sprints have recently come into their own within the world of product management, and are increasingly being used by companies of all shapes and sizes as a way to jump start innovation and introduce more agile ways of working. As a result, you don’t have to look far these days to find a story extolling the benefits of Sprints, and citing the success of the organizations that use them. It’s no secret that my team and I are big fans of the Design Sprint, and believe wholeheartedly in the outstanding value it provides, but as with any tool, it can do more harm than good when not used properly.
One of the primary benefits of a Design Sprint is its ability to break a team out of their normal process and give them a means of accelerating their work on a particular project over the course of just a few days. This can help teams push forward an existing project that’s stalled, or kick off a new one altogether, all of which is a huge positive… as long as the direction the team is headed is the right one.
Unlike Design Thinking, which is focused entirely on ensuring that the team is solving the right problem and for the right user, a Design Sprint makes the assumption that you already know that information, and therein lies the rub.
If your team doesn’t know who your end user really is, or what problem you’re trying to solve for them, then while a Design Sprint will certainly give you a big boost towards creating a solution, there’s a very real chance that it won’t be the right solution. You’ll have invested a fairly substantial amount of effort over the course of the Sprint only to find that your final output falls flat, because your users don’t actually need it. Or even worse, your testers will respond positively to your prototype — leading you to believe it’s something you should pursue further — only to find out much later that the people you were testing with weren’t representative of your actual users. Imagine the time, effort and money that might be wasted on a project like that.
We see this situation all the time, and have come to refer to it as a “solution without a problem” — teams creating something based on their own internal assumptions about who the user is and/or what their pain points are, without any real data to back up that point of view. That’s a dangerous situation to begin with, but the potential pitfalls are only multiplied when those assumptions are then fed into an accelerator like a Design Sprint.
Of course, this isn’t to say you shouldn’t consider using a Design Sprint — because you absolutely should! — just that you need to be careful to ensure your inputs are based on real data. It’s for this reason that we’ve found a Sprint to be the perfect complement to Design Thinking. In the course of a short Design Thinking project, you can identify your users, narrow in on what specific problems they have within a given area, and generate some high-level ideas for how you might solve those. Being able to then feed that into a Design Sprint as a means of accelerating the development of your solution is a natural next step and can be a very powerful thing. So go forth and Sprint! Just do it smartly.
