The product design sprint: A five-day recipe for startups
Note: This is an old/outdated post. For the latest on the design sprint, check out my book Sprint or this how-to guide.Oct 1, 2012
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?
