Co.Design

How To Conduct Your Own Google Ventures Design Sprint

To mentor 150 startups in its portfolio, Google Ventures developed a five-day design process. Here, the method’s mastermind, Jake Knapp, details how your company can run its own sprint to solve a big problem.

Editor’s note: This post is part of a seven-part series originally published on Google Ventures’ site, Design Staff.

At Google Ventures, we do product design work with startups all the time. Since we want to move fast and they want to move fast, we’ve optimized a process that gets us predictably good results in five days or less. We call it a product design sprint, and it’s great for getting unstuck or accelerating projects that are already in motion.

I’ve planned and run over 40 of these sprints, first with teams at Google and now with startups in the Google Ventures portfolio. To give you an idea of what one looks like, here’s a project we did with CustomMade:

Over the next several posts, I’ll be sharing a DIY guide for running your own design sprint.

Before the sprint: Prepare
Get the people and things you need.

Day 1: Understand
Dig into the design problem through research, competitive review, and strategy exercises.

Day 2: Diverge
Rapidly develop as many solutions as possible.

Day 3: Decide
Choose the best ideas and hammer out a user story.

Day 4: Prototype
Build something quick and dirty that can be shown to users.

Day 5: Validate
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.

If you think you’ve heard of this model before, well, you’re right. It’s based on the design thinking structure championed by Ideo and Stanford’s d.school. However, I’ve experimented and tweaked the process a bunch over the last few years. The version I’m going to share works especially well for startups.

What doesn’t work about brainstorming

I’m a big-time process nerd. Several years ago, I started experimenting with product design processes at Google. At first, I ran group brainstorming workshops inspired by the Ideo approach. Group brainstorming, where everyone shouts out ideas, is a lot of fun. At the end of a workshop we’d be tired, in good spirits, and the proud owners of a big pile of sticky notes. But the new ideas we came up with didn’t go anywhere. It’s not that we were coming up with dumb ideas—most of the ideas were actually pretty good. Yet still, better ideas were coming from somewhere else. But where?

In my experience, the most successful ideas tended to come from individuals, not groups. The ideas took some individual heads-down work time to develop, too. I ran a lot of workshops before I realized this, so if it seemed obvious to you from the beginning, I hope you’ll cut me some slack.

To make matters worse, my workshops were choosing the winning ideas by consensus. But consensus doesn’t always pick the bold ideas, the unique ideas, or the ideas with design integrity. Consensus tends to compromise.

There were a lot of good things going on in the workshops: focusing a team on one project, considering a range of ideas instead of just one, working on paper, and more. But I decided my method was fundamentally flawed. I was getting good-but-not-great ideas through group brainstorming, then choosing winners by consensus. I knew that wasn’t working, but at first, I wasn’t sure what to do about it.

The magic of constraints

One day I noticed something about my own design projects. The best work happened in short bursts, when I was under a deadline. One example was Gmail Priority Inbox, where we spent four weeks experimenting with different design prototypes. There were hundreds of internal dogfood users signed up to try a new experiment each week, so I had to move fast. By the end of the four weeks, I’d figured out which things worked, and saved months of noodling.

Another example was the project that became Google+ Hangouts. It started as a side project with two Googlers in the Stockholm office. I was visiting for only two days, so I designed as fast as I could. By the end, we had a working prototype that we could start using for our team’s meetings.

In both of these cases, I worked far more efficiently than I ever did in my normal day-to-day routine or in any of my brainstorm workshops. So what was different? I had time to focus and develop ideas on my own, not shouting and pitching the way I would in a group brainstorm.

But I also didn’t have too much time. I couldn’t afford to overthink things or get caught up in urgent but less important issues, the way I often did on normal workdays. And the people I needed to help me—engineers and product managers—were also focused on the project.

There was something magical about a tight time constraint combined with individual work, prototyping, and quick user feedback.

Adapting Ideo-style workshops to work at Google

I decided to try linking an Ideo-style “how might we” workshop to a few days of uninterrupted design time to execute the best ideas. In that very first sprint, designer Jason Cornwell roughed out the idea for the Gmail people widget. I knew I was on the right track.

I focused full-time on running design sprints with various teams at Google. I switched from group ideas to individual ideas and gave people more time to develop those ideas before getting feedback. I tried a bunch of critique and decision-making exercises that didn’t rely on consensus and chose a handful that worked best.

I got a lot of practice: I’d jump from team to team within Google, for a few days or a week at a time, leading sprints for projects like Chrome, Ads, Commerce, Apps, Search, and Google X. It was exciting. The designs were launching, and lots of teams started to run the process on their own.

10x faster: Running design sprints at startups

When I joined Google Ventures, I thought I had sprints all figured out. But I quickly realized I had a lot to learn. The process had to be changed to reflect the differences between a large company like Google and the startups in our portfolio. For example, at Google, it was easy to get three or four designers together for a few days. At a startup, they might be lucky to have one. So we needed design and critique processes that engineers and CEOs could do as easily as designers.

Startups want to get their product out there quickly and learn what’s working, but it’s costly to launch—you have to write more code, fix more bugs, and handle more issues than with a prototype. So we compressed the sprint cycle even further to get companies faster feedback. I ditched polished Photoshop mockups in favor of quick-and-dirty Keynote prototypes. Michael Margolis tied in his lightning-fast research techniques to deliver us next-day feedback.

We’re still learning, but we’ve run enough sprints to be confident the process works well.

Stay tuned to this series, and please give me your thoughts along the way—I’m always looking for more tricks to improve what we do. What processes do you use to get good design results? What helps your company move faster?

Read the second post here.

[Image: Relay via Shutterstock]

Add New Comment

17 Comments

  • I agree with your point about brainstorming vs individual ideating. A lot of my brainspace and energy is lost in handling the group discussion. Reacting to people without hurting their sentiments, mediating between 2 opposite views and i feel a lot of time is lost.

    If we let them all think individually and present their ideas on paper, we can save a lot of time. By allowing everyone to up vote the elements they like, we create a much less noisier atmosphere to capture their opinion. I am very eager to try it out with my team.

  • volaregear2011

    Oh and One Final Thing

    This Vest is linked to the bike with a break away connector
    that mirrors the same actions of the Motorcycle and at the same time it can
    charge Glass thru a coiled USB Connector on the collar and any type of phone in
    its water proof pocket while in use I would really like to know your opinions
    thanks.   

  • Rbean

    A-men.
    Throughout my career I've seen ebbs and flows regarding the brainstorm process; lately with the pendulum swinging back towards the 'ideas come from everywhere' mantra that has us doing large-group ideation sessions for most of our projects.

    While I will agree that fresh perspectives can lead to unexpected thinking at times; when the designer has to take into consideration the design whims of every administrative assistant and CFO, the process becomes more about appeasing the masses and usually results in a watered-down and compromised result that doesn't allow for the natural and instinct-driven-problem-solving that is the designer's raison-d'être.

    The blurting sessions are fun; they are good team-building exercises, but in the context of a big project, they can suck the time and inspiration out of the truly distilled ideas. It's too easy to have an idea when you don't have to be committed to executing on it. Democracy in design is the antipole of brilliance.

    In my experience a designer or small group of designers working in a focussed and saturated environment; with a good brief and strong CS support, with short timelines (which helps remove the ability for rounds and rounds of outside tinkering) often come to the best and most effective solutions.

  • Jake Knapp

    And to focus97 – you're right, good ideas can and often do come from non-designers. I don't think this process works nearly as well if it's just designers involved.

  • Jake Knapp

    Absolutely – creating that focused/saturated/clock-is-ticking environment isn't always natural for organizations, but in my experience it sure works well.

  • Focus97

    This I don't understand. As a designer and front-end developer, the goal is always to provide a great UX. To discount ideas from those who don't have to execute on it runs counter to the larger goal.

    Ideas can come from anywhere. And the challenge of dreaming them up as well as executing on them, no matter their origin, is what makes my roles always enriching.

  • marklambert

    It's too easy to have an idea when you don't have to be committed to executing on it.  That's the amen.Thanks.

  • Ben Nash

    Can we just call it like it is? This process is the most common "design process" that has been around for decades before IDEO. Tim Brown is not the first to "champion" "How Can We?". Industrial designers have long practiced these methods. "Design Thinking" is also a simple rebrand of what all humans already do: problem solve. Even Bauhaus encouraged the artist to work with the industry to solve problems with design processes over 100 years ago. Maybe we all need to share these processes more (like this article does), but its not new. 

  • Jake Knapp

    Very true, and I hope you don't get the impression that I think I invented design thinking! I do think that, no matter how long design thinking has been around, many people still struggle to practice it in a meaningful way in non-agency, non-academic environments. I'd love to see people start sharing more how they do it in the real world.

  • jnetic

    I agree that better or more developed ideas can come from individuals. However, group brainstorming does provide more wider divergent possibilities on problems. These divergent possibilities I think can often provide great intuitive fuel in doing more focused development of ideas by individuals.

  • Jake Knapp

    Interesting. Adding another layer has some risk – I always worry about the balance between tiring participants (any kind of problem solving, while fun, can also be pretty taxing on energy) and generating the most exhaustive set of solutions. But this kind of approach could be worth trying.

  • Focus97

    I appreciated reading this: "In my experience, the most successful ideas tended to come from
    individuals, not groups. The ideas took some individual heads-down work
    time to develop, too."

    My own experience tells me that my best ideas ("best" as in supported by client feedback and then time-tested viability) always required steeping myself in focused time as uninterrupted as possible. The above quote also reminds me of Rework from 37Signals, where brainstorming is listed as a waste of time. That's a bit extreme, as brainstorming sessions (and meetings in general) have their merits, but the gist is that great ideas require good old fashioned, focused due diligence. Deadlines certainly help that effort.

    Great to read about the experience from such a large enterprise's point of view.

  • Jake Knapp

    Thanks for reading! It's true that a lot of my obsession with deadlines comes from the fact that, like you, I found that uninterrupted time was golden, but (hopefully unlike you) I have a terrible problem with focusing my attention. The sprints in many ways are just an elaborate method for creating a fake (but irrevocable) deadline for myself so I get good quality make time. :)

  • Jane Jordan

    I agree with time restraint producing the best ideas. There is nothing better than a looming deadline to focus the thought process.

    Great article.

  • Ruthie

    I love the point you make about great ideas coming from individuals and the lack of consensus needed to arrive at great decisions! 

    Thank you for pulling back the curtain and sharing the process that you've spent so much time developing and refining. Very insightful!