Contents

Cover

About the Book

Title Page

Dedication

Preface

Introduction

Set the Stage

Challenge

Start with a big problem

Team

Get a Decider, a Facilitator, and a diverse team

Time and Space

Schedule five days and find the right room

Monday

Start at the End

Agree to a long-term goal

Map

Diagram the problem

Ask the Experts

Interview your teammates and other experts

Target

Choose a focus for your sprint

Tuesday

Remix and Improve

Look for old ideas and inspiration

Sketch

Put detailed solutions on paper

Wednesday

Decide

Choose the best solutions without groupthink

Rumble

Keep competing ideas alive

Storyboard

Make a plan for the prototype

Thursday

Fake it

Build a façade instead of a product

Prototype

Find the right tools, then divide and conquer

Friday

Small Data

Get big insights from just five customers

Interview

Ask the right questions

Learn

Find patterns and plan the next step

Liftoff

One last nudge to help you start

Checklists

Frequently Asked Questions

Thank-You Notes

Image Credits

Index

About the Authors

Copyright

TRANSWORLD PUBLISHERS
61–63 Uxbridge Road, London W5 5SA
www.penguin.co.uk

Transworld is part of the Penguin Random House group of companies whose addresses can be found at global.penguinrandomhouse.com

First published in Great Britain in 2016 by Bantam Press
an imprint of Transworld Publishers
Copyright © Jake Knapp, John Zeratsky and Braden Kowitz 2016
Cover design and typography © Jessica Hische

Jake Knapp, John Zeratsky and Braden Kowitz have asserted their right under the Copyright, Designs and Patents Act 1988 to be identified as the authors of this work.

A CIP catalogue record for this book is available from the British Library.

Version 1.0 Epub ISBN 9781473526808
ISBN 9780593076118

This ebook is copyright material and must not be copied, reproduced, transferred, distributed, leased, licensed or publicly performed or used in any way except as specifically permitted in writing by the publishers, as allowed under the terms and conditions under which it was purchased or as strictly permitted by applicable copyright law. Any unauthorized distribution or use of this text may be a direct infringement of the author’s and publisher’s rights and those responsible may be liable in law accordingly.

1 3 5 7 9 10 8 6 4 2

Jake:

To Mom, who helped me make castles out of cardboard
And to Holly, who picked me up when I caught the wrong bus

John:

To my grandpa Gib, who would have bought the first hundred books

Braden:

To my parents, who encouraged me to
explore the world and make it better

Preface

What I was doing at work wasn’t working.

In 2003, my wife and I had our first child. When I returned to the office, I wanted my time on the job to be as meaningful as my time with family. I took a hard look at my habits – and saw that I wasn’t spending my effort on the most important work.

So I started optimizing. I read productivity books. I made spreadsheets to track how efficient I felt when I exercised in the morning versus at lunchtime, or when I drank coffee versus tea. During one month, I experimented with five different kinds of to-do lists. Yes, all of this analysis was weird. But little by little, I got more focused and more organized.

Then, in 2007, I got a job at Google, and there, I found the perfect culture for a process geek. Google encourages experimentation, not only in the products, but in the methods used by individuals . . . and teams.

Improving team processes became an obsession for me (yes, weird again). My first attempts were brainstorming workshops with teams of engineers. Group brainstorming, where everyone shouts out ideas, is a lot of fun. After a few hours together, we’d have a big pile of sticky notes and everyone would be in great spirits.

But one day, in the middle of a brainstorm, an engineer interrupted the process. “How do you know brainstorming works?” he asked. I wasn’t sure what to say. The truth was embarrassing: I had been surveying participants to see if they enjoyed the workshops, but I hadn’t been measuring the actual results.

So I reviewed the outcome of the workshops I’d run. And I noticed a problem. The ideas that went on to launch and become successful were not generated in the shout-out-loud brainstorms. The best ideas came from somewhere else. But where?

Individuals were still thinking up ideas the same way they always had – while sitting at their desks, or waiting at a coffee shop, or taking a shower. Those individual-generated ideas were better. When the excitement of the workshop was over, the brainstorm ideas just couldn’t compete.

Maybe there wasn’t enough time in these sessions to think deeply. Maybe it was because the brainstorm ended with drawings on paper, instead of something realistic. The more I thought about it, the more flaws I saw in my approach.

I compared the brainstorms with my own day-to-day work at Google. My best work happened when I had a big challenge and not quite enough time.

One such project happened in 2009. A Gmail engineer named Peter Balsiger came up with an idea for automatically organizing email. I got excited about his idea – known as “Priority Inbox” – and recruited another engineer, Annie Chen, to work on it with us. Annie agreed, but she would only give it one month. If we couldn’t prove that the idea was viable in that time, she’d switch to a different project. I was certain that one month wasn’t enough time, but Annie is an outstanding engineer, so I decided to take what I could get.

We split the month into four weeklong chunks. Each week, we came up with a new design. Annie and Peter built a prototype, and then, at the end of the week, we tested the design with a few hundred people.

By the end of the month, we had struck on a solution that people could understand – and wanted to use. Annie stayed on to lead the Priority Inbox team. And somehow, we’d done the design work in a fraction of the usual time.

A few months later, I visited Serge Lachapelle and Mikael Drugge, two Googlers who work in Stockholm. The three of us wanted to test an idea for video meeting software that could run in a web browser. I was only in town for a few days, so we worked as fast as we could. By the end of the visit, we had a working prototype. We emailed it to our coworkers and started using it for meetings. After a few months, the whole company was using it. (Later, a polished and improved version of that web-based app launched as Google Hangouts.)

In both cases, I realized I had worked far more effectively than in my normal daily routine or in any brainstorm workshop. What was different?

First, there was time to develop ideas independently, unlike the shouting and pitching in a group brainstorm. But there wasn’t too much time. Looming deadlines forced me to focus. I couldn’t afford to overthink details or get caught up in other, less important work, as I often did on regular workdays.

The other key ingredients were the people. The engineers, the product manager, and the designer were all in the room together, each solving his or her own part of the problem, each ready to answer the others’ questions.

I reconsidered those team workshops. What if I added these other magic ingredients – a focus on individual work, time to prototype, and an inescapable deadline? I decided to call it a design “sprint.”

I created a rough schedule for my first sprint: a day of sharing information and sketching ideas, followed by four days of prototyping. Once again, Google teams welcomed the experiment. I led sprints for Chrome, Google Search, Gmail, and other projects.

It was exciting. The sprints worked. Ideas were tested, built, launched, and best of all, they often succeeded in the real world. The sprint process spread across Google from team to team and office to office. A designer from Google X got interested in the method, so she ran a sprint for a team in Ads. The Googlers from the Ads sprint told their colleagues, and so on. Soon I was hearing about sprints from people I’d never met.

I made some mistakes along the way. My first sprint involved forty people – a ridiculously high number that nearly derailed the sprint before it began. I adjusted the amount of time spent on developing ideas and the time spent on prototyping. I learned what was too fast, too slow, and finally, just right.

A couple of years later, I met with Bill Maris to talk about sprints. Bill is the CEO of Google Ventures, a venture capital firm created by Google to invest in promising startups. He’s one of the most influential people in Silicon Valley. However, you wouldn’t know it from his casual demeanor. On that particular afternoon, he was wearing a typical outfit of his: a baseball hat and a T-shirt that said something about Vermont.

Bill was interested in the idea of running sprints with the startups in GV’s portfolio. Startups usually get only one good shot at a successful product before they run out of money. Sprints could give these companies a way to find out if they were on the right track before they committed to the risky business of building and launching their products. There was money to be made, and saved, from running sprints.

But to make it work, I’d have to adapt the sprint process. I had been thinking about individual productivity and team productivity for years. But I knew next to nothing about startups and their business questions. Still, Bill’s enthusiasm convinced me that Google Ventures was the right place for sprints – and the right place for me. “It’s our mission,” he said, “to find the best entrepreneurs on the planet and help them change the world for the better.” I couldn’t resist.

At GV, I joined three other design partners: Braden Kowitz, John Zeratsky, and Michael Margolis. Together, we began running sprints with startups, experimenting with the process, and examining the results to find ways to improve.

The ideas in this book come from our entire team. Braden Kowitz added story-centered design to the sprint process, an unconventional approach that focuses on the whole customer experience instead of individual components or technologies. John Zeratsky helped us start at the end, so that each sprint would answer the business’s most important questions. Braden and John had the startup and business experience I lacked, and they reshaped the process to create better focus and smarter decisions in every sprint.

Michael Margolis encouraged us to finish each sprint with a real-world test. He took customer research, which can take weeks to plan and execute, and figured out a way to get clear results in just one day. It was a revelation. We didn’t have to guess whether our solutions were good. At the end of each sprint, we got answers.

And then there’s Daniel Burka, an entrepreneur who founded two startups of his own before selling one to Google and joining GV. When I first described the sprint process to him, he was skeptical. As he put it later, “It sounded like a bunch of management mumbo jumbo.” But he agreed to try one. “In that first sprint, we cut through the BS and made something ambitious in just a week. I was hooked.” Once we won him over, Daniel’s firsthand experience as a founder, and his zero tolerance for baloney, helped us perfect the process.

Since the first sprint at GV in 2012, we’ve adjusted and experimented. At first we thought rapid prototyping and research would only work for mass-market products. Could we move as quickly when the customers were experts in fields such as medicine or finance?

To our surprise, the five-day process held up. It worked for all kinds of customers, from investors to farmers, from oncologists to small-business owners. It worked for websites, iPhone apps, paper medical reports, and high-tech hardware. And it wasn’t just for developing products. We’ve used sprints for prioritization, for marketing strategy, even for naming companies. Time and time again, the process brings teams together and brings ideas to life.

Over the past few years, our team has had an unparalleled opportunity to experiment and validate our ideas about work process. We’ve run more than one hundred sprints with the startups in the GV portfolio. We’ve worked alongside, and learned from, brilliant entrepreneurs like Anne Wojcicki (founder of 23andMe), Ev Williams (founder of Twitter, Blogger, and Medium), and Chad Hurley and Steve Chen (founders of YouTube).

In the beginning, I wanted to make my workdays efficient and meaningful. I wanted to focus on what was truly important and make my time count – for me, for my team, and for our customers. Now, more than a decade later, the sprint process has consistently helped me reach that goal. And I’m superexcited to share it with you in this book.

With luck, you chose your work because of a bold vision. You want to deliver that vision to the world, whether it’s a message or a service or an experience, software or hardware or even – as in the case of this book – a story or an idea. But bringing a vision to life is difficult. It’s all too easy to get stuck in churn: endless email, deadlines that slip, meetings that burn up your day, and long-term projects based on questionable assumptions.

It doesn’t have to be that way. Sprints offer a path to solve big problems, test new ideas, get more done, and do it faster. They also allow you to have more fun along the way. In other words, you’ve absolutely got to try one for yourself. Let’s get to work.

– Jake Knapp       

San Francisco, February 2016

Introduction

One overcast morning in May 2014, John Zeratsky walked into a drab beige building in Sunnyvale, California. John was there to talk with Savioke Labs, one of Google Ventures’ newest investments. He wound his way through a labyrinth of corridors and up a short flight of stairs, found the plain wooden door marked 2B, and went inside.

Now, tech companies tend to be a little disappointing to those expecting glowing red computer eyes, Star Trek–style holodecks, or top secret blueprints. Most of Silicon Valley is essentially a bunch of desks, computers, and coffee cups. But behind door 2B there were piles of circuit boards, plywood cutouts, and plastic armatures fresh off the 3D printer. Soldering irons, drills, and blueprints. Yes, actual top secret blueprints. “This place,” thought John, “looks like a startup should look.”

Then he saw the machine. It was a three-and-a-half-foot-tall cylinder, roughly the size and shape of a kitchen trash can. Its glossy white body had a flared base and an elegant taper. There was a small computer display affixed to the top, almost like a face. And the machine could move. It glided across the floor under its own power.

“This is the Relay robot,” said Steve Cousins, Savioke’s founder and CEO. Steve wore jeans and a dark T-shirt, and had the enthusiastic air of a middle-school science teacher. He watched the little machine with pride. “Built right here, from off-the-shelf parts.”

The Relay robot, Steve explained, had been engineered for hotel delivery service. It could navigate autonomously, ride the elevator by itself, and carry items such as toothbrushes, towels, and snacks to guest rooms. As they watched, the little robot carefully drove around a desk chair, then stopped near an electrical outlet.

Savioke (pronounced “Savvy Oak”) had a team of world-class engineers and designers, most of them former employees of Willow Garage, a renowned private robotics research lab in Silicon Valley. They shared a vision for bringing robot helpers into humans’ everyday lives – in restaurants, hospitals, elder care facilities, and so on.

Steve had decided to start with hotels because they were a relatively simple and unchanging environment with a persistent problem: “rush hour” peaks in the morning and evening when check-ins, check-outs, and room delivery requests flooded the front desk. It was the perfect opportunity for a robot to help. The next month, this robot – the first fully operational Relay – would go into service at a nearby hotel, making real deliveries to real guests. If a guest forgot a toothbrush or a razor, the robot would be there to help.

But there was one problem. Steve and his team worried that guests might not like a delivery robot. Would it unnerve or even frighten them? The robot was a technological wonder, but Savioke wasn’t sure how the machine should behave around people.

There was too much of a risk, Steve explained, that it could feel creepy to have a machine delivering towels. Savioke’s head designer, Adrian Canoso, had a range of ideas for making the Relay appear friendly, but the team had to make a lot of decisions before the robot would be ready for the public. How should the robot communicate with guests? How much personality was too much? “And then there’s the elevator,” Steve said.

John nodded. “Personally, I find elevators awkward with other humans.”

“Exactly.” Steve gave the Relay a pat. “What happens when you throw a robot in the mix?”

Savioke had only been in business for a few months. They’d focused on getting the design and engineering right. They’d negotiated the pilot with Starwood, a hotel chain with hundreds of properties. But they still had big questions to answer. Mission-critical, make-or-break type questions, and only a few weeks to figure out the answers before the hotel pilot began.

It was the perfect time for a sprint.

The sprint is GV’s unique five-day process for answering crucial questions through prototyping and testing ideas with customers. It’s a “greatest hits” of business strategy, innovation, behavioral science, design, and more – packaged into a step-by-step process that any team can use.

The Savioke team considered dozens of ideas for their robot, then used structured decision-making to select the strongest solutions without groupthink. They built a realistic prototype in just one day. And for the final step of the sprint, they recruited target customers and set up a makeshift research lab at a nearby hotel.

We’d love to tell you that we, the authors, were the genius heroes of this story. It’d be wonderful if we could swoop into any company and dish out brilliant ideas that would transform it into a breakout success. Unfortunately, we are not geniuses. Savioke’s sprint worked because of the real experts: the people who were on the team all along. We just gave them a process to get it done.

Here’s how the Savioke sprint went down. And if you’re not a roboticist yourself, don’t worry. We use this same exact sprint structure for software, services, marketing, and other fields.

First, the team cleared a full week on their calendars. From Monday to Friday, they canceled all meetings, set the “out of office” responders on their email, and completely focused on one question: How should their robot behave around humans?

Next, they manufactured a deadline. Savioke made arrangements with the hotel to run a live test on the Friday of their sprint week. Now the pressure was on. There were only four days to design and prototype a working solution.

On Monday, Savioke reviewed everything they knew about the problem. Steve talked about the importance of guest satisfaction, which hotels measure and track religiously. If the Relay robot boosted satisfaction numbers during the pilot program, hotels would order more robots. But if that number stayed flat, or fell, and the orders didn’t come in, their fledgling business would be in a precarious position.

Together, we created a map to identify the biggest risks. Think of this map as a story: guest meets robot, robot gives guest toothbrush, guest falls for robot. Along the way were critical moments when robot and guest might interact for the first time: in the lobby, in the elevator, in the hallway, and so on. So where should we spend our effort? With only five days in the sprint, you have to focus on a specific target. Steve chose the moment of delivery. Get it right, and the guest is delighted. Get it wrong, and the front desk might spend all day answering questions from confused travelers.

One big concern came up again and again: The team worried about making the robot appear too smart. “We’re all spoiled by C-3PO and WALL-E,” explained Steve. “We expect robots to have feelings and plans, hopes and dreams. Our robot is just not that sophisticated. If guests talk to it, it’s not going to talk back. And if we disappoint people, we’re sunk.”

On Tuesday, the team switched from problem to solutions. Instead of a raucous brainstorm, people sketched solutions on their own. And it wasn’t just the designers. Tessa Lau, the chief robot engineer, sketched. So did Izumi Yaskawa, the head of business development, and Steve, the CEO.

By Wednesday morning, sketches and notes plastered the walls of the conference room. Some of the ideas were new, but some were old ideas that had once been discarded or never thought through. In all, we had twenty-three competing solutions.

How could we narrow them down? In most organizations, it would take weeks of meetings and endless emails to decide. But we had a single day. Friday’s test was looming, and everybody could sense it. We used voting and structured discussion to decide quickly, quietly, and without argument.

The test would include a slate of Savioke designer Adrian Canoso’s boldest ideas: a face for the robot and a soundtrack of beeps and chimes. It would also include one of the more intriguing but controversial ideas from the sketches: When the robot was happy, it would do a dance. “I’m still nervous about giving it too much personality,” Steve said. “But this is the time to take risks.”

“After all,” said Tessa, “if it blows up now, we can always dial back.” Then she saw the looks on our faces. “Figure of speech. Don’t worry, the robot can’t actually blow up.”

As Thursday dawned, we had just eight hours to get the prototype ready for Friday’s live test in the hotel. That shouldn’t have been enough time. We used two tricks to finish our prototype on time:

1.  Much of the hard work had been done already. On Wednesday, we had agreed on which ideas to test, and documented each potential solution in detail. Only the execution remained.

2.  The robot didn’t need to run autonomously, as it would eventually in the hotel. It just needed to appear to work in one narrow task: delivering one toothbrush to one room.

Tessa and fellow engineer Allison Tse programmed and tuned the robot’s movements using a beat-up laptop and a PlayStation controller. Adrian put on a pair of massive headphones and orchestrated the sound effects. The “face” was mocked up on an iPad and mounted to the robot. By 5 p.m., the robot was ready.

For Friday’s test, Savioke had lined up interviews with guests at the local Starwood hotel in Cupertino, California. At 7 a.m. that morning, we rigged a makeshift research lab inside one of the hotel’s rooms by duct-taping a couple of webcams to the wall. And at 9:14 a.m., the first guest was beginning her interview.

The young woman studied the hotel room decor: light wood, neutral tones, a newish television. Nice and modern, but nothing unusual. So what was this interview all about?

Standing beside her was Michael Margolis, a research partner at GV. For now, Michael wanted to keep the subject of the test a surprise. He had planned out the entire interview to answer certain questions for the Savioke team. Right now, he was trying to understand the woman’s travel habits, while encouraging her to react honestly when the robot appeared.

Michael adjusted his glasses and asked a series of questions about her hotel routine. Where does she place her suitcase? When does she open it? And what would she do if she’d forgotten her toothbrush?

“I don’t know. Call the front desk, I suppose?”

Michael jotted notes on a clipboard. “Okay.” He pointed to the desk phone. “Go ahead and call.” She dialed. “No problem,” the receptionist said. “I’ll send up a toothbrush right away.”

As soon as the woman returned the receiver to its cradle, Michael continued his questions. Did she always use the same suitcase? When was the last time she’d forgotten something on a trip?

Brrrring. The desk phone interrupted her. She picked up, and an automated message played: “Your toothbrush has arrived.”

Without thinking, the woman crossed the room, turned the handle, and opened the door. Back at headquarters, the sprint team members were gathered around a set of video displays, watching her reaction.

“Oh my god,” she said. “It’s a robot!”

The glossy hatch opened slowly. Inside was the toothbrush. The robot made a series of chimes and beeps as the woman confirmed delivery on its touch screen. When she gave the experience a five-star review, the little machine danced for joy by twisting back and forth.

“This is so cool,” she said. “If they start using this robot, I’ll stay here every time.” But it wasn’t what she said. It was the smile of delight that we saw over the video stream. And it was what she didn’t do – no awkward pauses and no frustration as she dealt with the robot.

Watching the live video, we were nervous throughout that first interview. By the second and third, we were laughing and even cheering. Guest after guest responded the same way. They were enthusiastic when they first saw the robot. They had no trouble receiving their toothbrushes, confirming delivery on the touch screen, and sending the robot on its way. People wanted to call the robot back to make a second delivery, just so they could see it again. They even took selfies with the robot. But no one, not one person, tried to engage the robot in any conversation.

At the end of the day, green check marks filled our whiteboard. The risky robot personality – those blinking eyes, sound effects, and, yeah, even the “happy dance” – was a complete success. Prior to the sprint, Savioke had been nervous about overpromising the robot’s capability. Now they realized that giving the robot a winsome character might be the secret to boosting guest satisfaction.

Not every detail was perfect, of course. The touch screen was sluggish. The timing was off on some of the sound effects. One idea, to include games on the robot’s touch screen, didn’t appeal to guests at all. These flaws meant reprioritizing some engineering work, but there was still time.

Three weeks later, the robot went into full-time service at the hotel. And the Relay was a hit. Stories about the charming robot appeared in the New York Times and the Washington Post, and Savioke racked up more than 1 billion media impressions in the first month. But, most important, guests loved it. By the end of the summer, Savioke had so many orders for new robots that they could hardly keep up with production.

Savioke gambled by giving their robot a personality. But they were only confident in that gamble because the sprint let them test risky ideas quickly.

The trouble with good ideas

Good ideas are hard to find. And even the best ideas face an uncertain path to real-world success. That’s true whether you’re running a startup, teaching a class, or working inside a large organization.

Execution can be difficult. What’s the most important place to focus your effort, and how do you start? What will your idea look like in real life? Should you assign one smart person to figure it out or have the whole team brainstorm? And how do you know when you’ve got the right solution? How many meetings and discussions does it take before you can be sure? And, once it’s done, will anybody care?

As partners at GV, it’s our mission to help our startups answer these giant questions. We’re not consultants paid by the hour. We’re investors, and we succeed when our companies succeed. To help them solve problems quickly and be self-sufficient, we’ve optimized our sprint process to deliver the best results in the least time. Best of all, the process relies on the people, knowledge, and tools that every team already has.

Working together with our startups in a sprint, we shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, our companies get clear data from a realistic prototype.

The sprint gives our startups a superpower: They can fast-forward into the future to see their finished product and customer reactions, before making any expensive commitments. When a risky idea succeeds in a sprint, the payoff is fantastic. But it’s the failures that, while painful, provide the greatest return on investment. Identifying critical flaws after just five days of work is the height of efficiency. It’s learning the hard way, without the “hard way.”

At GV, we’ve run sprints with companies like Foundation Medicine (makers of advanced cancer diagnostics), Nest (makers of smart home appliances), and Blue Bottle Coffee (makers of, well, coffee). We’ve used sprints to assess the viability of new businesses, to make the first version of new mobile apps, to improve products with millions of users, to define marketing strategies, and to design reports for medical tests. Sprints have been run by investment bankers looking for their next strategy, by the team at Google building the self-driving car, and by high school students working on a big math assignment.

This book is a DIY guide for running your own sprint to answer your pressing business questions. On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a realistic prototype. And on Friday, you’ll test it with real live humans.

Instead of giving high-level advice, we dig into the details. We’ll help you assemble the perfect sprint team from the people with whom you already work. You’ll learn big stuff (like how to get the most out of your team’s diverse opinions and one leader’s vision), medium stuff (like why your team should spend three straight days with your phones and computers off), and nitty-gritty stuff (like why you should eat lunch at 1 p.m.). You won’t finish with a complete, detailed, ready-to-ship product. But you will make rapid progress, and know for sure if you’re headed in the right direction.