3 Golden rules for a better Design Sprint
Have you ever organized or participated in a Design Sprint? Has it helped you to solve big problems and test new ideas in five days? We found that Google Ventures’ Design Sprints work well to crunch problems with your team. But it is easier said than done, as executing this process takes practice.
At 0smosis we started applying the method almost a year ago. Where we started as real rookies reading the Sprint book out loud at every step of the process. Today, we evolved to a seamless way of applying the principles. One that feels natural to us.
We even conducted another one last week.
Pondering on it the week after, let us share 3 golden rules we learned the last year:
1. Importance of defining and assigning clear team roles
Great facilitators: Need to knows
Clearly lay out prepare and follow and prepare the agenda, and make sure to stick to it., Make sure to clarify the goal for each topic/phase to get the whole team along the same line.
Apply the group discussion principle described in the book. Some of your team members love to debate. Sometimes for good reasons and sometimes for the reason of being right (which we all like). The group discussion principle speeds up the process of giving feedback to each other. It allows everybody to explain her/his opinion and implements dot voting to make a “group” decision. There’s an important role for the decider here (see below).
Tip: Nobody in a sprint will take a decision that will cause bankruptcy to your company. So why act like it would when someone disagrees?
Great Decider: You decide
As stated above, assign someone who is responsible for the decision making. Make sure to choose someone that is passionate about solving the problem. Important is that the decider takes the shots and the team accepts this. In the end it will be the customers that will confirm or challenge your assumptions during the interviews. To reach your group objective at the end of the week, it is important to let the decider take the decisions.
Team diversity augments your Design Sprint outcome
Don’t copy paste your regular team dynamics into a design sprint. This will, of course, work as expected. But in order to give the team an extra spark, you need to assemble the team a bit differently. We have done the best design sprints when we added a potential customer and a few external stakeholders. People that normally don’t work together on the same stream of content.
2. The Sprint Book steps are not a 1-size-fits-all solution…but when you apply a step…apply it with rigor
We love good design sprints, but every design sprint is different. Depending on your problem, the requirements you’ll need to meet are different. We performed a revenue model generation sprint for a certain venture. Because of this specific goal, the 2 first days of the design sprint agenda were not fully mappable on our objectives. This means a deviation from the plan. E.g. in this case we bring market studies that we performed in the past to the table and let someone of the team explain its output. Or we push the principle of lightning demo’s to Monday instead of Tuesday. The more you play with the concepts…the better you’ll figure out how to optimize your output.
However, if you feel like applying certain elements described. Apply it with rigor or you’ll fall into the trap of being half pregnant. Wasting time and effort. We learned this through customer interviews. In the beginning, we walked into coffee shops…interviewing people on the spot. This created some value but didn’t give clear and tangible insights. Nor did it provide insight in customer behavior. As soon as we build a real interview facility, where the team could observe. Our eyes opened up! Everything we discussed and the hypothesis got confirmed or challenged. Same goes for organizing good lightning demos or expert interviews. You alter it and change the desired outcome or you apply it like described in blogs and the book. That’s where the value is.
3. The impact of daily retrospectives on your progress
This comes from our core culture where all themes have weekly retros. Design sprints can start off fluffy or unstructured. The location can be bad. Roles can be unclear. Don’t wait till Friday to make this discussable. Do this on Monday or Tuesday so you can adapt your sails and catch some wind to accelerate again the next day. It takes 15 mins of your time, accelerates team dynamics and the pace. So that you can really solve a problem or test an idea in five days.
BONUS: Provide a great location.
Don’t sit in your regular meeting room unless it contains a jacuzzi and champagne bar. Even in that case, different locations work well too.
Did you already do design sprints to crunch big problems? What are your mains lessons learned?
Never did a design sprint but eager to learn more, let me know
