Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days
March 31, 2016
Jake Knapp, John Zeratsky, and Braden Kowitz detail a process "for answering crucial questions through prototyping and testing ideas with customers" in just one workweek.
Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp, John Zeratsky, and Braden Kowitz, Simon & Schuster, 288 pages, $28.00, Hardcover, March 2016, ISBN 9781501121746
Jake Knapp’s view of the world and work changed when he and his wife had their first child 2003. Being filled with a new meaning and purpose at home made him yearn for that feeling when he returned to work, and led to a series of personal experiments in his productivity and output. Being a self-professed “process geek,” he ran experiments with different daily regimens, to-do lists, and even beverage choices. And it worked.
It became a healthy obsession, perfectly suiting him to the work he would go on to do helping improve team processes when he joined Google in 2007. There, he began holding group brainstorming sessions with engineers. There were a lot of fun for everyone involved and left everyone “in great spirits.” What he soon realized, however, is that they didn’t work. None of the ideas being generated were finding their way into practice or product development. So he went back and studied what did work—beginning, once again, with himself. What he found was that the best ideas never come out of a group, even if it is in a group that they are perfected and eventually brought to life. The best ideas came from elsewhere. But where?
Individuals were still thinking up ideas the same way they always had—while sitting at 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.
… 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.
When he looked at the recent projects he had been involved in, and which had produced the greatest leaps forward, Jake noticed they had a few things in common. Other than that time constraint (an “inescapable deadline”), he instilled “a focus on individual work” and “time to prototype” into a new creative process he called a sprint. Google, with its team focus and willingness to experiment, was the perfect place to test his ideas.
Google teams welcomed the experiments. 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. … Soon I was hearing about sprints from people I’d never met.
Knapp eventually moved over to Google Ventures, where he perfected the process with a team of others, including the coauthors John Zeratsky and Braden Kowitz. They’ve fit the process into a standard workweek, and have now employed it over one hundred times to test ideas and help launch new products and companies GV is invested in. But perhaps we should back up for a moment. What, exactly, is 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—adapted into a step-by-step process that any team can use.
The great thing about the process at GV is that “Instead of giving high-level advice,” they “dig into the details.” They don’t swoop in and provide perfect solutions from on high, exiting as heroes at the end. They provide a process that leverages the on-the-ground expertise, culling and honing their ideas and perspectives into an actionable plan and prototype that can be tested with real customers by the end of the process—by the end of the week! And, because “the process relies on the people, knowledge, and tools that every team already has,” you don’t really need them to run it. The book is their do-it-yourself guide to the sprint process, broken out by days of the week.
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.
After they set the stage by introducing and providing background on the efficacy of the process, it is the days of the workweek and how to structure them that that the book is built around.
On Monday, you’ll learn how to work backward, or how to “solve the surface first.” This will help ensure that, at the end of the week, you’ll have prototypes of customer facing surface material to test (for example, the front of a website or a sales brochure), so you can learn what works best for those customers and then build, manufacture, or program the background material to match their needs. You’ll learn how many people, and what kinds of people, you will need on board to construct your sprint team. You’ll learn how to maintain focus and avoid distraction while they’re together, how to set up a good workspace—even what size and how many whiteboards you’ll need, and when to have lunch.
Each day of the week is that detailed and solidly tied to the overall goal, which is having something to test in the real world at the end of the week.
And at the end of the book, you’ll even find a shopping list for sprint supplies, a checklist for each day of the sprint to keep you on track, and a list of frequently asked questions.
Many (if not most) business books these days tell you upfront that the book you’re reading is designed for busy businesspeople, and you should feel free to skip around and find what works for you and your organization. Not so with this book. The only thing I’d suggest you read out of order is the FAQ at the end of the book, which you might want to read first. That is because, in order for it to work, you can’t pick and choose what to use; you have to be committed to the process. If you are, it can and has worked across disciplines and industries all over the world. In addition to running over one hundred sprints themselves, they’ve given speeches and written articles on the process, prompting others to employ it, and just as quickly as they spread throughout Google, they’ve now heard of sprints happening everywhere from Columbia University and a high school math class to Fortune 500s.
Legendary consulting firm McKinsey & Company began running sprints, as did advertising agency Wieden+Kennedy. A team of Google engineers used a sprint with the City of San Francisco to design tools for helping citizens find affordable housing.
The sprint process is used at companies like Airbnb and Facebook. We’ve heard of sprint stories from Munich, Johannesburg, Warsaw, Budapest, Sao Paulo, Montreal, Amsterdam, Singapore, and even Wisconsin.
Being a proudly Wisconsin-based company, that last even Wisconsin was a little jarring. We are, after all, the only place on that list located within the same country as the authors. But we get it. We probably seem a little exotic up here in the Dairyland, what with our tubed meats, fancy cheeses, and fermented beverages. What is certain is that, after reading this book, I’m pretty convinced that the sprint process can work here in the Badger State, throughout our wide range of interests and institutions—from agricultural and industrial concerns, to our many higher education institutions and, perhaps, even a business book distributor located near the shores of Lake Michigan. Because, even here, we know all too well that:
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 new way. If you’d like to give them a try, Sprint is your guide.