In our second FAQ post about design sprints (following the first post on who should be present for a design sprint), we are answering the important question of when does it make sense to run a design sprint. And "when" not applies to timing, but also to the specific scenario you find yourself in.

Let's start off with a story.

A while ago we ran a design sprint with an innovation team at one of our clients, a large electronics retailer. They were entering a new space and were considering which products to create there. We flew out to San Francisco (pre COVID), rented some shared design space, and conducted the sprint.

We quickly realized that a design sprint wasn’t actually the right tool for the job.

Both sides didn’t understand enough about the market. The product was actually straddling several markets, each competing in a slightly different way. So when we tried to create a map of the customer experience on the first day of the sprint, we didn’t get very far. In addition, we realized that the conversations around the sprint goals stayed at an extremely high level.

So, we decided to blow up the sprint. We cancelled the normal sprint activities and instead shifted the week’s activities to learning about the market. We conducted a bunch of interviews, did an in-depth analysis of the market and looked for direct and indirect competitors so we really understood the problem at hand, allowing us to rethink the situation in terms of jobs to be done.

While it was tough, we had learned several things about when not to run a sprint.

  • Don’t run them just because sprints are cool or your team just wants to run one
  • Don’t run them because they seem like a short-cut
  • Don’t run them if you don’t understand the market

The last one is a big one. And it might help to hear that more often than not, the question we get is not “why do we need a design sprint” but “when should we run one.” Design sprints have become a common feature in the product world for a reason and a lot of folks have developed a serious appreciation for them.

You want to get to a place where sprints are a tool in your product development arsenal. So knowing when to run them and knowing when not to run them, is critical.

A design sprint can tell you if your idea for a product is worth investing in. And we’re not just talking about money. We’re talking about time.  

So, when do you run a design sprint?

When you have a product concept and you want to know if it’s worth your time and effort (and money). If you have nothing built yet, no mock-up or prototype to work with, then a design sprint is for you. You can use a design sprint to generate that artifact, and then test it. You’ll know if the concept you’ve built is headed in the right direction and worth investing in further.

At Rocket we run sprints when we have one of two questions - a business question or a design question. The first question is “Is this idea worth pursuing?” This is a business question. The sprint becomes a validation (or invalidation) of the idea itself. Sprint questions of this type include “Can we port this experience to mobile?” or “Are people open to buying this as a subscription service?” These are questions of the original sprint type...testing a product concept for validity.

But we’ve also used sprints just as much in the second way. The second question is “What does this idea look like?” This is a design question. This is essentially about building the first prototype of a product or service. The sprint question becomes “is this a good design direction?” for this concept.

Design sprints also help to unlock innovation, faster. As product pros with decades of combined experience under our belt, we’ve seen plenty of products flop, sometimes putting tens of thousands of dollars and months of hard work to waste. Design sprints allow people to gauge the viability of an idea in just five days.

Let’s say you begin your design sprint on a Monday. By EOD that Friday, you’ll have a minimum viable product that will have already undergone usability testing. This means you’ll not only have a prototype to work with, you’ll have feedback from real users who have test-driven that prototype. Most of all, you’ll know whether or not the idea is worth pursuing.