Design Sprint

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. 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. 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? 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. 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. 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. 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?