Pulse ← Library
Reviews and Expert Analysis · book-summary

Sprint by Jake Knapp — Cliff Notes Summary for B2B Sales

👁 0 views📖 3,127 words⏱ 14 min read5/31/2026

Direct Answer

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp with John Zeratsky and Braden Kowitz (Simon & Schuster, 2016) is the operating manual for the GV Design Sprint — a tightly choreographed five-day process that compresses months of strategy debate, design exploration, prototyping, and customer validation into one calendar week.

Knapp ran the original sprint at Google in 2010, refined it across 100+ engagements at Google Ventures with portfolio companies (Slack, Nest, Blue Bottle, 23andMe, Flatiron Health), and proved the format produced better answers than the multi-month process it replaced. The book's central claim: "compress months of debate into one week of decisions" — Monday maps the problem, Tuesday sketches solutions, Wednesday picks one, Thursday builds a realistic-but-fake prototype, Friday tests it with five real customers.

The method is foundational in modern product and UX circles but criminally underused in B2B sales and RevOps, despite mapping cleanly onto sales-motion redesign, pricing tests, and stalled-deal post-mortems — exactly the discovery-and-validation discipline Teresa Torres (bs0193) and Clayton Christensen (bs0200) argue every modern revenue team needs.

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

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

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

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

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)

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

flowchart TD A[Monday: Map] --> B[Long-Term Goal + Sprint Questions] B --> C[Customer Journey Map] C --> D[Ask the Experts + How Might We] D --> E[Tuesday: Sketch] E --> F[Critique + Remix Existing] F --> G[Crazy 8s + Solution Sketch] G --> H[Wednesday: Decide] H --> I[Art Museum + Heat Map] I --> J[Speed Critique + Straw Poll] J --> K{Decider Supervote} K --> L[15-Panel Storyboard] L --> M[Thursday: Prototype] M --> N[Goldilocks Facade Build] N --> O[Trial Run at 4pm] O --> P[Friday: Test] P --> Q[Five 1-on-1 Customer Interviews] Q --> R[Pattern Review] R --> S{Outcome} S -->|Epic Win| T[Build for Real] S -->|Flawed Success| U[Second Sprint] S -->|Efficient Failure| V[Kill or Pivot]

8. Frameworks at a Glance

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

flowchart LR A[Long-Term Goal] --> B[Sprint Question] B --> C[Map + Experts] C --> D[Sketch + Crazy 8s] D --> E[Decider Supervote] E --> F[Goldilocks Prototype] F --> G[5 Customer Tests] G --> H[Pattern Synthesis] H --> I[Ship / Iterate / Kill]

9. What Holds Up, What Has Aged

What still holds (2026-2027):

What has aged:

FAQ

How does this apply to B2B sales and RevOps, not just product? Three direct applications. Sales Motion Sprint — five-day compressed redesign of a struggling sales motion (Monday maps the buyer journey, Friday tests new positioning with five real prospects). Customer Sprint — five-day compressed analysis of a stalled deal, with the Decider being the account exec or CRO.

Pricing Sprint — five days to test a pricing page or packaging change with five live prospects. Modern PLG companies (Linear, Vercel, Notion) run quarterly RevOps sprints on these exact templates.

Do you really need the Decider in the room every day? Yes — and this is the most-violated rule. Knapp documents sprint after sprint where the Decider tried to delegate to a deputy "for most of the week" and the team's decisions had to be redone when the Decider returned. The asynchronous approval is the source of the multi-month-decision-cycle the sprint exists to kill.

If your Decider can't commit five days, postpone the sprint.

Can you run a Design Sprint remotely? Yes — Knapp and Zeratsky published the Remote Sprint adaptation in 2020, and the community standardized on a Miro-board-plus-Zoom format with shorter days and async sketch time. The core protocol survives intact; the energy is lower and you have to be more disciplined about facilitator pacing.

How is this different from Lean Startup or continuous discovery? Lean Startup (Eric Ries, 2011) prescribes the build-measure-learn loop as a continuous operating mode. Continuous Discovery (Teresa Torres, 2021, bs0193) prescribes weekly customer touchpoints as a perpetual habit.

The Sprint is a discrete five-day intervention you deploy when a specific big question needs a fast answer — not the permanent operating system, but the in-case-of-emergency-break-glass tool. Mature teams use all three.

Has AI replaced the need for a prototype day? No — AI has compressed it. The prototype must still exist, the trial run still has to happen Thursday evening, and the customer still has to interact with a believable facade Friday. What changed is the build time — ChatGPT and Claude generate copy in seconds, v0 and Replit Agent stand up clickable apps in under an hour, Figma AI assembles screens from prompts.

Thursday went from eight hours to two; the methodology around it is unchanged.

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.

Sources

Keep reading
Download:
Was this helpful?  
⌬ Apply this in PULSE
Gross Profit CalculatorModel margin per deal, per rep, per territory
Related in the library
More from the library
book-summary · cliff-notesThe Mom Test by Rob Fitzpatrick — Cliff Notes Summarybook-summary · cliff-notesBuyer-First by Carole Mahoney — Cliff Notes Summarybook-summary · cliff-notesLOVED by Martina Lauchengco — Cliff Notes Summarybook-summary · cliff-notesPitch Perfect by Bill McGowan — Cliff Notes Summarybook-summary · cliff-notesBargaining for Advantage by G. Richard Shell — Cliff Notes Summarybook-summary · cliff-notesEnchantment by Guy Kawasaki — Cliff Notes Summarybook-summary · cliff-notesReality Check by Guy Kawasaki — Cliff Notes Summarybook-summary · cliff-notesThe Brain Audit by Sean D'Souza — Cliff Notes Summarybook-summary · cliff-notesPre-Suasion by Robert Cialdini — Cliff Notes Summary & Key Takeawaysbook-summary · cliff-notesThe 4 Disciplines of Execution by McChesney, Covey, Huling — Cliff Notes Summarybook-summary · cliff-notesHow to Become a Rainmaker by Jeffrey Fox — Cliff Notes Summarybook-summary · cliff-notesSandler Enterprise Selling by Mattson and Sullivan — Cliff Notes Summarybook-summary · cliff-notesCrucial Conversations by Patterson, Grenny, McMillan, Switzler — Cliff Notes Summary