Sprint

Challenge

A sprint starts by naming a long-term goal, where the team wants this project to be in six months or two years, stated as a real ambition, not a vague hope. From there the team lists sprint questions: the specific things that have to be true, or the risks that could kill the idea, turned into questions the week is meant to answer.

Throughout the week, anyone can write a How Might We note on a sticky note the moment a concern or an opportunity crosses their mind, then post it on a wall. By Monday afternoon these get sorted and organized, turning scattered worries into a shared, visible list the team actually works from.

The team also names a target customer and target moment on Monday, one specific type of person at one specific point in their experience, since a sprint aimed at everyone and everything never converges on a testable prototype by Thursday.

This backward framing borrows from Amazon's practice of writing a press release before building a product: naming the win first makes it far easier to spot, mid-week, whether a proposed solution actually serves the goal or is just an interesting idea drifting away from it.

The chapter-specific lesson: the next time your team kicks off a project with a feature list instead of a long-term goal and the real risks to it, stop and write the goal and the risky questions first. A feature list without them is a plan with no way to know if it actually worked.

Team

A sprint team stays small, seven people or fewer, and cross-functional: someone from marketing, sales, or customer support sits next to the designer and engineer, since the people closest to customer complaints often spot the real risk fastest. One person, the Decider, holds final authority, usually a founder, CEO, or the product's owner.

Decisions made in the room without the Decider present tend to get quietly relitigated afterward, once the real decision-maker finally sees the work and disagrees. Having them in the room all week, not just for a final readout, is what actually makes Wednesday's choice stick through Thursday and Friday.

A useful sprint team usually includes a Facilitator role too, someone trained to run the schedule and keep exercises on time, distinct from the Decider, since running the room and making the final call are different jobs that shouldn't sit with the same overloaded person.

Getting the right seven people in the room is itself worth protecting on the calendar. A sprint with the wrong Decider, or missing the one engineer who actually knows the technical constraint, produces a confident answer to the wrong question just as easily as no sprint at all.

The chapter-specific lesson: before your next big product decision meeting, check whether the person who can actually override it later is in the room. If they're not, you're not deciding, you're proposing, and the real decision is still ahead of you.

Time and Space

A sprint claims five full, protected days, ten to five, in one dedicated room with whiteboard walls and no laptops or phones allowed during working hours, a rule enforced as strictly as the schedule itself. A trained facilitator runs the clock, keeps the room on task, and prevents any one voice from dominating.

This isn't about discipline for its own sake. A team that lets the sprint compete with regular email and meetings all week never actually leaves its normal thinking mode, and the whole method depends on getting a group to think differently for five straight days.

The room itself matters more than it sounds: whiteboard walls the team can cover in maps, sketches, and sticky notes for five straight days, left up and visible rather than erased between sessions, so Wednesday's decision can still see Monday's map on the wall.

Even small environmental choices compound over five days: fixed seating so people sit next to different collaborators than usual, snacks and coffee available without leaving the room, and a visible countdown clock, all designed to keep the group's energy and focus from quietly draining by Wednesday afternoon.

The chapter-specific lesson: the next time you block time for deep team work, protect it the way a sprint does, no laptops, no parallel meetings, a dedicated room, not just a calendar hold that everyone quietly works around.

Start at the End

Sprint teams work backward from an ending instead of forward from a feature list, because starting with the ending forces everyone to agree on what success actually looks like before arguing about how to get there. The long-term goal answers where the team wants to be; sprint questions name what has to be true to get there, or what could stop it.

Writing sprint questions as literal questions, not statements, matters more than it seems. A statement like "users don't trust our pricing" invites debate about whether it's true. A question like "can we make our pricing feel trustworthy enough that users complete checkout" gives the week something concrete to actually test.

A useful check on a sprint question: could a real customer conversation on Friday actually answer it. A question too abstract to test that way, however important it sounds, isn't ready to drive the week yet and needs to be narrowed further before Monday ends.

Framing risk as a question also changes how failure gets discussed afterward. A sprint that answers "no, customers don't trust this pricing" hasn't failed, it has directly resolved the sprint question it set out to test, which a vague statement of concern could never have delivered so cleanly.

The chapter-specific lesson: before your next big initiative starts, write its sprint questions as literal questions, not assumptions stated as fact. A question the team can test in five days is worth more than a confident statement nobody has actually checked.

Map

The map is a simple diagram of the customer's actual journey, actors on the left, a sequence of steps as boxes connected by arrows moving toward a goal on the right, kept to somewhere between five and fifteen steps. It becomes the sprint's shared model of the problem, referenced constantly for the rest of the week.

Drawing it together, out loud, surfaces disagreements about the problem itself before the team ever starts sketching solutions, since two people who think they agree on "the problem" often discover they've been picturing completely different journeys once it's actually on the wall.

A map that's too detailed defeats its own purpose. Twenty or thirty granular steps overwhelm the room and make Monday's target-picking harder, not easier; the goal is a map simple enough that everyone can hold the whole customer journey in their head at once.

A good map also reveals where the team has been quietly assuming agreement without ever actually checking it. Two people who each believe they understand "the checkout flow" often draw noticeably different boxes the first time they're forced to put it on the wall together.

The chapter-specific lesson: the next time your team debates a solution without agreement on the underlying journey, stop and map the actual steps a customer takes first. A shared map turns a solution debate into a much shorter conversation about where on the map to focus.

Ask the Experts

Monday afternoon brings in a short series of experts, internal specialists, customer-facing staff, occasionally an outside authority, each interviewed in front of the whole team for around thirty minutes rather than in separate one-on-ones. The team listens together so everyone hears the same context instead of getting it secondhand.

As each expert talks, team members write How Might We notes capturing anything useful: a risk, an opportunity, a fact that reframes the problem. These get posted to the wall in real time, then sorted onto the map from Chapter 5 by the end of the day.

Choosing which experts to interview is itself a real decision worth taking seriously: a sales lead who hears objections daily, a support lead who reads every complaint, an engineer who knows exactly where the technical constraints actually are, not just whoever's available that afternoon.

Expert interviews often surface information nobody thought to write down anywhere, the kind of tacit, operational knowledge that lives only in one person's head. Getting it onto sticky notes in front of the whole team turns a single person's private expertise into shared team knowledge in thirty minutes.

The chapter-specific lesson: the next time you'd normally interview a subject-matter expert one-on-one and write up notes afterward, bring the whole team into that conversation instead. What gets lost translating one person's notes into a summary is often the exact detail that mattered most.

Target

At the end of Monday, the Decider picks one target: a specific customer type and a specific moment in the map from Chapter 5, the one place the whole team will focus its energy for the rest of the week. Trying to solve for every customer and every step dilutes a five-day sprint into nothing usable.

The target doesn't need consensus, it needs a decision. Debating every stakeholder's favorite step can burn the whole week; the Decider hears the arguments, then picks, and the team moves forward together on one target instead of arguing indefinitely about which one deserves it.

Choosing a narrow target also protects the rest of the week from scope creep. Once Monday ends with one customer and one moment locked in, Tuesday's sketches, Wednesday's decision, and Thursday's prototype all have one clear, shared job instead of quietly drifting toward whichever idea feels most exciting that day.

Picking a narrow target doesn't waste the rest of the map. Everything not chosen this week stays on the wall, a visible record of what the team consciously deferred, ready to become next sprint's target instead of being forgotten the moment Monday ends.

The chapter-specific lesson: the next time your team's roadmap tries to serve every customer segment at once, force a single target the way Monday does: one customer, one moment, chosen deliberately by whoever actually owns the call, not by exhaustive consensus.

Remix and Improve

Tuesday morning starts by remixing, not inventing. The team reviews existing good ideas, from competitors, from other industries, from the company's own past work, through Lightning Demos: three-minute walkthroughs of any relevant product, each ending with the presenter sketching the specific part worth stealing directly on the whiteboard.

This deliberately lowers the bar for a Tuesday idea to just be good, not original. A team searching for a completely novel concept from scratch usually spends the morning stuck; a team hunting for the best parts of things that already work spends the morning generating real, usable material.

Lightning Demos work because they're bounded, three minutes each, forcing presenters to isolate the one specific detail worth borrowing instead of narrating an entire competitor's product. A vague "look how good their onboarding is" doesn't survive a three-minute clock; a specific sketchable detail does.

Recording each Lightning Demo's key sketch directly on the whiteboard, not just discussing it verbally, matters more than it seems. A verbal description of a good idea fades from memory within an hour; a rough sketch on the wall stays available for Tuesday afternoon's individual sketching to actually build on.

The chapter-specific lesson: the next time your team is stuck brainstorming from a blank page, run a round of Lightning Demos on existing products first, even ones outside your category. The fastest ideas usually come from noticing what already works somewhere else, not from pure invention.

Sketch

Tuesday afternoon's sketching happens alone, not in a group, through a four-step method: Notes (rereading everything on the walls and jotting anything useful), Ideas (rough doodles of possible directions), Crazy 8s (folding a page into eight panels and sketching eight variations of the strongest idea in eight minutes), and a Solution Sketch, a detailed, self-explanatory three-panel storyboard.

Solution Sketches stay anonymous and get reviewed without live discussion the next morning, which removes the social pressure that makes group brainstorms default to whoever's loudest or most senior. A quiet engineer's sketch gets judged purely on the idea, not on who drew it.

Crazy 8s specifically forces speed: eight variations of one idea in eight minutes leaves no time for a sketch to become precious. Team members who'd normally freeze up trying to draw one perfect concept instead generate eight rough ones, and the best version is often the fifth or sixth, not the first.

Working alone before comparing notes also protects introverted or junior team members from being talked over in a live brainstorm. A quiet engineer's solution sketch gets exactly the same wall space and the same anonymous review as the loudest executive's, judged purely on the idea itself.

The chapter-specific lesson: the next time your team brainstorms out loud in a group and gets the same three obvious ideas every time, try silent, individual sketching instead. Working alone first, then comparing results, usually surfaces sharper, more varied ideas than a live discussion does.

Decide

Wednesday morning runs a structured, mostly silent critique called the Sticky Decision, five steps in sequence: Art Museum (taping every sketch to the wall), Heat Map (silently marking interesting parts with dot stickers), Speed Critique (a few minutes per sketch naming its standout idea aloud), Straw Poll (each person votes for one favorite), and Supervote, the Decider's final call.

Keeping most of this silent and structured is deliberate. A normal group critique tends to be dominated by whoever speaks first or most confidently; a silent heat map and an individual straw poll surface what the whole room actually finds compelling before anyone's opinion can anchor the discussion.

The Speed Critique step deliberately limits discussion to naming the one standout idea in each sketch, not debating its merits. Longer discussion at this stage tends to just replay Tuesday's individual opinions out loud, which is exactly what the silent Heat Map step already captured more honestly.

The Decider's supervote doesn't have to pick a single sketch outright. It can combine the strongest elements from two or three different sketches into one composite direction, as long as that composite gets drawn out clearly enough that Wednesday afternoon's storyboard has one coherent thing to actually build from.

The chapter-specific lesson: the next time your team reviews competing ideas in an open discussion, try a silent dot-vote first, before any verbal debate. What the room actually gravitates to, marked quietly and individually, is often different from what the loudest voice argues for.

Rumble

When the Decider genuinely can't choose between two strong, competing sketches, the sprint doesn't force a premature pick, it runs a rumble: building and testing both directions in parallel through Thursday and Friday, and letting real customer reactions settle the disagreement instead of another round of internal debate.

This only works because a sprint's prototypes are fast and cheap. Testing two directions doubles the prototyping effort for one day, not the multi-week cost a real product decision usually carries, which is exactly why the method can afford to let evidence decide instead of forcing an early, poorly informed choice.

A rumble isn't the default outcome, and the book treats it as a fallback, not a strategy. Running two prototypes doubles Thursday's workload and complicates Friday's five interviews, since each customer now needs to react to two different directions instead of one clean comparison.

A rumble also produces a genuine byproduct beyond resolving the disagreement: real, comparative customer data about two live alternatives, which is a far stronger foundation for the next quarter's roadmap than either sketch would have been evaluated alone, on its own, without anything to measure it against.

The chapter-specific lesson: the next time your team is stuck deadlocked between two genuinely strong options, ask whether you could cheaply test both instead of debating harder. A real rumble, however small, is often faster and more honest than one more meeting trying to argue someone into agreement.

Storyboard

Wednesday afternoon turns the winning sketch, or sketches from a rumble, into a storyboard: roughly fifteen panels laid out in sequence, starting from how the customer first encounters the product and walking through every screen and action in order, drawn as a comic strip on the whiteboard.

The storyboard exists to remove ambiguity before Thursday's building starts. A sketch shows a good idea; a storyboard shows exactly what happens, in what order, which is what turns an inspiring concept into something a small team can actually build in one day without stopping to debate the sequence.

Storyboarding as a full team, not by one designer alone, also surfaces gaps early: a step someone assumed was obvious turns out to need its own panel once the group actually tries to draw the sequence out loud, panel by panel, on the board.

A completed storyboard also becomes the week's most useful communication tool afterward. Showing a stakeholder fifteen clear panels of what the team tested is a far more convincing artifact than describing the idea verbally, since it shows exactly what customers reacted to, panel by panel, not just the concept in the abstract.

The chapter-specific lesson: before your next team starts building anything from an approved concept, check whether the sequence of screens or steps is actually nailed down, panel by panel, or just implied. An unstoryboarded idea always costs more time in mid-build arguments than the storyboard would have taken to draw.

Fake It

Thursday's building philosophy is blunt: fake it. The goal isn't a working product, it's something that looks and feels real enough to get an honest reaction from a real customer on Friday, built in a single day using whatever shortcuts get there fastest, a slide deck standing in for a live interface, scripted responses standing in for real backend logic.

Quality has a specific target here, nicknamed Goldilocks quality: too rough and customers can't react honestly because it clearly isn't real; too polished and the team wastes the one day they had, chasing details nobody needed answered yet. The right level looks finished on the surface and is empty underneath.

The Wizard of Oz technique often does the heaviest lifting here: a team member manually triggers responses behind the scenes, a message, a calculation, a screen change, so the customer experiences something that reacts convincingly without any of the real logic actually existing yet.

Thursday's fakery has a hard boundary worth naming: it only works because Friday's customers never actually use the product afterward. A prototype that looks real but does nothing is a legitimate research tool for one interview; shipped to real, paying customers under the same false pretense, it would just be a broken product.

The chapter-specific lesson: the next time your team debates how polished a test artifact needs to be, ask what specific question Friday's customers need to answer, then build only what's needed to ask that question honestly. Anything beyond that is Thursday time spent on the wrong kind of quality.

Prototype

Building a Thursday prototype works best with clear roles: a Stitcher assembling the pieces into one coherent flow, a Writer handling all the text and copy, an Asset Collector sourcing images and other material, and someone lined up to run Friday's interviews, so nobody is improvising their part mid-afternoon under time pressure.

The prototyping tool matters less than picking one scoped to finish in a day: a slide deck or a simple prototyping tool for a screen-based product, a printed script for a phone-based service, a physical mockup for something tangible. The team builds only the front the customer will actually see and touch.

Data used inside the prototype matters more than it seems. Real-sounding names, prices, and content make a fake interface feel trustworthy to a customer; obviously placeholder text like "Lorem ipsum" or "Test User" breaks the illusion and quietly changes how honestly people react to it.

Keeping the prototyping team small and focused on one clear storyboard also prevents the classic Thursday failure mode: scope creep, where someone tries to sneak in "just one more screen" mid-afternoon and the whole team runs out of time to finish the one flow that Friday's interviews actually need to test.

The chapter-specific lesson: the next time your team scopes a quick test, assign the same explicit roles a Thursday build uses, someone owns the flow, someone owns the words, someone owns the assets, rather than leaving it as one shared task everyone assumes someone else is handling.

Small Data

Friday tests the prototype with five customers, a number chosen deliberately, not out of laziness. Research on usability testing shows five users reveal the large majority of a design's real problems; a sixth, seventh, and eighth interview mostly repeat what the first five already surfaced, at steeply diminishing return.

A sprint isn't trying to produce statistically significant data, it's trying to spot big, obvious patterns fast enough to act on this week. Five focused interviews, watched together by the whole team, deliver that faster and cheaper than a larger, slower study aimed at a level of certainty the sprint doesn't actually need yet.

This same five-user logic, borrowed from Jakob Nielsen's usability research, applies inside a single day too: watching customer three react almost identically to customer one is usually the moment a team stops needing to be convinced and starts trusting the pattern.

Five is a floor, not a hard ceiling. A sprint testing two directions from a rumble often runs five interviews per direction, ten total, rather than splitting five interviews across two prototypes and diluting the sample each direction actually gets tested against.

The chapter-specific lesson: the next time your team delays a decision waiting for a bigger sample size, ask whether five well-run interviews would already show the pattern clearly. Waiting for statistical certainty on a question five conversations could already answer directionally is often just expensive procrastination.

Interview

Each Friday interview follows a five-act script: a friendly welcome to put the customer at ease, general context questions about their life and habits, an introduction to the prototype framed as something unfinished, tasks that nudge them to explore it while thinking out loud, and a quick debrief at the end.

One interviewer runs all five conversations, keeping the questions consistent, while the rest of the team watches live from another room, taking notes independently rather than discussing impressions in real time, which keeps one person's early reaction from quietly shaping what everyone else notices.

The interviewer deliberately avoids leading language throughout, asking "what do you make of this" rather than "do you like this," since even a slight change in phrasing measurably shifts how polite, rather than honest, a customer's answer turns out to be.

The one-way mirror or video link isn't just logistics, it changes the interview itself. A customer who knows a room full of the product's actual builders is watching live tends to answer more politely; a customer who only sees one interviewer speaks far more honestly about what's actually confusing or off-putting.

The chapter-specific lesson: the next time you run user interviews, have one skilled interviewer conduct all of them rather than splitting the sessions across different people. Consistency in how the questions get asked matters more for spotting real patterns than dividing up the workload evenly.

Learn

After the five interviews, the whole team builds a shared Learnings Matrix together: customers as rows, key parts of the prototype as columns, each cell marked with a quick positive, negative, or neutral reaction pulled straight from the team's independent notes, not from memory or a single person's summary.

Filling the grid out loud, comparing notes cell by cell, is what turns five separate impressions into one shared, visible pattern the whole team actually agrees they saw, rather than five people leaving the room with five different stories about what happened.

A pattern showing up in only one or two of the five interviews gets flagged, not ignored, but treated with real caution rather than driving a big decision. Small samples still teach directional lessons; they just don't earn the same confidence a five-for-five pattern does.

The Friday debrief deliberately happens the same day as the interviews, not the following Monday. Waiting even a weekend lets memory soften sharp, specific reactions into vaguer, kinder summaries, which is exactly the drift a same-day Learnings Matrix, built from fresh notes, is designed to prevent.

The chapter-specific lesson: the next time your team wraps up a round of user testing, build a shared matrix like this together instead of asking each person for their individual takeaways afterward. A pattern the whole team built together survives contact with a stakeholder meeting far better than one person's paraphrase does.

Liftoff

A sprint's real output was never a finished product, it was fast, cheap, directional evidence about whether an idea is worth pursuing at all, in five days instead of the months a normal build-and-launch cycle would take to deliver the same answer.

That evidence lets a team do something a normal roadmap rarely allows: kill a bad direction cheaply, before it consumes a quarter of real engineering time, or double down on a promising one with actual customer reactions behind it instead of internal conviction alone.

Jake Knapp and his co-authors ran this exact process at Google Ventures with dozens of portfolio companies, including Blue Bottle Coffee's homepage redesign and Slack's marketing overhaul, before writing it down as a repeatable method any team could run without a facilitator flying in from Google.

A sprint doesn't replace the normal product development process that follows it, building, shipping, iterating, it just makes sure that process starts from a direction the team has real evidence for, rather than from five months of confident internal debate about which idea seemed best in a conference room.

The chapter-specific lesson: the next time your team is about to commit a full quarter to an untested direction, ask whether a five-day sprint could get you real customer evidence first. A week spent finding out you're wrong is far cheaper than a quarter spent finding out the same thing.

The Entire Book in One Framework

Every day of the sprint solves a different failure mode that normally kills product decisions. Monday replaces vague ambition with a specific target. Tuesday replaces groupthink with individual, considered sketches. Wednesday replaces endless debate with a structured, mostly silent decision process. Thursday replaces months of building with one day of faking it convincingly. Friday replaces internal opinion with five real customer reactions.

None of these days work in isolation. A sharp Monday target with no real prototype to test it against is just a well-organized guess. A brilliant Thursday prototype built on a fuzzy, undecided Wednesday direction is polished evidence for the wrong question.

The point of a sprint was never speed for its own sake. It was replacing five months of confident guessing with five days of getting an honest answer from a real customer.

10 Most Important Takeaways

• Start with a long-term goal and a list of sprint questions, the specific risks worth testing, not a feature list.
• Keep the team to seven people or fewer, cross-functional, with one named Decider actually in the room all week.
• Protect five full, uninterrupted days in one dedicated room, no laptops, no parallel meetings.
• Map the customer's actual journey together before debating any solution, then pick one narrow target customer and moment.
• Sketch solutions alone, not in a group brainstorm, using Crazy 8s and a detailed Solution Sketch, then review them anonymously.
• Decide through a structured, mostly silent process, Art Museum, Heat Map, Speed Critique, Straw Poll, Supervote, not an open debate.
• If the team genuinely can't choose between two strong directions, test both in a rumble instead of forcing a premature pick.
• Build a prototype that only needs to look real for one day, not actually work, at deliberate Goldilocks quality.
• Test with five real customers, one interviewer, the rest of the team watching and taking independent notes.
• Build a shared Learnings Matrix the same day as the interviews to turn five impressions into one visible, trusted pattern.

The single deepest idea in the book is that most product teams don't actually disagree about facts, they disagree because nobody has gone and gotten the facts yet, and a five-day sprint is simply a fast, disciplined way to go get them before committing months to a guess.