Sprint by Jake Knapp — Cliff Notes Summary for B2B Sales

1. Part One — The Setup (Pre-Sprint and Monday)

Part One — The Setup (Pre-Sprint and Monday)

1.1 Chapter 1 — The Challenge (Why Sprints Exist)

Knapp opens with his own origin story: at Google in 2009 he was running design reviews on Gmail features and noticing that the highest-quality decisions emerged from a specific kind of meeting — small group, hard deadline, prototype on the table, real user feedback within a week. He started formalizing the pattern and named it the Design Sprint. When he joined Google Ventures in 2012, he ran the sprint with portfolio companies whose runway was measured in months, not years. The constraint forced the method: a startup cannot afford a six-month research-build-test cycle. The book's thesis crystallizes here — most product, UX, and strategy decisions take months of meetings, builds, and market testing; the sprint compresses that into one week with a working prototype and real customer feedback by Friday afternoon.

1.2 Chapter 2 — Set the Stage (People, Place, Time)

Before Monday begins, the sprint organizer locks down three things. People: seven participants maximum — a small enough room that everyone contributes, large enough to cover the disciplines (design, engineering, marketing, customer, finance). One seat is reserved for The Decider — the single person with decision authority over the problem. Place: one room, one week, no laptops in the room except for specific moments. Two whiteboards. Sticky notes, sharpies, dot stickers, a timer. Time: five consecutive days, 10am–5pm, with the Decider present every day. The non-negotiable: "The Decider must be in the room — no asynchronous approvals." Without that authority physically present, every decision becomes provisional and the week collapses into another round of meetings.

2. Part Two — Monday: Map

Part Two — Monday: Map

2.1 Chapter 3 — Start at the End (Long-Term Goal + Sprint Questions)

Monday begins by writing the long-term goal on the whiteboard — the optimistic, two-year aspiration ("Make banking simple enough that anyone can open an account in five minutes"). Then the team writes sprint questions — the assumptions that have to be true for the long-term goal to hold ("Can customers verify their identity without a branch visit? Will they trust us with their primary checking?"). The exercise inverts the normal product-meeting energy from optimistic ("we'll figure it out") to skeptical ("here is what could kill this"). Knapp's instruction: list every fear out loud, write it as a question, choose the one the sprint will answer.

2.2 Chapter 4 — Map the Customer Journey

The team draws a map of the customer journey from first awareness to outcome — a left-to-right flow of actors on the left, end goal on the right, the customer's path connecting them. The map is deliberately ugly and simple — six to fifteen steps, hand-drawn, on the whiteboard for the rest of the week. The map is the artifact the team refers back to every time a decision is debated. In a B2B context the map would run Buyer Awareness → Discovery → Demo → Champion Sells Internally → Procurement → Signature → Onboarding → First Value — exactly the sales-motion stages a RevOps team needs to redesign.

2.3 Chapter 5 — Ask the Experts (Lightning Demos and How Might We)

The afternoon is expert interviews — 30-minute one-on-ones with the people who know parts of the problem (the CEO, the lead engineer, the customer-success lead, an actual customer if reachable). While experts talk, the rest of the team writes "How Might We" notes — one observation or opportunity per sticky note, phrased as an opening question ("How might we let the customer verify ID in under two minutes?"). At end of day the team clusters the How Might We notes by theme, heat-map votes with dot stickers, and the Decider casts two supervotes that anchor where Tuesday's solutions will focus. Mixed in: lightning demos — three-minute show-and-tells of solutions that already exist in adjacent industries, mined for ideas to remix.

3. Part Three — Tuesday: Sketch

Part Three — Tuesday: Sketch

3.1 Chapter 6 — Remix and Improve (Critique Before Create)

Tuesday morning the team studies existing solutions — competitors, analogous products, prior internal attempts. The instruction is explicit: do not invent from scratch — remix. Each participant captures three to four notes on what works in each example. The point is to load the team's brain with raw material before asking it to produce. Knapp argues this is where most ideation workshops fail — they ask people to "be creative" with an empty whiteboard, and the room produces shallow ideas. Sprints front-load inspiration, then ask for synthesis.

3.2 Chapter 7 — Crazy 8s and the Solution Sketch

Tuesday afternoon is the sketch session — the most distinctive part of the sprint and the part that most participants initially resist. It runs in four stages.

1. Notes (20 minutes) — re-read the morning's notes and the map; write down anything that strikes you.
2. Ideas (20 minutes) — rough doodles, anything goes, just generate.
3. Crazy 8s (8 minutes) — fold a sheet of paper into eight panels and sketch eight variations of the same idea in eight minutes. The exercise forces past the first-idea anchor — sketches 5, 6, 7, 8 are where the unexpected angles surface.
4. Solution Sketch (30 minutes) — each person produces a three-panel storyboard of the single best idea, detailed enough that a stranger could understand it. Anonymous — no names on the sketches. Self-explanatory — no presenter standing next to it on Wednesday to defend it. The artifact has to speak for itself.

4. Part Four — Wednesday: Decide

Part Four — Wednesday: Decide

4.1 Chapter 8 — The Art Museum (Gallery Walk + Heat Map)

Wednesday opens with the art museum — every solution sketch is taped to the wall like an exhibition. The team walks silently with sheets of dot stickers and heat-map votes every interesting element — not the whole sketch, just the specific panels, ideas, headlines, mechanics that resonate. The heat map produces a visible map of where attention concentrates without any verbal advocacy.

4.2 Chapter 9 — Speed Critique and Straw Poll

Each sketch then gets a three-minute speed critique — a facilitator narrates what the sketch shows, the room calls out standouts the artist confirms or corrects, concerns get recorded on sticky notes. Then a straw poll — every team member casts one vote on the sketch they would test. The straw poll surfaces the team's intuition without committing the decision.

4.3 Chapter 10 — The Supervote (Decider Picks)

The Decider then casts the supervote — one (or several) decisive votes on the sketches that will actually go to prototype. This is the moment the week's structure pays off — instead of a committee compromise, one accountable person picks, in the room, with the entire week's research and the team's straw poll visible behind the decision. Knapp's verbatim instruction: the Decider's vote is the decision — no appeals, no asynchronous override, no follow-up meeting.

4.4 Chapter 11 — Storyboard (Wednesday Afternoon)

The afternoon converts the chosen sketches into a 15-panel storyboard — the exact sequence Friday's prototype will walk a customer through, from first touchpoint to outcome. Each panel is a screen, a moment, a step. Disagreements get resolved by the Decider in real time. By Wednesday at 5pm the team has a literal plan for what Thursday will build.

5. Part Five — Thursday: Prototype

Part Five — Thursday: Prototype

5.1 Chapter 12 — Fake It (Goldilocks Quality)

Thursday's instruction is the most counterintuitive in the book: build a realistic facade, not a real product. Knapp calls this "Goldilocks quality — real enough to fool customers into reacting honestly, fake enough to build in a single day." The prototype must NOT come with a disclaimer ("this is a test, ignore the rough edges") because the disclaimer changes the customer's behavior. But it also cannot be real code, real data, real integrations — those take weeks.

The standard prototype kit (2016): Keynote or PowerPoint for clickable screens, InVision to stitch screens into a flow, Squarespace or a quick HTML page for a marketing-site illusion, fake data hand-typed into spreadsheets, a real-looking domain name. (2026 equivalent: Figma, Framer, Webflow, ChatGPT or Claude to generate copy and code stubs, Replit Agent or v0 to stand up clickable apps in under an hour.)

5.2 Chapter 13 — Divide and Conquer (Thursday's Roles)

The team splits into roles for the day. Makers (two people) build screens. Stitcher (one person) assembles the screens into a single end-to-end flow. Writer (one person) writes every word the customer will read — copy is the prototype's most-used component. Asset Collector (one person) sources logos, images, stock photos, fake names, fake transaction data. Interviewer (the person running Friday's sessions) writes the interview script and confirms the five customers are confirmed for Friday. The trial run at 4pm is non-negotiable — the team clicks through the prototype end-to-end before going home, catching every dead link.

6. Part Six — Friday: Test (and What Happens Next)

Part Six — Friday: Test (and What Happens Next)

6.1 Chapter 14 — Five Customers, One Day

Friday is five 60-minute one-on-one customer interviews, scheduled back-to-back with breaks. The number five is empirically tuned — Knapp cites Jakob Nielsen's research showing that five users surface roughly 85% of usability problems; the sixth through tenth add diminishing returns. The interview format runs five segments: friendly welcome (5 min), context questions (5 min), introduce the prototype (3 min), tasks and observation (40 min) — the customer narrates aloud while using the prototype — and debrief (5 min) — the customer rates and reflects.

6.2 Chapter 15 — Observe and Synthesize

The entire team watches the interviews from a separate room via livestream, taking notes on sticky notes color-coded by interview (Customer 1 = green, Customer 2 = blue, etc.). After all five interviews, the team performs the pattern review — sticky notes go on the wall, clustered by behavior, and the patterns that show up in three or more interviews are real signals. Patterns that show up once are noise. By Friday at 6pm the team has answered the sprint question and produced a clear next step — ship, iterate, pivot, or kill.

6.3 Chapter 16 — Liftoff (What the Sprint Produces)

The output of any sprint is one of three answers. Efficient Failure — the prototype didn't work, but the team learned in five days instead of five months, conserving runway. Flawed Success — the prototype mostly worked but needs a second sprint on specific issues. Epic Win — the prototype worked across all five customers, and the team has conviction to invest engineering time building the real thing. Knapp argues all three outcomes are valuable; the sprint's job is truth, not validation.

7. The Central Sprint Model

The Central Sprint Model

8. Frameworks at a Glance

Frameworks at a Glance

The frameworks that travel directly from the book into modern product, UX, and increasingly RevOps operating systems:

• The Five-Day Sprint Structure (Map / Sketch / Decide / Prototype / Test) — the master template.
• The Decider — the single accountable person whose presence in the room is non-negotiable; the cure for asynchronous-approval bottlenecks.
• How Might We Notes — the question-phrased sticky-note format that converts criticism into opportunity.
• Crazy 8s — eight sketches in eight minutes, the canonical anti-anchoring exercise.
• Solution Sketch — anonymous three-panel storyboard that has to speak for itself.
• Art Museum + Heat Map + Supervote — the decision protocol that replaces consensus-by-committee.
• Goldilocks Quality — real enough to test, fake enough to build in a day.
• Five-Customer Friday — empirically calibrated to Nielsen's 85%-of-issues threshold.

9. What Holds Up, What Has Aged

What Holds Up, What Has Aged

What still holds (2026-2027):

• The compression thesis — one week beats six months — has been replicated thousands of times at modern PLG companies running sprints on pricing pages, onboarding flows, and sales motions.
• The Decider-in-the-room rule remains the single biggest predictor of sprint success vs. failure.
• The Goldilocks-quality principle survives the AI revolution intact — modern prototypes built in Figma, Framer, v0, or Replit Agent still need to be just-real-enough.
• The five-customer empirical rule (Nielsen 1994) continues to hold; modern continuous-discovery practitioners like Teresa Torres validate it weekly.

What has aged:

• The 2016 prototype kit (Keynote + InVision + Squarespace) has been displaced by Figma, ChatGPT, Claude, v0, and Replit Agent — modern teams compress Thursday from eight hours to two.
• The five-people-one-room model strained during 2020 and forced the Remote Sprint adaptation (Knapp and Zeratsky's 2020 update plus the Miro-and-Zoom playbook the community converged on).
• The "single sprint produces a decision" framing has been partially superseded by continuous discovery (Torres, bs0193) — modern product teams run perpetual smaller experiments rather than discrete week-long sprints.
• The book is silent on B2B sales applications — sales-motion design sprints, pricing sprints, and customer (stalled-deal) sprints are a 2020s extension the original book never describes but the method maps onto directly.

FAQ

What is the main goal of a Design Sprint? The main goal is to compress months of debate and decision-making into a single week. By following a structured five-day process, teams can quickly validate or discard ideas without lengthy development cycles.

How does the Sprint method apply to B2B sales specifically? It helps sales teams redesign sales motions, test pricing models, or diagnose stalled deals. The same principles of mapping, sketching, deciding, prototyping, and testing work for revenue challenges, not just product features.

Do I need a full team to run a Sprint? Ideally, you need a small, cross-functional team of 5–7 people, including a decision-maker, a designer, and someone who can build a prototype. If you’re solo, you can adapt the process by focusing on the mapping and testing phases with customer calls.

How much time does a Sprint actually take? The book prescribes five full days, but many B2B teams compress it into three or four half-days spread over two weeks. The key is to maintain the sequence: map, sketch, decide, prototype, test.

What if I don’t have access to real customers for testing? You can test with prospects, existing clients, or even internal stakeholders who match your buyer persona. The goal is to get honest reactions, not a statistically significant sample—five interviews are enough to spot major flaws.

Is the Sprint method still relevant for remote or hybrid teams? Yes, but you’ll need to adapt. Use virtual whiteboards for mapping and sketching, run video calls for decision-making, and share prototypes via links. The core structure remains effective as long as the team stays focused and synchronous.

Bottom Line

Read this book if you have ever sat through a three-month product-strategy debate that ended with another meeting. The Sprint method is the cure for asynchronous-decision rot — it forces the right seven people into one room with one Decider for five days and produces a real customer-tested answer by Friday at 6pm. For RevOps, the underused application is sales-motion redesign — most CROs argue about positioning for two quarters; a Sprint settles it in a week. The Monday-morning takeaway: schedule one sprint this quarter on the question that has been stuck the longest. The framework will pay for itself the first time it kills a six-month bad idea in five days.

Related on PULSE

• [Sprint by Jake Knapp — Cliff Notes Summary for Sellers](/knowledge/bs0194)
• [The Advantage by Patrick Lencioni — Cliff Notes Summary for Sales Leaders](/knowledge/bs0318)
• [Major Account Sales Strategy by Neil Rackham: Summary, Key Lessons, and RevOps Takeaways](/knowledge/bs305)
• [Demand-Side Sales 101 by Bob Moesta: Summary, Key Lessons, and RevOps Takeaways](/knowledge/bs304)
• [Cracking the Sales Management Code by Jason Jordan and Michelle Vazzana: Summary, Key Lessons, and RevOps Takeaways](/knowledge/bs302)
• [Founding Sales by Pete Kazanjy: Summary, Key Lessons, and RevOps Takeaways](/knowledge/bs300)

Sources

• Knapp, Jake with Zeratsky, John and Kowitz, Braden — *Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days* (Simon & Schuster, 2016)
• Knapp, Jake and Zeratsky, John — *Make Time: How to Focus on What Matters Every Day* (Currency, 2018) — the personal-productivity companion
• Knapp, Jake and Zeratsky, John — Remote Design Sprint Guide (GV / The Sprint Book site, 2020)
• Nielsen, Jakob — Why You Only Need to Test with 5 Users (Nielsen Norman Group, 1994/2000) — empirical foundation for Friday's five-customer protocol
• Torres, Teresa — *Continuous Discovery Habits* (Product Talk, 2021) — modern continuous-discovery descendant
• Christensen, Clayton — *Competing Against Luck* (HarperBusiness, 2016) — Jobs to be Done foundation that the Map exercise draws on
• Ries, Eric — *The Lean Startup* (Crown Business, 2011) — build-measure-learn antecedent
• IDEO — Design Thinking Field Guide (IDEO.org, 2015) — the 1990s methodology Sprint compresses
• Stanford d.school — Design Thinking Bootleg (Hasso Plattner Institute of Design at Stanford, 2018) — academic codification of the design-thinking lineage
• Google Ventures (GV) — The Sprint Book Resources Library (thesprintbook.com) — case studies of 100+ portfolio sprints (Slack, Nest, Blue Bottle, 23andMe, Flatiron Health)
• Brown, Tim — *Change by Design* (HarperBusiness, 2009) — IDEO's foundational design-thinking text