If you work in tech, product management, or design and haven’t spent the last three years at some hot yoga retreat on a uninhabited island, it’s very likely that you heard the term Design Sprint at least once.

If you still don’t know what’s behind that term, there’s an excellent book called “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” by Jake Knapp (with John Zeratsky and Braden Kowitz) that will clear up any confusion you have much better than I could.

In terms of usefulness and applicability, it’s one of my favorite design books ever (full disclosure: my company AJ&Smart works with Jake on training workshops. And no, we don’t get any commissions or kickbacks if more books get sold!). If you don’t feel like spending any money, there are of course loads of freely accessible resources where you can find out more (for example, here and here).

A lot has already been written about the process itself, by smarter people than me, so I am not going to add more to this. Instead, I want to address some common misconceptions people have about Design Sprints.

Q: “Why do you even care, are you some kind of Design Sprint fanboy?”

A: I guess you could say that! I work as a Product Designer at AJ&Smart. We have been following what Jake and his colleagues were doing at GV with great interest, first via their blog posts, then by their book and finally by having the opportunity to work with Jake himself a couple of times.

Once the book came out, we doubled down and focused on Design Sprints exclusively. We run sprints for clients from Europe and the US, from charities to startups to Fortune 500 companies, and also run Design Sprint trainings for executives, product managers and designers so they can run Design Sprints themselves. So I think it’s fair to say that we have loads of experience running and teaching Design Sprints.

Of course, there are also people in the design industry who think Design Sprints are just a fad, overrated, or even snake oil. I think that’s fair, and I believe skepticism is generally a good quality to have, especially for designers. Having these kind of robust debates is valuable. Usually, it will come out pretty fast if an idea can stand on it’s own or if it falls apart immediately when exposed to reality.

So, here goes nothing:

Top 10 Design Sprint Misconceptions

1. “Design Sprints are about building MVPs faster.”

Careful now. Design Sprints definitely speed things up considerably, but they are not about building a finished product within one week. If you go into your first Sprint with the expectation of having usable code or sending off files to a printer or manufacturer at the end of the week, you are doing it wrong.

I can understand how people get that impression, though. “Design Sprint” is a nice name, but might be confusing to people who know the term from agile development frameworks like Scrum, where things actually get build over multiple iterations. What you work on in the iterations of a Design Sprint is essentially ideas and concepts.

This is why the best place for a Design Sprint is upstream in product development: When you define core ideas and features, strategy and unique value proposition of your product.

Or way, way downstream, to look at the problems in an existing product or service to come up with solutions for them or realign the product vision.

But you should be very wary about implementing any solution without testing it first. Design Sprints are a great tool precisely because they create a space where it’s possible to rapidly try out different things without fear of failure. The stakes are low, failure carries no stigma, and everybody is in an experimental mindset. Even if it turns out in a test that an idea didn’t work, it’s still a valuable insight: it’s one less idea to waste time and resources on and allows you to coldly move on to the next idea. “Failure sucks, but instructs.”

2. “There is no place for research in a Design Sprints.”

Wrong. It’s a common misconception that in a Design Sprint, you skip research and jump straight to generating solutions. If that was the case, it would be pretty bad, but it’s just not true. The start of every Design Sprint is dedicated to learning about problem by interviewing experts and Sprint participants from the client side. What is true, however, is that long, upfront “Design Research” phases are not a part of the Design Sprint (which doesn’t mean that existing data will be ignored when a Sprint kicks off).

3. “But you need to fully understand a problem to solve it!”

I disagree. Unless we are talking about math problems, real-world problems are often very complex, very fuzzy and hard to define, and usually have more than one, ideal solution. Barring omniscience, fully understanding these types of problems is close to impossible (see “wicked problem”).

In Design Sprints, you accept this ambiguity. Instead of waiting until you achieved The Ultimate Truth™, you are willing to take a few educated guesses and run an experiment that will show pretty clearly if you are on the right track or not. The goal of a Design Sprint is not to spit out a perfect solution at the end of one week, but to get feedback on one or two of many possible solutions.

You will learn immediately if your initial assumptions were right or wrong. Based on these insights, you can then decide how to continue (for example, iterating to get closer to a working solution).

Alternatively, you can keep researching a problem for months or years without coming any closer to a solution. But if you want to start attacking your problems, it’s crucial to leave the comfort of the armchair or design studio, get out into the real world and risk being proven wrong: By running an experiment and testing potential solutions with real people.

4. “You need in-depth Design Research to find out what users really want.”

I disagree. I think upstream Design Research has its value, but overly relying on it can be problematic. Very often this kind of research is done in separation from the rest of the business or the organization. If it ever reaches the people who are supposed to work with it, it’s often diluted, misinterpreted or simply ignored.

Waiting for the results of in-depth design research is a perfect excuse for procrastinating on executing on solutions and testing them in reality (such as a prototype). My go-to example for this is Nokia: World-class designers and researchers spent years traveling the globe to find out how people all over Asia and the African continent use their cellphones. The idea: Gain insights how people live, so Nokia can build products that people would buy.

Really fascinating stuff, but this treasure-trove of research still left Nokia unable to defend their market share against the iPhone (which, by the way, was considered a product “real consumers don’t want”). Nokia, an industry juggernaut and defining brand during my youth, on par with Nintendo, Nike and Apple collapsed in a shockingly short amount of time because their products became irrelevant.

5. “The methods used in Design Sprints are nothing new and have been used by Designers forever.”

That’s probably true… but does it matter? Before I read Sprint and took part in a Design Sprint myself, I also struggled with understanding what’s so special about the process. Before “Sprint” came out, we experimented with our own, home-brew processes for years. We relied heavily on an exercise called User Journey Mapping and Lean Personas. For what it’s worth, it worked fairly well and brought a lot more structure to our design process. But the exercises still didn’t lead to a clear goal. There was just not enough momentum to quickly get to a point were we could test ideas. Sometimes we would tweak a prototype for up to a week. As soon as we tested Design Sprints ourselves, it was clear that the way Jake and his colleagues at GV repackaged and bundled the Sprint exercises into a clear, coherent process worked amazingly well for us.

6. “Design Sprints are Design by Committee.”

Wrong. But I get why some people might get this impression. There are several points in a Design Sprint where participants can cast votes, both anonymously, as a group, and openly. But these votes don’t define the direction the Sprint is taking. In each Sprint, one participant has to take the role of the Decider. Whoever does that carries a lot of responsibility because they have to make decisions (duh…) that define in which direction the Sprint is going. Usually this role tends to fall to Product Owners or Product Managers because their teams trust them to make these decisions — but in principle, as long as somebody is willing to make a call, anyone can take on this role. Deciders are free to listen to their team or completely ignore what everybody else says.

7. “Voting in Sprints is trickery to placate people that have no say.“

I don’t agree. There are two reasons for this: First off, it gives every Sprint participant an opportunity to have their say and state their opinions and preferences. This gives them a lot of personal ownership in the results of the Sprint, and I think this is really important. Secondly, the voting serves to map possible directions, which in turn helps Deciders make a call so things can move forward. They can also choose to completely ignore their team’s opinion, but at least they get an idea where everybody stands on an issue and their reasoning behind it.

So, Design Sprints are neither truly democratic nor really hierarchical. The role of the Decider is an important, but as long as somebody is around who can make a decision, it doesn’t truly matter who it is.

8. “Most people lack the skills or creativity to come up with good ideas.”

I couldn’t disagree more.  Creative problem-solving is used by people everywhere, from all backgrounds, in all professions, not just Designers. I do agree that some people might have a higher natural affinity or aptitude for it, but it doesn’t mean that this mode of approaching problems can’t be used by anyone else.

Last year I finally got around to read Designerly Ways of Knowing by Nigel Cross, a design researcher and forethinker of Design Thinking. When I read the book a big, bright lightbulb went off in my head and it completely changed my understanding of design and my own, internal process of problem-solving, and why I was drawn to the design profession in the first place. The book is a really great, short read, and I highly recommend it.

The main takeaway: Design is not (just) a tradecraft or vocation. It’s a skill and an approach to solving problems that is distinctly different from how scientists and artists solve problems — and it’s not only used by designers!

Design Sprints break down these designerly modes of problem-solving into a repeatable process that can be used by anyone. Everybody, not just designers, can have great ideas. But ideas are nothing special or precious. Until you test your ideas, they are dime a dozen. Design Sprints just enable you to follow through and test them faster.

9. “Design Sprints are only for digital products.”

Not at all. While a lot of our Sprints somehow involve digital products or services, the framwork is pretty flexible. We have successfully run Design Sprints on business models, work processes, education, cultural change inside of companies, board games and even snack bars. The only caveat is that you should be able to prototype your solutions at a relatively high degree of fidelity.

10. “You should do a Design Sprint every week.”

You don’t have to. And probably you shouldn’t. Design Sprints are a lot of fun, but also pretty intense. They demand your full attention and focus. We recommend running two Sprint weeks back-to-back per quarter, but your mileage might vary, depending on how you plan to use sprints and who is involved in them. Keep in mind that Design Sprints are mainly about learning, alignment and goal definition. At some point you need to make time to execute on what you have learned. Your Sprints should have given you enough insights to confidently decide which features of a product are most important for an MVP, what features should be shipped as soon as possible, and what ideas you can ignore for the time being.

Conclusion

If you have made it this far, wow. Let me wrap this up: I think a lot of issues people have with Design Sprints are founded in misunderstandings what Sprints claim to do. To be clear, Design Sprints are not the only valid approach to problem-solving and might not work for everyone. So why do I, as a designer, still think that Design Sprints are extremely valuable?

• They offer a productive process that allows to experiment with solutions instead of procrastinating forever.
• They offer self-contained space where failure carries a low risk, no stigma and thus help propagate an experimental mindset: try things and see if they work instead of racking your brain trying to make the one, right decision (which is impossible).
• They compress the time needed from conceptualizing solutions to testing them into a few days.

Design Sprints are just a framework to turn Design Thinking methods into something more applicable and practical. That’s it. And that is very, very valuable.

If you have any criticisms or concerns about Design Sprints, how to use them in practice, or any of my answers, I’d love to address them, so leave a comment!