I’ve spent a lot of effort trying to communicate clearly with people that I meet what the Design Sprint is for, but also not for. There are many blogs, tweets, podcasts and other forms of media that help explain this, but it can be conflicting and confusing depending how familiar you are with the process. Hopefully by the end of this post, I’ll help you realise if a Design Sprint is right for you.
Who are Sprints for?
The fact that the process was born at Google Ventures, famous for being involved in assembling a string of highly successful startups, makes it pretty obvious that it’s a great tool for any tech venture. Here’s a couple of common scenarios:
- I’m at the beginning of my venture but don’t know how to get started.
- The idea is clear in my head, but I can’t seem to get investors/partners to understand.
- I’ve reached a point in my startup journey, but it’s unclear how to move forward.
- My product has had some success, but further growth plans aren’t working as I expected.
If any of these sound like you, a Design Sprint might be right for you.
What do I get if I run a Sprint, what are the outcomes?
As per the book’s promise:
How to solve big problems and test new ideas in just five days.
Tools are designed and crafted to achieve a desired outcome. A broad summary of the outcomes of a typical design sprint are:
- A small, tangible part of your idea or concept. Something you can physically share with others. For us it’s often a clickable prototype.
- Guiding insights from real customers. These are facts that we’ve witnessed first hand, not assumptions. We almost always surprise either our clients or ourselves.
- Alignment and understanding of the problem by your team. If your team understands what we’re trying to achieve, then your customers (probably) will too.
The phrase I always come back to is how Jake Knapp describes it:
It’ll either be an efficient failure, or a flawed success.
If it’s an efficient failure you’ve only invested 3–5 days worth of time and can rethink your idea, pivot, or start again from scratch. If it’s a flawed success, you know broadly what’s working but have some details to work out moving forward. Every single Design Sprint I’ve run I feel has given me clarity on which side of the fence an idea falls into.
Unexpected outcomes we’ve found
There are a couple of unexpected outcomes we’ve found by running a Design Sprint as well. These could be useful for your idea or proposition if you’re particularly worried about these challenges:
People you test your prototype with will more likely help you further down the line.
This is because of the “co-creation effect”. People who got to try out your concept in the early phases, feel like they’ve helped shape the final product and therefore are more likely to work with you in the later stages of your venture. It feels like there’s a vested interest.
You quickly discover whether this person or team is someone you can work with.
An important and often overlooked aspect of assembling a team for a startup venture is how well the team bonds together. The team that has a strong bond and psychological safety with each other will drastically outperform a group of A-players who haven’t bonded as well. By the end we mutually get a feel for whether we could work together over the longer term or not.
When is a Design Sprint right?
The best framework I know of so far for figuring out if you have a Design Sprint worthy problem to solve, is the Wicked Problem definition you can read below.
Out of the 10 characteristics of Wicked Problems, here’s the three that can most quickly help determine the right time to Sprint:
- Wicked problems have no stopping rule, as in there’s no way to know your solution is final.
- Wicked problems do not have a set number of potential solutions.
- Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
Basically if you couldn’t get a “final solution”, if there are many possible solutions, and it’s very expensive (time and/or money) to roll out a “real” solution then it’s definitely worth considering a Design Sprint.
Gotchas and Caveats
I think it’s really important to list the gotchas and caveats, and be aware of them before you even go out and ask someone for a Design Sprint. Some of the most common questions I get asked, or preconceptions I’ve seen are listed below.
You won’t get the “full answer” in one Design Sprint.
A reasonably common misconception is you can go from a single Design Sprint and then build just that thing. You only have a small slice, and you still need the right blend of Design, Technology and Business to execute that idea successfully.
No two Design Sprints are the same.
The insights you learn are very real, and will pay itself back tenfold or more when it comes to your decision making. Keep in mind that who you run it with, how you run it and when you run it will influence the quality of those insights.
Be prepared to put in the hard work following a Sprint.
Successful startups are very tough. If you aren’t fully prepared to commit getting the ball rolling soon after the Sprint, you may want to hold off until you can get your affairs in order.
If you want to do a Design Sprint and even one of these caveats made you stop and think twice, then you may be doing it for the wrong reasons. Arm yourself with more knowledge or talk to a professional.
Further Resources and Reading
Here’s some more reading that I’ve collected from other people, that should help you get more context (and show that I’m not alone). I’ll edit this over time, so check back from time to time 👇.
- 9 Reasons Why We Start Projects With a Design Sprint ← the soft “fluffy” stuff is almost more important
- Stop Brainstorming and Start Sprinting ← why this process even exists
- [One Pager About the] Design Sprint ← print this out for best results
- What’s a Design Sprint and Why is it Important? ← this shows you a great example of the physical outputs
So, when is a Design Sprint the answer?
Solving big, meaty, complex business problems requires an intensive and flexible method to make progress. A Design Sprint is a wonderful tool to help with that, but it isn’t always the right one. Make sure that:
- Your problem is indeed a Wicked Problem; complex and risky.
- You want to use the outcomes of a Sprint for the right reasons.
- You’re ready to take the Sprint outcomes, and hit the ground running.
Convinced? Confused? Confounded!? Drop me an email at email@example.com or let’s do the Twitter thing via @chuckwired.
This blog was originally published on medium.com/tsftech.