The Five-Day Design Sprint
Go from zero to a tested prototype in five days — decide with customer reactions, not hunches
- Difficulty
- Advanced
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 92%
The design sprint is a scripted, five-day recipe that takes a team from a blank start to a realistic prototype and a real customer test of that prototype. Its purpose is to replace the perfect plan, the perfect PRD and the perfect exec pitch with something concrete people can click, and to evaluate strategy on observed customer reactions rather than on a hunch or a guess. It changes team defaults the same way Make Time changes individual defaults: how time is spent, how people interact, and how decisions get made.
Origin
Created by Jake Knapp. The seed was a week in the 2000s when Knapp, a Gmail product designer, flew to Stockholm and, with two colleagues, cleared the decks for one focused week on a 20% side project that had been going nowhere for eighteen months — building a working prototype instead of chasing the perfect plan. That project became Google Meet. He and Zeratsky then ran hundreds of sprints with startups at Google Ventures, refined the process, and published Sprint. They now run sequences of sprints at their VC firm, Character (with colleague Eli), to help portfolio companies find and expand product-market fit.
Core principles
- 01A prototype beats a plan — build the thing people can see and click, not the perfect PRD or pitch deck.
- 02Compress the whole loop into five days so an idea is contained rather than allowed to sprawl for months.
- 03Judge ideas on customer reactions you can actually observe, not on hunches, guesses or seniority.
- 04For startups, runway is the real constraint: the faster you learn, the sooner you can course-correct.
- 05Sprints pay off most where there is a big behavioral risk — where customers must be persuaded to trust or change how they work.
- 06Change the team's defaults for the week: how time, technology and interaction happen are all under deliberate control.
How to run it
- 1
Qualify the problem for behavioral risk
Before running a sprint, check whether the opportunity carries a genuine behavioral risk — customers must trust something they don't yet trust, or change how they work. Sprints are wasted on incremental improvements to something that already exists.
Pro tip AI products are a strong fit: the output can feel alien, trust is not yet earned, and the behavior shift is large.
Watch out If you're just making an existing thing slightly cheaper, faster or easier to use, you probably don't need this — you can likely just build it.
- 2
Clear the decks and change the defaults
Get the team into one focused week with everything else cleared off. Deliberately control how the day is structured, how technology is used, and how people interact — the same default-changing logic as Make Time, applied to a team.
Pro tip This is where the Make Time system originally came from — the individual tactics were reverse-engineered from what worked in sprints.
Watch out A half-committed sprint with people dipping back into their normal defaults is not a sprint.
- 3
Run the scripted sequence to a prototype
Follow the recipe — a scripted set of activities that carries the team from abstract concepts and discussion into a concrete, clickable prototype within the week, instead of arguing over the ideal plan.
Pro tip Free step-by-step resources exist at thesprintbook.com, including a Miro template with instructions for every step and 30+ videos of Knapp explaining each one.
- 4
Test the prototype with real customers
Put the prototype in front of real people (or, in the Google Meet origin case, colleagues) and watch them use it. The reaction — not the internal debate — is the decision input.
Pro tip The prototype only needs to be realistic enough for a person to react to, not real enough to ship.
Watch out Skipping the test collapses the sprint into an expensive brainstorm.
- 5
Sequence sprints for compounding learning
For hard problems, run a sequence of sprints rather than a one-off — each cycle course-corrects the last. Character runs a four-week sprint sequence for pre-seed software startups in its Labs program.
Pro tip Best fit: teams who know the market and opportunity they're attacking but definitely have not reached product-market fit, and may not even have a product yet.
In the wild
A 20% side project had been going nowhere for a year and a half and was on the rocks. Knapp visited the two other people involved in the Stockholm office, and for one focused week they cleared everything off and built a working prototype rather than chasing the perfect plan, PRD or exec pitch, then put it in front of colleagues and got them using it.
→ That was the thing that stuck — the project became Google Meet, and the experience convinced Knapp to codify the format so those moments could be recreated on demand.
A Character portfolio company, founded by ex-Google DeepMind people who had run AI control for Google's data centers, sells AI that controls industrial facilities. Their challenge is convincing plant operators in hard hats dealing with huge equipment to trust AI.
→ Knapp and Zeratsky cite it as the archetypal sprint use case — high behavioral risk, big trust hurdle, technology that can plainly help if people can get over the hurdle.
Common mistakes
Chasing the perfect plan instead of a prototype
The Google Meet project stalled for eighteen months trying to produce the perfect plan, PRD and pitch to executives. The unlock was building something people could actually use and reacting to that.
Running a sprint on a low-behavioral-risk idea
If your product is a slightly cheaper, faster, easier version of an existing thing, the sprint machinery is overkill — you can probably just build it and it will probably work.
Letting an idea sprawl instead of containing it
Without a five-day box, a new idea distracts the team for months and stays theoretical. The time-box is what makes the exploration affordable.
Is it for you?
Best for
Pre-product-market-fit startups and product teams facing a big behavioral or trust risk (AI, healthcare, education) who need to test a concrete idea fast
Not ideal for
Incremental improvements to an existing, already-trusted product where the behavior change asked of the customer is small
From the transcript
“the big idea with a design Sprint is to go from a zero to a prototype and a test of that prototype in just five…”
“we're like let's just build a prototype and put it in front of our colleagues and get them using it and we did that and…”
“we run hundreds of these at Google Ventures with startups tweaked and refined the process wrote this book called Sprint”
“what we find is that the more there's a there's kind of a big behavioral risk the the better this stuff works”
From the episode
Making time for what matters
Jake Knapp and John Zeratsky (authors of Sprint and Make Tim