← Dossiers > The GV Design Sprint
A complete reference to the five-day method, its evolution, and its limits
Directed by Igor · researched by Claude Opus 4.8
Jake Knapp compressed months of product debate into one week, and a generation of product teams ran with it. The full map: how the five-day Design Sprint works, how it has fractured and evolved since 2016, and what the honest evidence says about when it earns its keep and when it misleads.
This report is a full reference on the Google Ventures (GV) Design Sprint: where it came from, exactly how the classic five-day version runs hour by hour, the reasoning baked into each step, how the method has splintered and evolved over the past decade, and what the honest evidence says about when it works and when it falls apart. The Design Sprint was created by designer Jake Knapp at Google in 2010 and popularized in the 2016 book Sprint, co-written with John Zeratsky and Braden Kowitz, which has since sold more than half a million copies and been adopted by thousands of teams worldwide 1,21. At its core, the method compresses what would normally be months of product debate into a single week, moving a small team from a fuzzy problem on Monday to a realistic prototype tested with five real customers by Friday 2,6. The central findings of this report are these: the sprint is a genuinely powerful decision-making and de-risking tool, but it is a solving tool, not a finding tool, and it inherits real weaknesses around research quality, decision bias, and the seductive illusion that one week of work settles a question for good 11,30,31. The method has not stood still — it has forked into Google’s own six-phase kit, AJ&Smart’s four-day “Design Sprint 2.0,” fully remote variants, and most recently the creators’ own two-day “Foundation Sprint,” a direct response to a world where artificial intelligence makes building cheap and deciding what to build the real bottleneck 3,7,22,26. What follows is the practitioner’s map of all of it, written with both the enthusiasm the method earns and the skepticism it deserves.
The Design Sprint did not begin as a product or a book. It began as one designer’s personal frustration with how knowledge work actually gets done. Jake Knapp came up with the steps in 2010 while he was at Google helping build Gmail and co-founding the video-calling product that became Google Meet 21. The problem he kept running into was familiar to anyone who has sat through a quarter of planning: teams debated endlessly, the loudest or most senior voice usually won, real decisions slipped, and months could pass before anyone learned whether an idea was any good. Knapp’s insight was that the best work he had seen happened under two conditions that office life rarely combined — individuals having focused, uninterrupted time to think alone, and a hard deadline forcing the group to actually finish 2. The sprint was an attempt to manufacture both on purpose.
Knapp began running these structured weeks inside Google on a range of projects, from Google Search to the experimental moonshot lab Google X 4. When he moved to Google Ventures — Alphabet’s venture-capital arm, which invests in and supports startups — he joined two other designers who would become his co-authors and co-developers. Braden Kowitz had founded the GV design team in 2009 and pioneered the then-novel idea of a “design partner” embedded inside a venture firm 1,2. John Zeratsky had been a designer at YouTube, Google, and the startup FeedBurner, which Google acquired in 2007 1,4. Together at GV, the three refined the method across the firm’s portfolio, and by the time Sprint was published they had run the process with more than a hundred companies 4,6. The Wikipedia record of the method’s development also credits GV researcher Michael Margolis, who built much of the customer-testing discipline, and designer Daniel Burka, and notes that the approach was first popularized through a series of blog posts on the widely read GV Library before it ever became a book 20.
It is also worth noting that the customer-testing half of the method had its own precursor. Before the full five-day sprint was codified, the GV team — led on research by Michael Margolis — had developed a separate four-day “research sprint” specifically for answering important startup questions through structured customer interviews, and the testing discipline from that work was folded into the Friday of the combined method 2. This lineage matters because it locates the rigor of the sprint’s testing day in a dedicated research practice rather than in improvisation, and the creators still point teams to that original research-sprint guidance for the details of running Friday’s interviews well 2. The method’s evolution, in other words, was already underway inside GV before the book froze one particular version of it in 2016, which helps explain why so many later variants felt licensed to keep adapting it 2,20.
The Design Sprint was not invented from nothing; it is a deliberate remix of older traditions, which is fitting given that “remix and improve” is one of its own mantras 2. Its most obvious ancestor is design thinking, the human-centered problem-solving tradition associated with the firm IDEO and Stanford’s d.school. Knapp has acknowledged IDEO’s design-thinking workshops as a direct source of inspiration, and the sprint follows the same broad logic of understanding users, generating ideas, prototyping, and testing 5. A second parent is the Lean Startup movement, Eric Ries’s framework built around testing a hypothesis cheaply before committing resources; Ries himself endorsed Sprint as a transformative formula for testing ideas 1. The third influence is Agile software development and its named time-boxes — confusingly also called “sprints” — which established the cultural habit of small cross-functional teams working in short, bounded iterations 4,20. The Design Sprint’s genuine novelty was not any single ingredient but the packaging: it took the divergent creativity of design thinking, the validation discipline of Lean, and the time-boxing of Agile, and fused them into a fixed, repeatable, hour-by-hour checklist that a non-expert could follow 4.
It helps to be precise about the job the sprint was designed for, because much of the later criticism stems from people using it for jobs it was never meant to do. GV’s own description framed the method as “a shortcut to learning without building and launching” 6,23. The traditional product path runs in a costly order: have an idea, build the product, launch it, and only then discover whether customers actually want it. The sprint inverts the risk by letting a team build a convincing facade of the product and put it in front of real customers in a week, so that the expensive lesson arrives before the expensive build 1,53. Knapp and his co-authors were explicit that this is best reserved for high-stakes situations — when the bet is big, when there is not enough time, or when the team is simply stuck 2. The sprint, in other words, was engineered as a focused instrument for answering a specific, important, already-identified question. That framing — a sharp tool for a particular cut — is the thread that runs through everything that follows, and the place where the method most often gets misapplied.
The enduring artifact of the original method is its checklist. The creators’ current step-by-step guide still organizes the week the same way the 2016 book did: Monday you map the problem, Tuesday you sketch solutions, Wednesday you decide which sketches are strongest, Thursday you build a realistic prototype, and Friday you test it with five target customers 2. What gives the method its character is the obsessive specificity — not just what to do each day, but what pens to buy, when to break for lunch, and who is allowed to make which decision.
Before Monday begins, the sprint requires casting two roles that carry most of the method’s weight. The first is the Decider — the genuine decision-maker for the project, the person whose call will actually stick afterward 2. The guide is blunt that without a Decider in the room, decisions won’t hold, and if the real Decider cannot attend the whole week, they must appoint a delegate who can 2. The second role is the Facilitator, who manages time, conversation, and the process itself, and who needs to be comfortable leading a meeting and synthesizing messy discussion on the fly 2. Around these two, the team should be seven people or fewer, deliberately mixing the people who work on the project day to day with diverse outside skills 2. Experts who can’t commit the whole week are scheduled as short “cameo” interviews on Monday afternoon rather than excused entirely 2. The logistics are equally prescribed: block five full days, reserve a room with two whiteboards, gather classic yellow sticky notes (the guide warns that multicolored notes create needless cognitive load), felt-tip pens chosen so handwriting stays legible, and two sets of dot stickers — small ones for “heat map” voting and larger ones for the bigger votes 2. Two principles govern the whole week: no distractions, with devices shut down during working hours, and strict time-boxing, with a visible countdown timer used to create urgency 2.
Monday is about building a shared understanding and choosing where to aim. The team starts optimistically by writing a long-term goal — why this project exists and where they want to be in six months, a year, or five years 2,5. They then deliberately flip to pessimism and list the risks, turning fears like “how could this fail?” into a short list of sprint questions the week could answer 2. Next they make a map: customers and key players listed down the left side, the finished goal on the right, and a simple five-to-fifteen-step flowchart in between showing how a customer moves through the experience 2. The afternoon is given over to Ask the Experts, a series of fifteen-to-thirty-minute interviews with teammates and outside guests in which the team behaves, as the guide puts it, like reporters — updating the goal, questions, and map as new information surfaces 2. As they listen, the team captures problems as How Might We notes, a technique borrowed from design thinking that reframes each problem as an opportunity (“How might we…”), one idea per sticky note 2. These notes get organized into themes, voted on with two votes per person, and the winners are moved onto the map 2. Finally, the Decider picks a target: one specific customer and one specific moment on the map that the rest of the week will focus on entirely 2. The day’s governing ideas are that you should “start at the end” and work backward, that “nobody knows everything” so the team’s scattered knowledge must be pooled, and that problems are most useful when reframed as opportunities 2.
Tuesday turns from understanding to invention, and it is here that the method’s most distinctive belief shows up: that the traditional group brainstorm is actively counterproductive. The morning begins with Lightning Demos, where each person presents great existing solutions from any company — including competitors and analogues from unrelated industries — in three minutes each, with the good ideas captured as quick drawings 2. The team then decides whether to “divide or swarm” the map, assigning people to different parts if the target is large 2. The afternoon is the Four-Step Sketch, done by each person individually and in silence. First, twenty minutes of Notes, walking the room and gathering what’s on the walls. Second, twenty minutes of rough Ideas, jotted privately, with the most promising circled. Third, the famous Crazy 8s: a single sheet folded into eight frames, with eight rapid variations of one strong idea sketched at one minute apiece 2. Fourth, a Solution sketch — a self-contained, three-panel storyboard on a single sheet, made to be self-explanatory, kept anonymous, given a catchy title, and held to the cheerful standard that “ugly is okay” but “words matter” 2. In parallel, someone is put in charge of recruiting customers for Friday, writing a screening survey, and finding target users where they congregate, with a recruiting service like UserTesting as a backup 2. The day’s principles capture the method’s creative philosophy: every great invention is built on existing ideas, almost anyone can sketch because most sketches are just rectangles and words, concrete beats abstract, and — most pointedly — you should “work alone together” because group brainstorms don’t work 2.
Wednesday exists to solve the problem Knapp originally set out to fix: how a group makes a fast, high-quality decision without the loudest voice winning. The mechanism is a five-step ritual called the sticky decision 2. First, the Art museum: all the solution sketches are taped up in a long row like gallery pieces. Second, the Heat map: each person silently reviews every sketch and places small dot stickers on the specific parts they like, with no discussion, so that interest becomes visible at a glance. Third, the Speed critique: three minutes per sketch in which the group discusses highlights and objections while someone captures them, ending by asking the sketch’s author if anything was missed. Fourth, the Straw poll: each person silently picks one favorite and places a single large dot, a nonbinding signal of where the group leans. Fifth, the Supervote: the Decider receives three large dots marked with their initials, and whatever the Decider chooses is what gets prototyped and tested — full stop 2. The team then separates winners from “maybe-laters” and decides whether the winning ideas can fit into a single prototype or whether genuinely conflicting concepts call for two or three competing prototypes in a head-to-head “Rumble,” using fake brand names so the comparison is fair 2. The day ends by turning the chosen direction into a storyboard — roughly fifteen squares on a whiteboard, starting from how a customer first encounters the product and running five to fifteen steps forward in just enough detail to guide Thursday’s build 2. The Facilitator’s watchword for the day is “don’t drain the battery”: defer hard calls to the Decider, push small decisions to tomorrow, and refuse to let new abstract ideas sneak in 2.
Thursday is a single-minded production day, and its defining concept is the prototype mindset: the belief that you can prototype anything if you accept that the prototype is disposable and needs only to appear real, not be real 2. The first instruction is counterintuitive — don’t use your normal high-quality production tools, because they are optimized for polish and therefore slow; instead, use tools that are rough, fast, and flexible 2. The team divides into clear roles: Makers build the individual pieces, a Stitcher assembles them into a coherent whole and guards overall quality, a Writer handles the words (which matter more than teams expect), an Asset Collector gathers borrowable images and content, and an Interviewer prepares for Friday 2. Throughout the day the team runs a trial of the prototype to catch mistakes, makes sure the Interviewer and Decider have seen it, writes the interview script, reminds the recruited customers to show up, and buys the gift cards (typically around one hundred dollars) used to thank participants 2. The quality bar is captured in a single phrase the method calls Goldilocks quality — not too rough and not too polished, but just realistic enough to provoke honest reactions from customers, because a prototype that looks obviously fake gets fake feedback and one that looks finished wastes effort that the sprint exists to save 2.
Friday closes the loop by putting the prototype in front of five real target customers, one at a time, in a single day, with the whole team watching together rather than disbanding 2. If the interviews happen in person, the team sets up a makeshift research lab: a comfortable interview room and a separate sprint room where the team watches a one-way video feed 2. Each interview follows a Five-Act Interview structure designed by Michael Margolis: a friendly welcome to put the customer at ease, easy context questions, an introduction to the prototype (with a reminder that nothing is being tested about the customer), the core tasks-and-nudges section where the interviewer watches the person figure the prototype out while thinking aloud, and a debrief 2. The interviewer is coached to be a good host, ask open-ended “who/what/where/when/why/how” questions, use “broken questions” that trail off into silence to avoid leading the customer, and stay authentically curious 2. The team observes against a scorecard — a grid with a column for each customer and a row for each question or assumption — taking notes, then voting yes or no on each question for each customer, with the Decider making the final call per question at the end of the day 2. The day’s three principles are the philosophical payoff of the whole method: five is the magic number because clear patterns emerge after five interviews, the team should watch together to draw better conclusions, and there is “a winner every time” because the result is either an efficient failure or a flawed success — and in both cases the team has learned exactly what it needs for the next step 2.
The checklist is the surface. Underneath it sit four load-bearing beliefs about psychology and decision-making, and understanding them is what separates a practitioner who can adapt the method intelligently from one who is merely following steps. Each belief is also a place where the method’s confidence outruns its evidence, which is why this section sets up much of the later critique.
The single most important idea in the sprint is that traditional group brainstorming is a bad way to generate good ideas, and that the fix is to have people work alone, together — in the same room, on the same problem, at the same time, but generating individually 2. The method’s proponents argue that unstructured group brainstorms reward the most extroverted and confident people, quietly punish introverts who need time to think, and prioritize the quantity of ideas shouted out over their quality 8[16-context]. This is why Tuesday’s sketching is silent and individual, and why even the decision process on Wednesday begins with silent dot-voting before any discussion. The belief has real support in the broader research literature on group creativity, which has repeatedly found that “brainwriting” and individual ideation tend to outperform verbal group brainstorming on both the number and originality of ideas. The sprint operationalizes that finding into a ritual. The risk, as later critics note, is that replacing one flawed group ritual (the brainstorm) with another (silent sketching followed by dot-voting) can swap one set of biases for a different, less visible set 11.
The second belief is that most organizational decisions are corrupted by what is often called the HiPPO problem — the tendency for the “highest paid person’s opinion” to override evidence and discussion. The sprint’s answer is not to pretend the team is a flat democracy but to formalize authority openly: one named Decider, given an explicit, weighted “supervote,” makes the call, and everyone agrees in advance to build and test whatever that person chooses 2. The logic is that slow, ambiguous decisions sap a team’s energy and stall the timeline, so it is better to make the power structure transparent and fast than to let it operate invisibly through debate 2. The straw poll that precedes the supervote is a clever piece of design: it surfaces the group’s genuine preference as a signal to inform the Decider, without binding the Decider to it 2. The honest tension here is that the same mechanism built to defeat the HiPPO can just as easily entrench it — if the Decider is also the highest-paid person and ignores the straw poll, the sprint has simply given executive intuition a faster, better-organized rubber stamp 11.
The third belief is the most famous and the most misunderstood: that testing with just five customers is enough to find the important problems. This is not something Knapp invented; it comes directly from usability research published in 1993 by Jakob Nielsen and Thomas Landauer, whose mathematical model showed that usability problems are discovered on a curve of steep diminishing returns 17,16. By their estimate, the first test user uncovers roughly 31 percent of the problems, and five users together surface about 85 percent, after which each additional participant reveals very little that is new 18,16. Nielsen Norman Group’s own analysis of dozens of real consulting projects found only a tiny correlation between the number of users tested and the number of insights produced, which is why they argue for small, frequent rounds rather than one large study 16. The practical wisdom that follows — and that the sprint adopts — is that three rounds of five users beats one round of fifteen, because each round lets you fix the biggest problems before they mask the smaller ones underneath [40-context]16. The crucial caveat, which the sprint’s marketing tends to skip, is that the five-user rule holds reliably only for a relatively uniform group of users testing for obvious interface problems 17. When the audience is genuinely diverse, or the questions are subtle, or the stakes demand statistical confidence, five is demonstrably not enough — a later study by Spool and Schroeder found that complex e-commerce sites needed considerably more than five users to find even 85 percent of problems, and modern practitioners increasingly argue that ten participants often strike a better balance for today’s broader research goals 19,17. The sprint treats “five is the magic number” as a near-universal law; the underlying research treats it as a context-dependent rule of thumb 16,17.
A less-discussed but essential belief in the sprint is that constraints — especially tight time limits — improve the quality of work rather than degrading it. The method is built on aggressive time-boxing: a visible countdown timer runs during nearly every activity, breaks are scheduled every sixty to ninety minutes, and the Facilitator is coached to “decide and move on” the moment a discussion starts to sprawl 2. The reasoning draws on a well-known observation often called Parkinson’s Law — that work expands to fill the time available — and inverts it deliberately, using an artificial scarcity of time to force closure and prevent the perfectionism and circular debate that the creators watched devour ordinary projects 2. Just as important is the method’s treatment of decision-making as a finite energy budget rather than an unlimited resource. The Facilitator’s recurring instruction is “don’t drain the battery”: each decision costs the group energy, so hard calls are deferred to the Decider, small calls are pushed to the next day, and new abstract ideas are actively kept out so the team can work with what it already has 2. This is a practical application of the idea, popularized in behavioral science, that focus and self-control draw on a limited reserve that depletes over the course of a day, and it explains the otherwise odd rituals around scheduled snacks, deliberately light lunches, and protecting the team’s stamina 2. The clock and the battery are two halves of the same philosophy: a sprint succeeds not by working people harder but by spending their limited focus on the few decisions that actually matter, in an order that keeps momentum alive 2.
The fourth belief reframes what a prototype is for. In most engineering cultures, a prototype is an early version of the thing you are building — a step on the path to the real product. The sprint insists instead that a prototype is a question made physical, a disposable facade whose only job is to generate a learning, and which should be thrown away afterward 2. This is why the method is comfortable “faking it”: a prototype can be a clickable shell with no working back end, a brochure describing a product that doesn’t exist, or a person secretly operating what looks like an automated system 2. The “Goldilocks quality” standard exists to serve learning specifically — enough realism to get honest reactions, no more — and the whole approach assumes that the cost of building the fake is trivial compared to the cost of building the real thing and being wrong 2. This belief is the sprint’s most durable and least controversial contribution, and as the next sections show, it is also the one that artificial intelligence is now reshaping most dramatically, since the cost of producing a convincing prototype has collapsed 2,22.
A method adopted by thousands of teams does not stay frozen, and the Design Sprint has splintered into several distinct lineages. Some forks came from Google itself, some from the consultancies that built businesses around the method, and the most consequential came from the original creators as they rethought the approach from the ground up. The table below orients the main variants before the text examines each.
| Variant | Source | Length | Core change | Best for |
|---|---|---|---|---|
| Classic Design Sprint | Knapp / GV, Sprint (2016) | 5 days | The original Monday–Friday checklist | Startups and teams answering one big, defined question 2 |
| Google Design Sprint Kit | Google (official kit) | 1–5 days | Reframed as six flexible phases with a menu of swappable methods | Teams wanting modular flexibility and large method library 26,27 |
| Design Sprint 2.0 | AJ&Smart / Jonathan Courtney (2018) | 4 days | Compresses Mon–Tue into one day; full team needed only two days | Large organizations that can’t free a whole week 7,9 |
| Remote / distributed sprint | GV + tools (Miro, Zoom) | 4–5 days | Runs entirely online with digital whiteboards | Distributed teams; became default after 2020 2,25 |
| Foundation Sprint | Knapp & Zeratsky, Click (2025) | 2 days | Front-end strategy: decides what to build before any design | Brand-new projects with no defined problem yet 3,21 |
| Service Design Sprint | Tenny Pinheiro (2014) | Varies | Parallel lineage grounded in service design + Lean | Service innovation rather than product prototyping 20 |
While Knapp’s book defined the canonical five-day version, Google itself later published an official Design Sprint Kit that reframes the method as six named phases rather than five weekdays: Understand, Define, Sketch, Decide, Prototype, and Validate 26,27. (Some of Google’s materials substitute “Diverge” for “Sketch,” but the structure is the same 29.) The most important difference from the book is philosophical: where the book is a fixed hour-by-hour script, Google’s kit treats the six phases as a stable backbone with a menu of interchangeable methods inside each one — the Understand phase alone offers around fifteen different activities to choose from, including techniques contributed by the Luma Institute such as abstract laddering and affinity clustering 27. This modularity is sometimes called a “triple diamond” approach, expanding the design-thinking double diamond 27. Practitioners who have worked deeply with Google’s version stress two things. First, “the phases are fixed; the methods inside them are choices,” and knowing which is which is where real facilitation skill lives 28. Second, and more provocatively, “the six phases are not the sprint — they’re the middle of it,” because the planning that happens before day one (choosing the right challenge, framing the problem, selecting the right participants, understanding the history) is where most sprint outcomes are actually determined 27,28. The repeated lesson from large organizations is that the method is “not plug-and-play” and must be adapted to a team’s culture, size, and risk tolerance 28.
The most widely used variant outside Google came from AJ&Smart, a Berlin product studio led by Jonathan Courtney, which ran more than two hundred sprints after the book came out and trained thousands of people alongside Knapp 9,7. Their Design Sprint 2.0, introduced around May 2018, is described as the most up-to-date “semi-official” version and is notable for being the only update Knapp himself has endorsed 7,8. Its headline change is compressing the process from five days to four, and its more practically important change is that the full team is only needed for the first two days [12-context]7. In the 2.0 structure, Monday is “basically two days squeezed into one” — the original Monday’s understanding exercises in the morning and Tuesday’s sketching in the afternoon — followed by a decision and storyboard, then a full day of prototyping and a full day of testing 9. AJ&Smart kept the prototyping and testing days intact and untouched because they considered those two “non-negotiable and non-shrinkable,” and in their model the studio’s own team handles the prototype and the user research rather than the client’s experts 9,10. They also recruit six users instead of five — five plus one spare in case someone cancels — a small but telling adaptation 8. The explicit motivation for 2.0 was to make the method viable for large corporations that genuinely cannot dedicate a full week, a constraint the original five-day version struggled against 7,8.
A second major evolution was the shift online. The creators’ current guidance treats remote sprints as a first-class option rather than a fallback, recommending an official Miro template paired with Zoom and noting wryly that running online is “less fun but more practical” — and that they now run most of their sprints remotely 2. This shift was accelerated enormously by the pandemic, after which the image of a room papered in sticky notes started to feel, in one practitioner’s words, like “a relic from a different working world” 25. Digital whiteboard tools such as Miro and Figma, combined with remote user-testing services, made it possible to run the entire sequence with a distributed team, and the creators released an updated “2024 Design Sprint” Miro template to reflect current practice 2,25. The trade-off practitioners report is real: remote sprints lose some of the energy, spontaneity, and social bonding of being physically together, but they dramatically lower the logistical cost of assembling the right people and recruiting the right customers 2.
The most significant evolution came from the creators themselves and directly addresses the deepest criticism of the original method. In early 2025, Knapp and Zeratsky introduced the Foundation Sprint in their book Click, the sequel to Sprint, debuting the method publicly through Lenny’s Newsletter 21,3. The Foundation Sprint is a two-day workshop for the very beginning of a big project — before any design work — and it exists because, after working with more than three hundred teams, the creators concluded that a crucial element was usually missing: a shared strategic foundation about what to build and why, established before anyone starts sketching solutions 3,21. The structure moves through three blocks. Day one morning defines the Basics — the target customer, the most important customer problem, the team’s genuine advantage, and the competitors (including “do nothing,” whose presence is a warning that the problem may not be painful enough) 3. Day one afternoon crafts Differentiation, using a two-by-two chart focused on customer perception to find a position where the product sits alone in the top-right quadrant while competitors are pushed into the other three (which the creators jokingly call “Loserville”), followed by a one-page “Mini Manifesto” of guiding principles 3. Day two chooses an Approach using a technique called Magic Lenses — plotting candidate approaches against a series of two-by-two charts (a customer lens, a pragmatic lens, a growth lens, a money lens, plus custom ones) so that complex trade-offs become visible rather than argued in the abstract 3. The output is a single testable sentence called the Founding Hypothesis: “If we help [customer] solve [problem] with [approach], they will choose it over [competitors] because our solution is [differentiators]” 3. The intended workflow is explicit and sequential: run a Foundation Sprint to define the hypothesis, then run a series of Design Sprints to test and refine it until the product “clicks” with customers 3. Throughout, both methods now lean on a lightweight decision technique called Note-and-Vote — individual silent writing, silent dot-voting, brief debate, then the Decider decides — which has become a reusable building block across the creators’ work 3. The Foundation Sprint is, in effect, the creators’ admission that the original sprint assumed teams already knew which problem to solve, and that this assumption was often wrong 3,21.
Finally, it is worth noting that the GV sprint was neither the first nor the only published sprint method, even if it became by far the most famous. In 2014, Brazilian service designer Tenny Pinheiro released The Service Startup: Design Thinking Gets Lean, introducing a Service Design Sprint grounded in service design and Lean Startup principles and aimed at service innovation rather than product prototyping 20. These are genuinely separate evolutions of the sprint idea that developed in parallel, and acknowledging them guards against the common mistake of treating “the Design Sprint” and “Jake Knapp’s method” as perfectly synonymous 20.
One reason the method spread so effectively is that it was designed to be decomposable: individual techniques can be lifted out of the full week and used on their own, which lowered the barrier to adoption. The creators explicitly encourage this, noting that a team facing a small decision in any meeting can run a quick Note-and-Vote, that frustrated teams can use How Might We notes to reframe problems, and that a group stuck arguing in the abstract can run a Four-Step Sketch to make ideas concrete — all without committing to a full sprint 2. The creators have since packaged some of these into named mini-methods of their own, including a Name Sprint for choosing a product or company name and the standalone Note-and-Vote technique, both published as free guides alongside the Design Sprint and Foundation Sprint 2,3. This modularity turned the sprint from a single workshop into a toolkit, and it is part of why the method seeped into everyday product practice even among teams that rarely ran the formal five-day version 25. The second engine of adoption was a commercial training ecosystem. Consultancies such as AJ&Smart and Design Sprint Academy built businesses on teaching, facilitating, and selling sprints, training thousands of practitioners inside large enterprises and producing a steady stream of videos, templates, and courses that kept the method visible and lowered the cost of learning it 8,36. GV itself amplified the spread by collecting and publishing user stories and by releasing an official Design Sprint Kit, while the creators offer free guides, book excerpts, and a maintained Miro template to anyone who wants to run their own 2,6,26. The combined effect was a self-reinforcing loop: accessible free resources created practitioners, practitioners created demand for training, and training created more practitioners — which is how one designer’s internal Google process became a global default for tackling ambiguous problems 25,36.
The most current chapter in the method’s story is its collision with generative artificial intelligence, and the creators have repositioned their entire framework around it. This is not a marketing afterthought — it is the explicit rationale behind the Foundation Sprint and a live theme in how sprints are run today.
The creators’ own framing is striking. Their current Design Sprint guide opens with the claim that “as the cost of building products moves toward zero with AI, the Design Sprint offers a practical, proven method for deciding what to build and how to stand out from the competition” 2. The Foundation Sprint materials sharpen this into a warning: in a world where generative AI lets anyone produce prototypes and code in record time, “running in the wrong direction only leads to arriving at the wrong destination faster” 22. The strategic logic is that as building becomes commoditized, the human decisions about direction and differentiation become the scarce, valuable, defensible work 22,3. The method’s proponents identify a specific new failure mode they call the “everything trap” — the temptation, now that AI makes everything easy to build, to try to beat competitors at everything at once rather than choosing one or two genuine ways to win 22. This reframing effectively elevates the Foundation Sprint above the Design Sprint in importance for early-stage work: the bottleneck has moved upstream from execution to judgment 22,35.
Beyond the strategic repositioning, AI is being woven into the mechanics of sprints themselves. The phases that historically consumed the most time — the early research and the prototyping — are exactly where AI tools are now being applied 23. On the front end, AI inspiration and research tools can compress the Monday-and-Tuesday work of gathering visual benchmarks, aligning on direction, and surfacing references, which traditionally ate hours of hunting and arguing 23. In the sketching phase, some practitioners now have participants use AI tools to explore variations, simulate flows, or co-design parts of a solution, which they argue can unlock more unconventional thinking before the team critiques and combines ideas 36. On the prototyping day, AI functions as a “speed multiplier,” letting a team produce a far more realistic facade in the same single day 21,24. A growing number of practitioners describe explicitly “AI Design Sprints,” typically built on the four-day structure, that bake these tools into each phase 36,23. There is also a recursive twist: product teams are now running sprints specifically to design AI-powered products, where the prototype must somehow convey behavior driven by a large language model — a genuinely harder thing to fake convincingly 24.
The most interesting tension in the AI era is one the creators themselves flag: the more a product is AI-generated, the more generic it tends to become, because everyone has access to the same models producing similar outputs 22. This is precisely why the methodology now insists that differentiation remains human work — AI is excellent at prototyping, but only people can define the radical, opinionated point of view that makes a product genuinely distinct 22,3. The repeated guidance from Knapp and Zeratsky is that founders must retain ownership of the core narrative and positioning, using AI as a speed multiplier without abdicating the product thinking itself 51,21. In this telling, AI does not make the sprint’s human-judgment exercises obsolete; it makes them more valuable, because the parts of product development that AI can do are no longer where competitive advantage lives 22. Whether this framing holds up — or whether it is partly the understandable instinct of a methodology defending its relevance — is something a critical reader should keep in view 25.
Because terms like “design sprint,” “design thinking,” “Lean Startup,” and “Agile” get used loosely and often conflated, it is worth placing the sprint precisely among its neighbors. The cleanest way to understand them is by the job each one does in the overall arc of building a product, summarized in the table below and then explained.
| Approach | Origin | Primary job | Time-boxed? | Output |
|---|---|---|---|---|
| Design thinking | IDEO / Stanford d.school | Understand users and frame the right problem | No | A well-understood problem and explored solution space 31 |
| Design Sprint | Jake Knapp / GV (2016) | Solve a defined problem and validate a solution fast | Yes (4–5 days) | A tested prototype and a clear answer 2,31 |
| Lean Startup | Eric Ries | Test business hypotheses and find a viable model | No | Validated learning via minimum viable products 33 |
| Agile / Scrum | Agile Manifesto (2001) | Build and ship working software iteratively | Yes (iterations) | Working, released product increments 33 |
The most useful one-line distinction practitioners offer is this: design thinking frames problems, design sprints solve them quickly, and Agile implements solutions efficiently 31. Design thinking, associated with IDEO and Stanford’s d.school, runs through five non-time-boxed phases — Empathize, Define, Ideate, Prototype, Test — and is best understood as a versatile mindset and toolkit for deeply understanding users and identifying the right problem to work on in the first place 31. The Design Sprint is narrower and more rigid by design: a four-to-five-day, tightly time-boxed problem-solving method that presupposes a well-defined challenge going in, which is why it is often described as a fusion of design thinking and Agile 31,33. Lean Startup, Eric Ries’s framework, starts from an explicit hypothesis and validates it through minimum viable products in a continuous build-measure-learn loop aimed at “validated learning” and a workable business model; unlike the sprint, it is not time-boxed and is more concerned with the market and the model than with the design of a single product experience 33. Agile and its frameworks — Scrum, Kanban, Extreme Programming — emerged from the 2001 Agile Manifesto and govern how cross-functional teams build and ship software in short iterations (also, confusingly, called “sprints”), with roles like the Scrum Master and Product Owner 33. The name collision between Agile “sprints” and “Design Sprints” is a frequent source of confusion, but they are different things: one is an ongoing delivery cadence, the other a one-off intensive workshop 33.
The framing that holds up best is that these are not competitors to be chosen between but complementary tools that add value at different points in the innovation arc 32. The strongest synthesis advice is to use design thinking to understand and frame, a design sprint to rapidly explore and validate a promising solution, Lean Startup thinking to test the business assumptions, and Agile to build and ship — with the common thread across all four being to involve real customers early and often 32. One innovation coach captures it well: it makes more sense to see design thinking, Lean, the sprint, and Agile as tools in a single toolbox than to argue one is superior, because each adds value somewhere on the spectrum 33. The practical failure most teams make is leaning on a single favored approach for every situation and ignoring the others 32. This placement also clarifies the sprint’s most important boundary condition, which becomes the hinge of the next section: because the sprint is a solving tool that assumes the problem is already chosen, using it to decide which problem to solve is, in practitioners’ words, its single biggest misuse 31.
The Design Sprint spread further and faster than almost any comparable product methodology, and the stories used to sell it are worth knowing — both because they are genuinely illuminating and because they should be read with care.
By the creators’ own accounting, their methods have been used by more than three hundred teams to bring products to market, including teams at Google, Microsoft, YouTube, Slack, Uber, and One Medical, and adopted by organizations as varied as Airbnb, Amazon, LEGO, MIT, Mercedes-Benz, Harvard Business School, and the University of Oxford 1. The book Sprint became, in the words of multiple practitioners, a fixture on product-team bookshelves worldwide, selling over five hundred thousand copies and being translated into more than twenty languages 21. A consulting ecosystem grew up around the method — firms like AJ&Smart and Design Sprint Academy trained thousands of practitioners inside organizations including SAP, Roche, the World Bank, HSBC, and EY, and even co-organized a “Sprints for Change” conference with Google 36,9. For roughly a decade, running design sprints became something close to a global movement among design and innovation teams who needed a fast, structured, human-centered way to attack ambiguous problems 36.
The most-cited case studies come from the book itself and GV’s portfolio. The signature example is Savioke, a robotics startup that used a sprint to give its hotel delivery robot, Relay, a personality — testing how guests at an Aloft hotel would react by having the robot deliver a toothbrush to a guest’s room, and learning that a little expressiveness made the experience delightful rather than unsettling 6[22-context]42. Slack used sprints to work out how to explain its then-unfamiliar product to non-technical customers and to overhaul its marketing and onboarding 6[22-context]. Blue Bottle Coffee used the method to design an online store and expand into online sales 6. Flatiron Health tackled the genuinely high-stakes problem of getting cancer patients enrolled into clinical trials 6. The fitness app FitStar used a sprint to perfect its new-user experience, and Foundation Medicine used sprints to design interactive diagnostic tools for oncologists 6. More recent practitioner accounts describe sprints at companies like Lyft producing concrete features such as “Rides for Others” and family accounts 24. Across these cases, the recurring pattern is the method’s claimed range — consumer apps, physical robots, life-or-death healthcare, marketing, hardware — which is exactly the breadth the creators emphasize when they argue the prototype mindset can be applied to almost anything 2,6.
Here a careful reader must apply a discount. These case studies are, almost without exception, self-reported success stories told by the method’s creators and the consultancies that sell it, with no control group and no counterfactual 11. We do not know what would have happened had Slack or Blue Bottle made the same decisions without a sprint, and the natural tendency to attribute a company’s later success to a memorable week of work is a textbook case of confounding 11,13. The stories demonstrate that the method can produce useful prototypes and decisions in a week; they do not, and cannot, demonstrate that the sprint caused the downstream business outcomes, nor that it outperforms the alternatives. This is not a reason to dismiss the cases — they are real, instructive, and honestly told — but it is a reason to treat them as illustrations of how the method works rather than as evidence that it works better than other approaches.
There is also a survivorship problem worth naming explicitly. The sprints that become case studies are, almost by definition, the ones that produced a memorable result at companies that went on to succeed; the sprints that fizzled, validated nothing useful, ran at companies that later failed, or simply produced an undramatic “no” rarely get written up, turned into conference talks, or featured in marketing 11,25. Published accounts of sprints that failed are vanishingly rare in the literature, which means the visible record is systematically skewed toward success in a way that quietly inflates the method’s apparent hit rate 14,11. The same dynamic affects the practitioners who become the method’s most visible advocates — the people who built careers and consultancies around running sprints have an obvious stake in the method looking indispensable, and their enthusiasm, however sincere, is not a neutral data source 12,13. A disciplined reader should adjust for both effects: the canonical case studies describe the ceiling of what the method can achieve under favorable conditions, with the right problem and a skilled facilitator, not the average outcome across the thousands of teams who have tried it with varying preparation and skill 11,14. Treated that way, the stories remain genuinely useful as existence proofs of the method’s range, while losing the false authority of a track record 11.
That distinction leads directly into the most important section of this report.
The Design Sprint deserves credit for solving real problems: it gives teams a way to make fast decisions, it protects focused individual thinking from the tyranny of the group brainstorm, it forces validation before expensive building, and it has demonstrably helped many teams break out of analysis paralysis 1,2. But a clear-eyed practitioner needs to hold those strengths alongside a set of well-documented weaknesses, several of which the method’s own creators have implicitly conceded through the invention of the Foundation Sprint.
The first thing to say is that, despite the method’s enormous popularity, the rigorous empirical evidence for it is surprisingly thin. Academic researchers studying the Design Sprint note explicitly that there are very few peer-reviewed papers reporting on the technique and what its actual advantages and disadvantages are 14. The bulk of what exists is practitioner testimony, vendor case studies, and a handful of small academic studies in education and software-requirements contexts 14,15. This does not mean the method is ineffective; it means that confident claims about its effectiveness rest largely on the authority and storytelling of its creators rather than on controlled comparison 14. For a method this widely adopted, the gap between the strength of the claims and the strength of the evidence is itself a finding worth sitting with.
The most common and most serious criticism is that a sprint is only as good as the knowledge the team brings into it, and that teams routinely bring in too little. Critics point out that the only problems a sprint tackles are the ones the “internal experts” happen to raise on Monday, which means the process can quietly inherit and amplify the organization’s existing blind spots 11. Without recent, deep customer research feeding the week, a sprint can become, in one practitioner’s blunt phrase, “fun hours and days of guessing and assuming how we can drive or manipulate users into delivering the outcomes the business wants” 13. This opens the door to confirmation bias — the team interprets the five customer interviews as evidence for what it already believed, especially since testing five users only reveals problems with the specific solution being tested, not whether the underlying premise was sound 11. Practitioners working with Google’s own version reach the same conclusion from the opposite direction: sprints “are not worth the effort if you don’t have enough data on the problem to solve,” and the planning and research that happen before day one are where most outcomes are actually determined 29,28. The sprint’s speed, in other words, is a double-edged sword — it is just as fast at confirming a wrong assumption as a right one.
The deepest structural criticism, and the one most associated with the product-discovery movement, is that the sprint over-emphasizes generating and prototyping solutions without first validating that the team is solving the right problem 11. Product thinkers like Teresa Torres and Marty Cagan have argued for years that teams should map the problem space and test their riskiest assumptions before jumping to solutions — using tools like opportunity-solution trees to connect ideas back to validated customer needs — rather than racing to a hi-fi prototype of a solution whose underlying premise was never checked 11. The sprint’s own community concedes the boundary: its practitioners state that the single biggest misuse of the method is teams trying to use it to decide what problem to solve in the first place, because the sprint structurally assumes a well-defined challenge as its starting point 31. This is precisely the gap the creators eventually moved to fill with the two-day Foundation Sprint, which is essentially an admission that the original method skipped the strategic problem-framing work and that many teams were sprinting confidently toward the wrong target 3,21. A sprint run on a poorly chosen problem produces a beautifully tested answer to a question that didn’t matter.
A subtler criticism targets the very mechanisms the sprint uses to make decisions feel objective. Dot-voting — the heat maps, straw polls, and supervotes — is the method’s primary tool for converging from many ideas to one, and critics question whether it should be 11. The transition from generating ideas to choosing among them is genuinely hard, a phase facilitators call the groan zone, and dot-voting is a fast but blunt instrument for navigating it 11. The concern is that dot-voting can carry more hidden bias than alternatives, because votes cluster around whatever is already popular or whatever the influential people in the room gravitate toward, and richer methods like a structured two-by-two matrix or a “gradient of agreement” scale can surface more nuance 11. Combined with the earlier point about the Decider, the critique is that a process designed to neutralize organizational bias can, if run carelessly, simply repackage that bias in the legitimizing costume of sticky dots and silent votes — giving a predetermined conclusion the appearance of democratic, evidence-based consensus 11. The rituals are good; the claim that they guarantee unbiased decisions is overstated.
The method’s greatest strength — its prescriptive, follow-the-checklist specificity — is also a source of weakness. In an academic study of design sprints used in engineering education, students who went through the process specifically faulted it for being a “very limiting (rigid) method,” “a very basic process with a number of unknown outcomes,” and for the forced march through obligatory stages 15. In large organizations, the consistent finding is that the method “is not plug-and-play” and must be adapted to the team’s culture, size, risk tolerance, and decision-making dynamics, and that teams who run it rigidly “by the book” tend to struggle not because the method is broken but because they failed to flex it to their context 28. The framing that experienced facilitators land on is that the phases are fixed but the methods inside them are choices, and that most of the real skill is in that adaptation — which is, notably, exactly the expertise a beginner following the checklist does not yet have 28. There is also a pointed critique from within the design profession itself: experienced designers sometimes find sprints redundant and slow, because the activities a sprint spreads across several days with a whole group — interviews, ideation, prototyping, testing — are things a skilled designer already does faster on their own 12. For a seasoned team, the sprint’s structure can be scaffolding they no longer need.
Finally, there is the seductive misconception that a single sprint settles a question. Two related problems feed this. The first is structural: in the classic sequence, validation with real customers is left to the very end, which means a team can spend four days building elaborately on a faulty assumption before discovering, on Friday, that the premise was wrong — wasting most of the week 30. Critics argue that learning should be woven into every phase, with quick validation checks as early as Monday, rather than concentrated in a single final act 30. The second problem is conceptual: a sprint is one loop of a process that is fundamentally iterative, and the creators themselves note that the result is rarely a finished answer but rather a learning that should feed the next sprint 5,3. Treating the output of one week as a permanent verdict — rather than as one data point in an ongoing cycle — is a misuse, yet the method’s “solve big problems in five days” marketing actively invites it 25. The most candid current assessment from within the product community is that it is now rare to see teams run sprints strictly by the book, that the original Sprint can feel like a relic of a co-located, sticky-note world — and yet that the underlying framework has genuinely stood the test of time when used judiciously rather than dogmatically 25.
Pulling these failure modes together yields a clear set of conditions under which a team should not reach for a Design Sprint, or should do something else first. A sprint is the wrong tool when the problem itself is not yet well-defined, in which case the team needs problem-framing and discovery — or a Foundation Sprint — before anything else 31,3. It is the wrong tool when the team lacks real, recent customer data to inform the week, since the process will simply launder its own assumptions 29,13. It is the wrong tool when the team already knows the solution and the real question is one of engineering feasibility or execution that cannot be faked in a one-day prototype 29. It is the wrong tool when no genuine Decider can commit, because the decisions won’t stick 2. And it is often overkill for small, incremental tweaks that don’t carry enough risk or ambiguity to justify clearing five days and assembling seven people 2. The sprint earns its keep precisely in the situation it was built for: a high-stakes, genuinely ambiguous, already-identified problem where the team is stuck and a wrong guess would be expensive 2.
The GV Design Sprint is one of the most influential product methods of the last fifteen years, and that influence is deserved. Jake Knapp’s original insight — that good work needs both protected individual thinking and a hard deadline, and that office defaults supply neither — produced a genuinely clever piece of social engineering: a repeatable, hour-by-hour recipe that lets an ordinary team move from a fuzzy problem to a customer-tested prototype in a single week, while sidestepping the endless meetings, the loudest-voice problem, and the build-first-learn-later trap that plague normal product development 1,2. Its most durable contributions — the prototype-to-learn mindset, the discipline of working alone together, the formalized Decider, and the habit of putting something real in front of real customers fast — have permanently shaped how product teams think, and they remain valuable even for teams that never run a formal sprint again 2. The method has also shown an admirable capacity to evolve: from the original five days to Google’s flexible six-phase kit, to AJ&Smart’s leaner four-day version, to fully remote practice, and most tellingly to the creators’ own two-day Foundation Sprint, which answers the original method’s deepest blind spot by tackling what to build before how to design it 3,7,26.
But the report’s central judgment is that the sprint is a sharp tool for a specific cut, not a universal solvent — and that most of the trouble teams have with it comes from forgetting this. It is a solving tool that assumes the problem is already the right one; pointed at an unvalidated or poorly chosen problem, it produces a beautifully tested answer to a question that didn’t matter 31,11. Its speed confirms wrong assumptions as efficiently as right ones, its decision rituals can quietly repackage bias as consensus, its five-user testing rule is a context-dependent rule of thumb rather than a law, and its “solve it in a week” promise dangerously implies that one iteration is a verdict rather than a single loop in an inherently iterative process 11,16,30. The thin empirical evidence base means that confidence in the method rests more on the creators’ authority and storytelling than on controlled proof, and the canonical case studies, however instructive, are self-reported successes without counterfactuals 14,11. For a practitioner, the operative recommendations are straightforward: invest heavily in problem-framing and real customer research before the sprint (or run a Foundation Sprint first); secure a genuine Decider; adapt the fixed checklist to your team’s context rather than following it dogmatically; treat dot-votes and five-user tests as useful signals rather than oracles; and regard the output of any single sprint as the start of an iterative loop, not its conclusion 3,28,29,30. Used that way — with the enthusiasm the method earns and the skepticism it requires — the Design Sprint remains, even in an age where artificial intelligence is collapsing the cost of building, one of the best instruments available for the increasingly valuable human work of deciding what is actually worth building at all 2,22.