I’ve been teaching teams how to run design sprints for years, and one of the most common questions I get asked is: “When should we use a design sprint?”
I’ll tackle this in the upcoming sections by answering the opposite: when isn’t a design sprint going to help you? Despite the positive reviews and buzz, it’s not a magic bullet and cannot be used for everything.
Your product is already very well-defined
Some efforts don’t require that much design thinking. There might already be a validated product design concept that’s agreed to and all the team needs to do is execute it. A design sprint to implement functionality without exploring improvements, reductions, or changes isn’t a design sprint.
Significant research is needed
My experience has taught me that a design sprint needs to have inputs, and most often that input is a form of design research data. Yes, I’m talking about interviews with customers – you know, those people who use your product? You may want to consider a day or two of user research, ethnography, or interviews before starting a design sprint.
The scope is too broad
You don’t need to know everything before beginning a design sprint, but you’ll want to know the general problem area before you get started. “Don’t boil the ocean” is a phrase you may have heard in the halls of management consultancies and the same applies here. While we’ve seen design sprints work as a mechanism to help narrow your scope and focus, it may be a challenge if your task is to do something like ‘reinvent space travel’, for example. You’re unlikely to accomplish a task that big in one week!
“Add this button”
Conversely, if the scope is far too narrow, you may want to just go ahead and implement the idea. Some things you shouldn’t overthink, just get it into your product and test it live.
You mistake a design sprint for product development
A design sprint is not a method for getting a more sophisticated product development effort done for less money and time. However, we have seen that this belief can occur no matter how much expectation-setting you do at the beginning of the project.
A design sprint cannot accomplish everything, so scope appropriately. It is not a substitute for complex product development, nor is it appropriate if there’s an unwillingness in your organization for a change in direction.
Want to learn more? Here are two great books for you to explore:
- Design Sprint: A Practical Guidebook for Building Great Digital Products by Richard Banfield, Trace Wax, and myself!
- Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, John Zeratsky, and Braden Kowitz
More From C.Todd