[1]

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?







[2]


From Google Ventures, The 6 Ingredients You Need To Run A Design Sprint

Google Ventures’ Jake Knapp lists the people and things you’ll want on hand to start tackling a big design challenge.



[Editor’s note: This is the second post in a seven-part guide on how to conduct your own Google Ventures’ five-day design sprint. Read the first part, on why you should conduct a sprint, here. See more at Google Ventures’s site, Design Staff].

At the Google Ventures Design Studio, we have a five-day process for taking a product or feature from design through prototyping and testing. We call it a product design sprint. This is the second in a series of seven posts on running your own design sprint.
Now that you know what design sprints are good for, you’ll need a few important ingredients to make yours successful. Start with a big, important problem; pitch it to your team; and schedule a user study before you even start. Get the right people and the right supplies in a room and you’re on your way to a successful design sprint.

1. Pick a big fight

The first thing you need is an important design problem, and if you work at a startup, chances are good you probably have one lying around the office. Maybe more than one. It might be something big, like defining your product for the first time, or a big redesign or new feature. Or it might be something detailed, like improving conversion on a single user action. It just has to be really important to the company, and it has to be something you’re struggling to start or to make progress on–otherwise it can be difficult to get the other people you’ll need involved.
As long as it’s an important problem, it’s perfect for a design sprint. It’s OK if you don’t feel ready to start on it yet. No matter how overwhelming or ambiguous, you’ll be able to cut a big swath through the jungle of possible solutions.


2. Get the right people

The ideal sprint team is between four and eight people, but you can get by with more or fewer than that. Just make sure you have at least one:
• Designer: If your startup doesn’t have a designer yet, try to bring in a ringer.
• CEO: At a small startup, the CEO is the key decision-maker and needs to participate in order to get an actionable solution out of the sprint. At a bigger company, you’ll still need buy-in and it’s best to include the CEO, but if they can’t be there the whole time, you can bring them in at key decision-making moments.
• Product manager: The PM (or whoever is filling this role) will likely need to implement the solution that comes out of the sprint.
• User expert: The person on the team who has the most direct contact with customers often has great input, and can be the lead on user testing.
It’s also great to include:
• Engineer
• Marketer
• Anybody else who’s interested


3. Schedule the user study before you have anything to test

Once you know when you’re going to do the sprint, recruit users and schedule the user studies for the last day of the sprint. This is a bit terrifying: you haven’t even started to talk about the problem, let alone design solutions, and people–outsiders!–are going to come in and need to be shown something. This hard deadline, even though it’s artificial, will help you move faster and make tough decisions to focus your work throughout the sprint.


4. Find a facilitator

Pick someone to be the facilitator of the sprint. The facilitator is going to be responsible for managing the sprint and moving things along. They need to be confident leading a meeting, including synthesizing discussions and telling people it’s time to stop talking. They also need to be comfortable with not getting to participate as much in the actual design work, because facilitating is a lot of work. Since you’re the one reading this, you may be a good candidate–but it’s always easiest if the facilitator is an outsider. See if you can get a friend from another company to help out.

5. Put it on the calendar

Clear everybody’s schedule for five consecutive days. It’s also very important to have a dedicated room for the duration of the sprint, usually a conference room with lots of whiteboards.
Much of the magic in design sprints comes from the sense of urgency. By their very nature, startups always feel time-constrained; the short, focused time of the sprint adds another constraint.

6. Gather the ingredients

Luckily, you don’t need anything fancy to run a sprint. Here’s everything I use:
• Sticky notes: I like the yellow 3×5 size.
• Drawing pens: Any standard black or blue pen is probably fine. I like these, or you can get these for extra credit.
• Whiteboards: If your war room doesn’t have a lot of whiteboard space in it, find another war room or some rolling whiteboards, or heck, get some IdeaPaint and get busy.
• Whiteboard markers: I like to use these instead of Sharpies because they’re so versatile. Buy some good ones and be sure to have enough black markers for each person in the sprint.
• Dot stickers: for voting. You want something small with uniform color. Post-It brand dots are great.
• 8.5 × 11 blank copy paper: Nothing special, just have a pack of this on hand.
• Time Timer Clock: Optional, but totally awesome, see here. I guarantee you’ll find it useful during the sprint, and probably during regular meetings afterward.
• Snacks: You’ll need caffeine and food handy. Trail mix, bananas, and dark chocolate covered raisins have proved especially popular at our sprints, although it is possible that it’s just me eating all of it.
• Sticky stuff: You’ll need to stick your drawings and storyboards on the wall. This removable gummy material is inexpensive and works great, with less fuss than tape.
OK, the stage is set. Now it’s time to start the sprint.
Stay tuned for tomorrow’s post, in which we’ll explore the exercises we use on the first day of a sprint.






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