Aibrary Logo
Podcast thumbnail

Sprint

10 min

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

Introduction

Narrator: Imagine a robotics startup, Savioke, has built a brilliant delivery robot named Relay. It can navigate a hotel, ride the elevator, and arrive at a guest's door with a toothbrush or a snack. The technology works. But a huge, paralyzing question remains: how should it behave? Should it be purely functional, or should it have a personality? The team is stuck. They worry that if they make it too cute, like the famous robot WALL-E, they’ll disappoint guests when it can’t hold a conversation. But if it’s too cold, it might feel creepy. With a pilot program at a major hotel chain just weeks away, they don't have months to debate. They have days. This high-stakes problem, where time is short and the risk of failure is high, is the exact scenario at the heart of the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Written by Google Ventures partners Jake Knapp, John Zeratsky, and Braden Kowitz, it offers a structured, five-day process for fast-forwarding into the future to see how customers react to new ideas before you invest heavily in building them.

The Sprint Checklist: Setting the Stage for Success

Key Insight 1

Narrator: Before a single idea is sketched, a successful sprint depends entirely on preparation. The authors argue that a sprint is not a loose brainstorming session but a highly structured process, and the setup is non-negotiable. The first step is choosing the right challenge—a problem that is high-stakes, complex, and urgent. Next is assembling the right team. The ideal size is seven people or fewer, bringing diverse skills like engineering, design, marketing, and finance. Most critically, this team must include a "Decider." This is the person with the authority to make the final call, often a CEO or head of product.

The book tells a cautionary tale of a startup they call "SquidCo," where the team ran a sprint without their chief product officer, the Decider. They developed a brilliant prototype that tested wonderfully with customers. But when the CPO returned, he rejected the entire project because he felt they had solved the wrong problem. The week was wasted. A sprint without a Decider is just a workshop; its conclusions won't stick. The final pieces of the setup are logistical: booking a dedicated room for five full days, ensuring it has at least two large whiteboards, and enforcing a strict no-devices rule to guarantee focus.

Monday and Tuesday: From Abstract Problem to Concrete Solutions

Key Insight 2

Narrator: The sprint week begins on Monday by defining the problem. The authors advocate for a method they call "Start at the End." Instead of diving into solutions, the team first agrees on a long-term goal. To illustrate this, they point to the Apollo 13 mission. When the oxygen tank exploded, Mission Control didn't just start fixing random things. Flight Director Gene Kranz established a clear goal—"bring the astronauts home safely"—and the team worked backward from there, prioritizing every action against that single objective. Similarly, a sprint team sets a goal for six months or a year in the future. Then, they list all the "sprint questions"—the assumptions and obstacles that could cause the project to fail.

With the goal set, the team creates a map of the customer's journey. This simple diagram, with just a few words and arrows, visualizes how a customer interacts with the product or service. The team then interviews internal experts to refine the map and uses a technique called "How Might We" to reframe problems as opportunities. By Tuesday, the focus shifts from problems to solutions. But instead of a chaotic group brainstorm, the sprint uses a method called "work alone, together." Each person individually sketches detailed solutions. This avoids groupthink and allows for a wider range of ideas to emerge. The Blue Bottle Coffee team used this process to tackle their new website. Their sketches led to the crucial insight that customers didn't want to choose coffee by region, but by a much simpler question their baristas already used: "How do you make coffee at home?"

Wednesday: Deciding Without Debate

Key Insight 3

Narrator: Wednesday morning is for making decisions, but it’s designed to be "unnatural but efficient." To avoid endless debates and sales pitches, the team uses a five-step process called the "Sticky Decision." First, all the solution sketches from Tuesday are taped to the wall, creating an "Art Museum." The team then silently reviews them and uses dot stickers to create a "Heat Map," marking interesting ideas without discussion. This captures everyone's initial, unbiased reactions.

Next comes the "Speed Critique," where the facilitator leads a three-minute discussion of each sketch, focusing on the ideas highlighted by the heat map. The creator of the sketch remains silent until the end, preventing them from influencing the critique. After all sketches are discussed, the team holds a "Straw Poll," where each person silently places a single dot on the solution they believe is the strongest. Finally, the Decider makes the ultimate choice. They are given three "supervotes" and can place them on any idea, regardless of the straw poll's outcome. This structured process allowed the team at Slack to evaluate a dozen different approaches for explaining their product and commit to a clear plan for their prototype in just a few hours.

Thursday: The Power of the Realistic Façade

Key Insight 4

Narrator: Thursday is dedicated to building a prototype, but the key is to adopt the "Prototype Mindset." The authors compare this to an Old West movie set—from the front, it looks like a real town, but it’s just a façade. The goal of a sprint prototype is the same: to create a realistic surface that customers can react to, not a fully functional product. This façade must have "Goldilocks quality"—not so flimsy that it breaks the illusion, but not so polished that it takes more than a day to build.

This mindset frees the team to be creative. For example, the team at FitStar wanted to test a new version of their fitness app that featured personalized coaching from NFL star Tony Gonzalez. They didn't have time to code a new app, so they faked it. Using Keynote, they created realistic-looking app screens. When it came time for the coaching videos, the CEO simply stood in for Tony Gonzalez and recorded the lines himself. The result was a clickable prototype, built in just seven hours, that looked and felt real enough to test with customers the next day.

Friday: Learning from Just Five Customers

Key Insight 5

Narrator: The entire week culminates on Friday, the day of the test. The team interviews five target customers, one at a time. The authors cite research from usability expert Jakob Nielsen, which shows that five users will reveal about 85% of the core problems in a product. After five, you see the same patterns repeated. The interviews follow a structured, five-act script that makes the customer comfortable, gathers context, and elicits honest reactions to the prototype.

The entire sprint team watches the interviews together from a separate room via a live video feed. This shared experience is critical, as it allows the team to see patterns emerge in real time. This is exactly what happened with the Savioke robot team. During their Friday tests, they watched as guest after guest reacted with delight to the robot's simple face and sounds. When the robot completed its delivery and did a little "happy dance," the reaction was overwhelmingly positive. One guest even said, "If they start using this robot, I’ll stay here every time." In just five days, Savioke had gone from a state of uncertainty to a clear, validated answer. The robot needed a personality, and the happy dance was a hit.

Conclusion

Narrator: The single most important takeaway from Sprint is that it gives teams a superpower: the ability to fast-forward into the future. It replaces the endless cycle of debate, speculation, and slow development with a compressed process that delivers tangible evidence. In one week, a team can see how customers will react to their finished idea, long before they commit the immense resources required to build it. Whether the prototype is a "flawed success" or an "efficient failure," the sprint is always a win because it provides clarity. The real-world impact of this methodology is a fundamental shift in how teams approach work—moving from abstract arguments to concrete data. It leaves us with a powerful challenge: what critical, high-stakes question could you answer if you had a time machine to see the future? With a sprint, you essentially do.

00:00/00:00