Design sprints are fantastic ways to create a solution and test it quickly, however, sometimes it can be a red herring.
Innovation is hard, if everyone was doing it, then it’s no longer innovation – it’s business as usual
I’ve previously written about how we need to look at developing products and services differently, and how anyone can innovate in a company, but why are we obsessed with design sprints? Maybe I’m in a bubble, but almost every conversation I have around developing new products, services or even features will include something about a design sprint.
What’s a design sprint?
For the uninitiated, a design sprint is a multiple-day workshop where a team go from idea to prototype validation. It’s supposed to concentrate weeks or even months of development and testing into a week or less.
Probably the best-known sprint methodology is the Google Sprint, developed by Google Ventures – you might have seen someone reading the book Sprint by Jake Knapp et al – and I heartily recommend you take a look if you are considering doing your own sprint. Here’s what it looks like:
So you can see how you can get from a problem to an idea to a prototype in 5 (or less) days.
So when doesn’t it work?
Design sprints are fantastic if you know what problem you are trying to solve. However, if you focus on a particular problem and it turns out to be the wrong one (ahem), you’ll end up developing a product or service that does not fit the needs of your users or customers, and at best you would have wasted 3 or 4 days. At worst, you set yourself up to fail with your shiny new idea.
So if you are considering a design sprint, make sure you have done your pre-work with a problem reframing or pain points mapping exercise to ensure the success of your sprint.