Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

by Jake Knapp

My best work happened when I had a big challenge and not quite enough time.

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

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.

“It’s our mission,” he said, “to find the best entrepreneurs on the planet and help them change the world for the better.”

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.

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?

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.

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.

They also allow you to have more fun along the way.

Introduction

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.

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

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.

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.

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.

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.

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?

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

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.

At the end, you’ll find a set of checklists, including a shopping list and day-by-day guides. You don’t have to memorize everything now—the checklists await you once you’re ready to run your own sprint.

Set the Stage

1 Challenge

So we decided to prototype all three. After all, we didn’t need a functioning website. To appear real in our test, each fake online store only required a few key screens. Working together with the Blue Bottle team, we used Keynote presentation software to make a series of slides that looked like three real websites. With a little ingenuity, and without any computer programming at all, we stitched those screens into a prototype that our test customers could use.

Here are three challenging situations where sprints can help: High Stakes Like Blue Bottle Coffee, you’re facing a big problem and the solution will require a lot of time and money. It’s as if you’re the captain of a ship. A sprint is your chance to check the navigation charts and steer in the right direction before going full steam ahead. Not Enough Time You’re up against a deadline, like Savioke rushing to get their robot ready for the hotel pilot. You need good solutions, fast. As the name suggests, a sprint is built for speed. Just Plain Stuck Some important projects are hard to start. Others lose momentum along the way. In these situations, a sprint can be a booster rocket: a fresh approach to problem solving that helps you escape gravity’s clutches.

The lesson? No problem is too large for a sprint. Yes, this statement sounds absurd, but there are two big reasons why it’s true. First, the sprint forces your team to focus on the most pressing questions. Second, the sprint allows you to learn from just the surface of a finished product. Blue Bottle could use a slide show to prototype the surface of a website—before they built the software and inventory processes to make it really work. Graco could use a brochure to prototype the surface of a sales conversation—before they engineered and built the product they were selling.

Get that surface right, and you can work backward to figure out the underlying systems or technology. Focusing on the surface allows you to move fast and answer big questions before you commit to execution, which is why any challenge, no matter how large, can benefit from a sprint.

2 Team

To build the perfect sprint team, first you’re going to need a Danny Ocean: someone with authority to make decisions. That person is the Decider, a role so important we went ahead and capitalized it. The Decider is the official decision-maker for the project. At many startups we work with, it’s a founder or CEO. At bigger companies, it might be a VP, a product manager, or another team leader. These Deciders generally understand the problem in depth, and they often have strong opinions and criteria to help find the right solution.

But when Sam returned, the project ended. What happened? The solution had tested well—but Sam didn’t think we had picked the right problem to solve in the first place. There were other, more important priorities for the team.

You might feel nervous; after all, it’s a big time commitment for a new process. If your Decider is reluctant, try one or more of these arguments: Rapid Progress Emphasize the amount of progress you’ll make in your sprint: In just one week, you’ll have a realistic prototype. Some Deciders are not excited about customer tests (at least, until they see one firsthand), but almost everyone loves fast results. It’s an Experiment Consider your first sprint an experiment. When it’s over, the Decider can help evaluate how effective it was. We’ve found that many people who are hesitant to change the way they work are open to a onetime experiment. Explain the Tradeoffs Show the Decider a list of big meetings and work items you and your team will miss during the sprint week. Tell her which items you will skip and which you will postpone, and why. It’s About Focus Be honest about your motivations. If the quality of your work is suffering because your team’s regular work schedule is too scattered, say so. Tell the Decider that instead of doing an okay job on everything, you’ll do an excellent job on one thing.

If the Decider agrees to the sprint but can’t spare a full week, invite her to join you at a few key points. On Monday, she can share her perspective on the problem. On Wednesday, she can help choose the right idea to test. And on Friday, she should stop by to see how customers react to the prototype.

If she’s only going to make cameo appearances, your Decider needs to have an official delegate in the room. In many of our sprints with startups, the CEO appoints one or two people from the sprint team to act as Deciders when she’s not there. In one sprint, the CEO sent the design director an email that read, “I hereby grant you all decision-making authority for this project.” Absurd? Yes. Effective? Absolutel...

And if your Decider doesn’t believe the sprint to be worthwhile? If she won’t even stop by for a cameo? Hold up! That’s a giant red flag. You might have the wrong project. Take your time, talk with the Decider...

We’ve found the ideal size for a sprint to be seven people or fewer. With eight people, or nine, or more, the sprint moves more slowly, and you’ll have to work harder to keep everyone focused and productive. With seven or fewer, everything is easier.

But you shouldn’t limit your sprint team to just those who normally work together. Sprints are most successful with a mix of people: the core people who work on execution along with a few extra experts with specialized knowledge.

Decider Who makes decisions for your team? Perhaps it’s the CEO, or maybe it’s just the “CEO” of this particular project. If she can’t join for the whole time, make sure she makes a couple of appearances and delegates a Decider (or two) who can be in the room at all times. Examples: CEO, founder, product manager, head of design Finance expert Who can explain where the money comes from (and where it goes)? Examples: CEO, CFO, business development manager Marketing expert Who crafts your company’s messages? Examples: CMO, marketer, PR, community manager Customer expert Who regularly talks to your customers one-on-one? Examples: researcher, sales, customer support Tech/logistics expert Who best understands what your company can build and deliver? Examples: CTO, engineer Design expert Who designs the products your company makes? Examples: designer, product manager

Before every sprint, we ask: Who might cause trouble if he or she isn’t included? We don’t mean people who argue just for the sake of arguing. We mean that smart person who has strong, contrary opinions, and whom you might be slightly uncomfortable with including in your sprint. This advice is partially defensive. If the troublemaker is in the room, even just for a guest appearance, he or she will feel included and invested in the project. But there’s a more important reason. Troublemakers see problems differently from everyone else. Their crazy idea about solving the problem might just be right. And even if it’s wrong, the presence of a dissenting view will push everyone else to do better work.

If you have more than seven people you think should participate in your sprint, schedule the extras to come in as “experts” for a short visit on Monday afternoon.

A half an hour should be plenty of time for each expert. It’s an efficient way to boost the diversity of perspectives while keeping your team small and nimble.

You need someone to be the Rusty Ryan of your sprint. This person is the Facilitator, and she’s responsible for managing time, conversations, and the overall process. She needs to be confident leading a meeting, including summarizing discussions and telling people it’s time to stop talking and move on.

The Facilitator needs to remain unbiased about decisions, so it’s not a good idea to combine the Decider and Facilitator roles in one person. It often works well to bring in an outsider who doesn’t normally work with your team to be the Facilitator, but it’s not a requirement.

Each expert in the room will provide a key contribution—whether it’s background information, a fresh idea, or even a shrewd observation of your customers. Exactly what they’ll say and do is impossible to predict. But with the right team in place, unexpected solutions will appear.