When NOT to Design Sprint "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 18 May 2020 False Design Sprint, Product Design, Mind the Product Mind the Product Ltd 485 Sprinting man shutterstock Product Management 1.94
· 2 minute read

When NOT to Design Sprint

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.

Sprinting man shutterstock

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.

Further Reading

Want to learn more? Here are two great books for you to explore:

  1. Design Sprint: A Practical Guidebook for Building Great Digital Products by Richard Banfield, Trace Wax, and myself!
  2. 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

 

Comments 2

Great article! Around scope, I’ve seen design sprints work well for breaking down complex problems but the facilitator needs to more actively manage participant expectations and concerns. People can definitely get nervous if either they’re worried about getting tangible results by the end of the week, or if they’re concerned that we’ll miss a large piece of the puzzle. In our work with a government agency we found that regular prioritization (ex. of user pain points, process pain points, and how well ideas addressed those issues) helped us to both explore the space and focus in quickly as the week progressed.

Join the community

Sign up for free to share your thoughts

About the author

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. Sprinting man shutterstock

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.

Further Reading

Want to learn more? Here are two great books for you to explore:
  1. Design Sprint: A Practical Guidebook for Building Great Digital Products by Richard Banfield, Trace Wax, and myself!
  2. 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