4 learnings from running Design Sprints
You are at the beginning of launching a new product. You are facing a vague/big/complicated problem that you have no idea what’s the best way to solve it. You are 0% sure about the outcome.
Or you are stuck in regular (or outdated) office behaviors: endless meetings, unproductive debates, or individuals dominating group brainstorms.
Design Sprint is probably what your team need.
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers — Google Ventures
The biggest risk when building a product or solving a problems is that you put too much effort on something that does not bring any value. So instead of spending weeks and months to launch your first minimum viable product, a Design Sprint will help you to test your assumptions and collect data in just 5 days.
How can the process be compressed from months to just a week? You can read the detailed process anywhere (probably GV’s website or The Sprint Book), but beside the process, these are the top 3 of those criteria that make Design Sprint works.
1. Work alone together
You need a team to run Design Sprint, but Design Sprint is not (mainly) about teamwork. Most of the activities during a sprint is individual work: brainstorming, sketching, even voting for ideas (using sticky notes and stickers). The concept of working alone together is that you have a team sitting in a same place, but working individually in silence.
The objective of a Design Sprint is to get the best idea, which is not likely be able to achieve in a short time with discussions. In a discussion with ideas being shouted out, there might be people dominating others: when they talk, everyone shuts up. Voting and working in silence is made up to avoid that problem: the loudest voice wins in a discussion.
What is more, people are encouraged to perform deep work in a Design Sprint. Silence allows team members to concentrate and think, therefore “squeeze” the best part out of their brains.
2. No (or little) democracy
The one that cannot be missed in a Design Sprint team is the Decider: someone with authority to make decisions. At startups, it’s the founder or CEO. At bigger companies, it might be the VP, Manager, or the Team Leader.
In a Design Sprint, lots of decisions have to be made: which problem to solve, which question to answer, or which idea to prototype. When it comes to decision-making, to process goes like this: every members cast a vote (in silence), then the Decider will make his final decision. The decision can be the top voted one, or the one with no votes at all. In short, the decision can be whatever the Decider wants.
This is not really a democratic process which happens outside the Design Sprint. A problem with most meetings is that, people wait for consensus and try to make decisions that everybody will agree on. Getting to that consensus might take endless meetings, and in the worst case, the meeting ends without any decisions.
So to make it happens in just 5 days, it is crucial to have a decision-maker that is forced to make decisions and then the whole team move on. It is also essential that the Decider is the one who understand the problem in depth and have the vision to help find the right solution.
We might ask, if the Decider can decide whatever he wants, then what is the point of voting? Voting gives the Decider inputs to process his decision: it shows a good sense of what his team is thinking.
3. Prototype: made to be thrown away
In eight hours (instead of months or years to build a MVP), you are going to build a façade: a prototype that just appears real. With this eight-hour-prototype, you will be able to test your assumptions and collect data from user testing on the last day of the sprint. As they might say, fake it until you make it.
You could take a longer period of time to build your prototype, even months or years, but that will just slow down your learning process. Those extra work will produce diminishing returns. Or worse, you are putting your time and effort in a solution that could turn out to be a failure.
The more time and effort you spend on a prototype, the more attached you are to it, and the less likely you will be to accept negative feedback. A prototype must appear real, but flexible enough to be fixed or even to be thrown away.
4. High risk, high return
Design Sprint makes you a shortcut from idea to the last point: learn. Therefore, the more vague/bigger/more complicated you problems are, the more suitable the sprint is to your team. If your problem is some kind of too sure or clear, a Design Sprint may not bring you its best benefits.
When you have a success testing risky ideas in a sprint, it’s wonderful. However, what is more valuable, is that you can identify the failures after just 5 days before making any expensive commitments. Fail fast, learn fast, as they might say.
The sprint is great for testing risky solutions that may provide great return on investment. Try to avoid low-risk or safe solutions, because those each wins won’t bring you many learning points in a Design Sprint.
A reason why Design Sprint is suitable for vague/big/complicated problems is that it gives you a starting point when you don’t know what to do or where to start. It allows you to fast-forward into the end of the process to test assumptions with reactions and feedback from real live customers.
Above are the top 4 I learned from a Design Sprint. Share yours and I will be really happy to discuss.
