Most big product bets are settled in a meeting room and paid for in a build. Someone is sure the new feature will land; someone else is sure it won't; the loudest voice or the most senior one breaks the tie, and the engineering team spends the next quarter finding out who was right. A design sprint flips that order. Before anyone writes production code, you put a realistic fake of the idea in front of five real customers and watch what they do.

The quick version

  • A design sprint is a structured five-day process, map, sketch, decide, prototype, test, for answering a high-stakes product question fast. It was created by Jake Knapp at Google and refined at Google Ventures.
  • The payoff is learning before building: by Friday you have watched real customers react to a prototype, so you find out if the idea is wrong in a week, not a quarter.
  • It works best in the “Goldilocks zone”, a problem big enough to matter, small enough to test, with a clear question and a decision-maker in the room all week.
  • It is a way to de-risk a decision, not a way to ship a finished product. The output is validated learning and a tested direction, not release-ready code.

The idea in depth

The design sprint was created by Jake Knapp at Google in 2010 and developed further at Google Ventures (GV) from 2012, with Braden Kowitz, John Zeratsky, Michael Margolis and Daniel Burka. GV defines it plainly: “a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers” (gv.com/sprint). Knapp, Zeratsky and Kowitz later wrote it up as Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (Simon & Schuster, 2016) after running the process at more than a hundred companies.

The five days each have one job. Monday you map the problem and “start at the end”, agree the long-term goal, chart the challenge, and pick one target worth a week. Tuesday everyone sketches competing solutions on paper, alone, instead of brainstorming out loud. Wednesday you critique those sketches and decide which one to build, turning the winner into a storyboard. Thursday you adopt a “fake it” philosophy and build a prototype that only looks real. Friday you interview five customers and watch them use it. The shape matters because it forces a team to converge: every day narrows from many options to one testable thing.

flowchart LR
    A(["Mon · Map
frame the problem"]) --> B(["Tue · Sketch
solutions on paper"])
    B --> C(["Wed · Decide
pick one, storyboard"])
    C --> D(["Thu · Prototype
a realistic fake"])
    D --> E(["Fri · Test
5 real customers"])
    E -.->|what we learned| A
The five days of a design sprint, each narrowing toward one tested idea. Leaders Loop

Two of those choices are doing more work than they look. Sketching alone, then voting, is a deliberate fix for the way groups generate ideas, the first loud idea anchors the room and the rest of the conversation orbits it. By giving everyone paper and silence first, the sprint surfaces options that would never survive a live brainstorm. This is the same instinct behind the structured methods in ideation & co-creation: separate generating ideas from judging them. You can borrow the trick without running a whole sprint, on your next contested decision, ban the open brainstorm and have everyone write their proposal privately before anyone speaks.

The other quiet engine is the prototype. The sprint insists you build something that looks finished but is hollow, a clickable façade, a fake landing page, a hand-assembled screen flow. People react honestly to a thing they can touch and dishonestly to a description of it. The limitation worth naming up front: a sprint prototype is theatre, not product. It is built to provoke a reaction, not to ship, and treating Friday's tested mock-up as “nearly done” is how teams talk themselves into skipping the actual engineering. The sprint de-risks the decision; it does not shorten the build.

What the sprint actually buys you

The honest case for a sprint is not speed for its own sake. It is the cost of being wrong. A normal product cycle hides its mistakes until launch, when they are expensive to unwind. A sprint pays a small, fixed price, one week of a handful of people, to surface the biggest mistake while it is still cheap to change your mind. You are buying an early answer to the question “are we even building the right thing?”

A sprint doesn't make you faster. It makes you wrong sooner, while wrong is still cheap.

That framing also sets the boundary. The Nielsen Norman Group, the long-running usability research firm, places the sprint among the workshop formats and is clear that it suits a particular size of question, too small a problem (“what colour should this button be?”) wastes the week, and too large a one (“how do we enter the EMEA market?”) can't be prototyped in five days. C. Todd Lombardo, writing in Mind the Product (2016), adds the other guardrails: don't sprint when the product is already validated and agreed, when you have done no prior customer research to draw on, or when the people who can actually make the decision won't be in the room. Before you book anyone's week, then, run a two-minute pre-flight check: is the question in the Goldilocks zone, is there a real decision-maker committed to attending, and is there enough customer insight to build on? If any answer is no, fix that first. A sprint won't manufacture it for you.

It's also worth knowing the format has loosened since 2016. Knapp has endorsed a four-day variant (often called Design Sprint 2.0, popularised by the agency AJ&Smart) that folds the original sketch and decide days together; Knapp's own caveat is that the shorter version works best when the facilitator is experienced or the team has run sprints before. The five-day book version remains the safer default for a first attempt. The point for a leader: the days are scaffolding, not scripture, the non-negotiable is the arc from framing to a real customer test, not the exact timetable.

flowchart TD
    Q(["A big, contested
product question"]) --> G{"In the Goldilocks zone?
big enough to matter,
small enough to test"}
    G -->|no, too small| S(["Just decide and ship
skip the sprint"])
    G -->|no, too big| B(["Break it down first
into a testable slice"])
    G -->|yes| D{"Decision-maker in
the room all week?"}
    D -->|no| F(["Don't sprint yet
secure the Decider"])
    D -->|yes| R(["Run the sprint"])
A quick pre-flight: most failed sprints are failures of fit, decided before day one. Leaders Loop

A worked example

Picture a regional café-supplies company, illustrative, not a real case, whose leadership is split over a proposed self-service ordering portal. Sales swears customers want to phone a human; the digital team is convinced the phone is the bottleneck losing them small accounts. The default path is to build a basic portal over a quarter and see what happens. Instead they run a sprint.

Monday they map the ordering journey and pick one target: a first-time café owner placing a weekly order. Tuesday four people sketch rival portal flows on paper. Wednesday they vote, and the winner is a deliberately stripped-back “repeat my last order in two taps” flow, not the feature-rich catalogue Sales expected. Thursday a designer builds a clickable prototype that looks like a live site but is held together with screenshots. Friday they put it in front of five café owners.

The result (illustrative figures): three of the five sailed through and said they'd switch, but every single one hunted for a “something's wrong with my order, call me” button that didn't exist, and stalled when they couldn't find it. That is the kind of finding a quarter-long build surfaces only after launch, in churn data and angry emails. Here it cost a week, and it dissolved the original argument: the answer wasn't “portal” or “phone,” it was “portal with an obvious human escape hatch.” The sprint didn't build the product. It told them what product to build, and which executive's hunch to trust.

Frequently asked questions

Is a design sprint the same as an agile sprint?

No, and the shared word causes real confusion. An agile (Scrum) sprint is a one-to-four-week cycle of building and shipping working software. A design sprint is a five-day process of deciding and testing before you build, and it produces a prototype, not a release. One narrows a question; the other delivers increments of the answer.

Do I really need five whole days from busy people?

The time cost is the point of contention and the source of the value. The honest trade is one fixed week now against the open-ended cost of building the wrong thing later. If you can't clear the diaries, that's often a signal the question isn't yet important enough to sprint on, or that you should run the four-day variant with an experienced facilitator.

Why only five customers on Friday?

Because qualitative usability testing hits sharply diminishing returns: a handful of users reveals most of the serious problems in a flow, and a sixth or seventh mostly repeats what the first five already showed. The sprint isn't measuring how many people like it, that needs a larger study. It's looking for the showstoppers, and five is enough to find them. See usability & guerrilla testing for the underlying method.

What if the prototype tests badly?

Then the sprint did its job. A bad result on Friday is the cheapest bad result you will ever get, it cost a week instead of a quarter. The failure mode to avoid is rationalising the result away (“they didn't understand it”) instead of changing the idea. Watching customers struggle is the data; defending the design against them is not.

Does it replace ongoing customer research?

No. A sprint is most effective when it sits on top of existing insight, the Monday map is far better when the team already knows its customers. Treat it as a way to act on research under pressure, not a substitute for doing the research in the first place.

Related in the Toolkit

Where to go next