In May 2014, a Sunnyvale robotics startup called Savioke had a hotel delivery robot that worked and a question nobody could answer: would guests find it charming or creepy? CEO Steve Cousins and a team from Google Ventures cleared a full week to find out. By Wednesday they had 23 competing ideas for the robot’s personality. By Thursday night they had a prototype built in about eight hours, with a face on an iPad, a set of chimes, and a “happy dance,” steered from a laptop and a PlayStation controller. On Friday they watched real guests at a Starwood hotel receive toothbrushes from it. Some asked for repeat deliveries just to see it again. Three weeks later the robot was in full-time service, and by the end of that summer Savioke had more orders than it could produce, according to the account adapted from the book Sprint.
That is the design sprint working exactly as intended. One team, one hard question, five days, and an answer from real people instead of a conference room.
It is also the reason the method gets misused. The Savioke team already knew what they were building and who it was for. Their open question was narrow and testable. Most teams that run a design sprint are not in that position, and the sprint quietly fails them.
What a design sprint actually is
A design sprint is a five-day process, created by Jake Knapp at Google Ventures and published with John Zeratsky and Braden Kowitz in the 2016 book Sprint, for testing an idea with customers before anyone commits to building it. The authors say they have used it with more than 300 teams, and it has since spread to thousands more.
The week runs on a fixed schedule:
- Monday, Map. Agree on a long-term goal, list the questions that could sink it, map the customer journey, and pick one target moment on that map.
- Tuesday, Sketch. Everyone works alone. Notes, rough ideas, “Crazy 8s” (eight variations in eight minutes), then one detailed solution sketch each.
- Wednesday, Decide. Sketches go on the wall anonymously. The team dot-votes in silence, and the Decider makes the call. The winner becomes a storyboard.
- Thursday, Prototype. Build a realistic facade, not a product. Slides, a clickable mockup, a remote-controlled robot.
- Friday, Test. Five customers each go through the prototype in a one-on-one interview while the team watches.
Some older write-ups (including the previous version of this page) describe the phases as “Understand, Diverge, Converge” or borrow the Empathize and Define stages from design thinking. Those are related frameworks, but they are not the GV sprint. If you are reading a guide that mixes them, it is describing something else.
Why the sprint’s odd rules exist
The schedule looks arbitrary until you see what each rule is defending against.
Working alone on Tuesday is the most counterintuitive part, and the best supported. In a classic set of four experiments, psychologists Michael Diehl and Wolfgang Stroebe found that real brainstorming groups produce fewer ideas than the same number of people working separately, mainly because people block each other while waiting to talk. The sprint pools individual work instead of running a group brainstorm.
Silent voting and anonymous sketches remove the advantage of whoever speaks first or holds the most senior title. If you have ever watched a roadmap meeting bend toward the first confident opinion, this is the fix built into the process, and it is the same dynamic covered in why the highest-paid opinion usually wins.
Five testers on Friday comes from Jakob Nielsen’s usability work, which estimates that five users uncover roughly 85% of the usability problems in a single design. The caveat matters: Nielsen’s math assumes one homogeneous user group and recommends several small rounds rather than one. If your product serves two very different customer types, five testers drawn from both will tell you less than you think. Who you put in those five chairs decides what Friday tells you, which is why recruiting is a discovery decision, not an admin task.
A named Decider is the rule teams skip most often and regret most. Without someone in the room who can commit resources, the sprint produces a recommendation that joins the normal approval queue, and the week’s speed advantage disappears by the following Tuesday.
The four-day version most teams actually run
Clearing seven calendars for five straight days is rarely possible inside a large company. In 2018 the facilitation agency AJ&Smart, which had run more than 200 sprints after the book came out, worked with Knapp on a compressed format usually called Design Sprint 2.0. Mapping and sketching happen on day one, deciding and storyboarding on day two, then prototyping and testing.
The practical change is who has to be present. The full group, Decider included, attends the first two days. After that, only the facilitator and the people building and testing the prototype stay. For most product organizations that is the difference between a sprint that gets approved and one that never gets scheduled.
The problem the sprint never solved
Here is the failure pattern that shows up again and again: a team runs a well-facilitated sprint, builds a polished prototype, gets enthusiastic reactions on Friday, and still ships something nobody needs. The sprint did its job. It answered the question it was given. The question was wrong.
The design sprint assumes you already know the customer, the problem, and roughly what kind of solution you want to test. Savioke knew all three. A team that has not settled those things will spend Monday arguing about them, and the map they produce will rest on assumptions nobody tested.
Knapp and Zeratsky addressed this directly in Click: How to Make What People Want, published in April 2025. The book introduces the Foundation Sprint, a two-day workshop designed to run before a design sprint. Their own Foundation Sprint guide lays out the agenda:
- Day one covers the basics (target customer, a problem painful enough to justify a new solution, the team’s advantage, and the toughest competitor, including “do nothing”) and then differentiation, ending in a one-page “Mini Manifesto.”
- Day two generates alternative approaches, scores them against a set of 2×2 charts the authors call “Magic Lenses,” and picks a top bet plus a backup.
The output is a single sentence, the Founding Hypothesis: “If we help [customer] solve [problem] with [approach], they will choose it over [competitors] because our solution is [differentiators].”
Two details stand out. First, the Foundation Sprint team is capped at five leaders, smaller than a design sprint room, because the decisions are strategic and the people making them need the authority to make them stick. Second, the authors say outright that the next step is a design sprint. The Foundation Sprint produces the hypothesis; the design sprint tests it. They describe it on the Click page as their best method for starting big projects, and position it for a period when AI makes building fast for everyone, so the scarce skill is choosing what to build.
For product managers this pairing is more useful than either half alone. If you have been using opportunity solution trees or assumption mapping to get to a clear bet, the Foundation Sprint is a compressed, facilitated version of the same thinking, with a hard stop at the end.
A decision rule for when to sprint
From the operations side, the most useful thing a sprint does is force a decision on a calendar. Over 20+ years in IT operations I watched plenty of large tooling and process changes drift for months because nobody owned the call and every review surfaced one more concern. The fix was rarely more analysis. It was getting the person with authority into a room with the people who knew the constraints, putting something concrete in front of the users, and agreeing in advance that the result would decide the next step. That is the design sprint’s real value, and it is why the Decider rule matters more than the sticky notes.
So before booking the room, answer four questions honestly:
- Can you name the customer and the problem in one sentence each? If not, run a Foundation Sprint first, or do the problem validation work that tells you whether the problem is worth solving.
- Is there a real choice to make? If the solution is already agreed and obvious, build it. A sprint that confirms a foregone conclusion wastes a week and teaches the team the process is theater.
- Can you recruit five of the right customers by Friday? If not, you have a workshop, not a sprint. Recruiting is the step most often underestimated; start it the week before.
- Will the Decider act on what Friday shows, including a “no”? If leadership will not change course regardless of the test, skip it.
If the question is small (a copy change, a single screen, a minor flow), a sprint is overkill. A round of usability testing or a pretotype will get you the answer in a day or two for a fraction of the cost.
What happens the Monday after
The sprint ends with a test, not a decision document, and that is where many of them stall. Three habits keep the result from evaporating:
Write up Friday within 24 hours. One page: what you tested, what the five customers did (not what they said they would do), and what the team recommends. If it takes a deck, nobody will read it.
Decide the next step before anyone leaves. The last 30 minutes of Friday belong to the Decider: build it, iterate and test again next week, or kill it. Knapp’s own recommendation after a Foundation Sprint is to keep testing prototypes weekly until the product clicks, which means a single sprint is often the first of several rounds, not the end.
Put the outcome where planning happens. A validated concept belongs in the next roadmap review and backlog conversation, not in a shared drive folder titled “Sprint Q3.”
A design sprint is a decision tool. Judge it by whether the decision it produced changed what your team built next. Savioke’s did. The week only mattered because, three weeks later, the robot was delivering toothbrushes for real.