Turning Google’s design sprint into a marathon
An 8-day design discovery sprint for product teams
A shorter version of this article was published in Issue 272 of the net magazine, as a follow up to the article by Google Venture’s Daniel Burka.
Google Venture’s five-day design sprint (GV5) is a method of assessing startups and product ideas in just, well, five days. Your prospective startuppers drop in on Monday to introduce their business, you come up with some alternative solutions on Tuesday, decide on one via some fierce discussions on Wednesday, rush to your favorite prototyping tool on Thursday, so by Friday you are (supposedly) ready for some real humans to come and tear your concepts apart. You spend the weekend recovering.
Sounds exhausting enough for a week, but how about doing it for months? At Skyscanner, we were so fascinated by the seemingly contradicting idea of strict constraints applied to creative processes that we decided to try and transform GV5. We wanted to develop a version that supports complete product discoveries, typically lasting several months.
Why bother making it longer?
The most important benefit of the sprint is that it sets clear boundaries for the individuals and enables the team to work in synergy. Applying self-judgment or practicing harsh criticism and killing ideas too early can prevent the birth of enough directions. Truly great product ideas come from connecting seemingly unrelated thoughts via elegant shortcuts. Finding these bridges is hard with deductive logic, easier if you try many things. On the other hand, when it comes to killing ideas, everyone needs to become the worst critic so only the best ideas survive.
The sprint introduces certainty in the risky adventure for the ultimate product idea. It is a very powerful tool: you start with nothing on Monday and end up having a verified concept by Friday. You can have the creativity and the guaranteed output too. In this regard it is like a hotfix to address design thinking’s lack of a practical implementation guide.
Obviously GV5 was never meant to be used for extended periods, so we had to change a few things.
Trust in the process
The first advice is not a change really, but it is something we weren’t quite prepared for when introduced GV5 into our processes. The sprint has an overwhelming number of rules, and not everyone will feel comfortable with those. (Having a fancy for board games helps a lot, as it did in our case.) Results coming in slowly will test your patience, and charismatic leaders will start pushing the team towards decision making too early, limiting the number of alternatives discovered. You need to trust that there is a solution out there; you just need to stick to the schedule.
Introduce job stories
We wanted to make the results of research more actionable and inspiring for design, so we got rid of personas and user stories, and replaced them with job stories. Here is an example user story:
As a user, I can indicate folders not to backup,
so that backup drive isn’t filled with stuff I don’t want.
There are a couple of issues with this format: it uses a persona (learn why this is a bad idea); it couples implementation with motivation and outcome, prescribing a certain solution; and it totally ignores context, situation and anxieties. On the other hand a job story looks like this:
When I am in a rush and hungry, I want to eat something quick and sweet, so I can stave off hunger for 30 minutes.
This format frames situation, motivation and expected outcome. It tends to be inclusive rather than exclusive, so it is always easier to expand and apply it to unexpected situations.
Collaborate
As Jake Knapp told us, in order to make the process more robust and remove dependency on the team members’ skills, collaboration is largely missing from the original sprint. However as an established product team, you are more likely to have a track record of successful teamwork. We introduced a few sharing sessions in the process, for example between the two Crazy 8s on Tuesday. We are big fans of the design studio method, and believe that reviewing the same topic iteratively does the natural selection: the group will tend to pick the best ideas heard during the present&critique rounds and perfect them. These emerging patterns will make decisions on Wednesday a lot easier.
Avoid burnout
To avoid burnout we started using Edward de Bono’s lateral thinking methods, which infused new energy into the idea generation exercises (Mind Mapping, Crazy 8s and Storyboarding). Introducing ‘delight sprints’ — tackling such ideas as ‘what if the defining shape of the digital world were the circle instead of the rectangle?’ — after every few feature sprints helped us recharge, too.
We had to adjust each part’s length a bit. As we were focusing on just a feature in each sprint rather than an entirely new product, we could decrease Understand to just half a day. Having a dedicated researcher or anyone with a bit of a practice in your team can easily make up for the limited time. As we were aiming for depth, we needed more time in Diverge and Build and wanted to spend some time iterating to make use of the findings of the usability tests. Luckily an established team makes decisions a lot quicker, so we could save some time there. The result is an 8-day sprint, but with smart overlapping we could still start every sprint on Monday making planning easier.
Dedicate a war room
We squatted in the same meeting room for months, building up a visual history of our adventures on the walls. It made introducing the project to new stakeholders or getting a status report a lot easier. It also acted as a recruiting tool to lure new members in, providing new energy in Diverge.
We used this modified sprint to design from scratch the just released brand new versions of the Skyscanner Flights apps, so the method definitely has some merits. However we never stop hacking our processes, just like our products, so don’t hold back if you have any suggestions. I would be also happy to help you adopt our sprint method.
