Google design sprint — why and when to run one

By Nick Butler

Tags: Agile

The Google Design Sprint book with post-its and pens.

Here at Boost we’ve been keen to give the Google design sprint a try for a while and a couple of weeks ago we had our first crack at one.

This is the first of three posts based on the experience. In it you’ll learn why and when you might want to run a Google design sprint. The next post shows you how to run one. And lastly we present a case study on Boost’s inaugural design sprint.

What is the Google design sprint?

The Google design sprint is a set of structured activities developed to help organisations answer critical business questions by designing, prototyping and testing solutions over five days. Often these questions are about potential new products or services, or new features for existing offerings.

Developed first at Google, the system was then refined at Google Ventures (now GV). There are various versions of the design sprint; we followed the process laid out in the book Sprint by Jake Knapp with John Zeratsky & Braden Kowitz.

While the Google sprint is different to the Scrum sprint, they share the same Agile DNA.

When to use the Google design sprint

Sprint is ideal for the big challenges, for projects that are:

high stakes
short of time
stuck and need a fresh start.

It’s a chance to try high risk/high reward approaches without investing too much time and money. It also lets you concentrate your effort into a short period. And it gives you a structured approach that can jumpstart your creativity and decision making.

You can use it to develop things like business strategies and marketing plans. You can be building physical products, designing documents or working on creative projects. It’s even been used for school assignments.

All this means that, while sprint is ideal for IT start ups, its potential uses extend further. It can work for government and not-for-profit projects, for organisations of pretty much any size, in any sector.

If you want to learn about the experiences of a range of organisations using Sprint, check out the case studies collected at Sprint Stories.

Why use the Google design sprint

The process itself has been tried and tested. Jake Knapp traces its origins to an engineer at Google asking if group brainstorming actually worked. A self-confessed “process geek”, Knapp researched what produces successful ideas and found it wasn’t brainstorming. He came up with a new approach and has refined each element over hundreds of sprints. Having moved to GV he had plenty of motivation to get it right. GV was literally invested in the companies he and his colleagues ran sprints with.

In the sprint you:

take the time to get clear what the big challenge is
work separately to develop solutions, avoiding the groupthink of group brainstorms
use structured voting and a designated Decider to make quick, focussed choices
build a prototype to learn if your solution works before you build the full product
test your prototype with your target customers to get honest, actionable insights.