Design Sprint
The Design Sprint is a five-day process developed at Google Ventures by Jake Knapp (with John Zeratsky and Braden Kowitz) for solving critical business questions through rapid prototyping and customer testing. Rather than months of development followed by a product launch, the sprint compresses the learning cycle to one week — producing a realistic prototype that can be tested with real customers before any significant investment is committed.
“Identifying critical flaws after just five days of work is the height of efficiency. It’s learning the hard way, without the ‘hard way.‘”
— Sprint
“Get that surface right, and you can work backward to figure out the underlying systems or technology. Focusing on the surface allows you to move fast and answer big questions before you commit to execution.”
— Sprint
The Core Problem the Sprint Solves
Most product failures happen not because of bad execution but because of wrong assumptions. Teams build for months, then discover that customers don’t understand or care about what was built. The sprint inverts this: test assumptions with the minimum viable representation before committing to build.
“When our new ideas fail, it’s usually because we were overconfident about how well customers would understand and how much they would care.”
— Sprint
The Five-Day Structure
Monday: Map and Target
The team maps the problem space, creates a simple customer journey map, and identifies the most critical moment to focus on. Expert interviews surface distributed knowledge from across the organization. “How Might We” (HMW) notes capture insights in the form of solvable questions.
Key outputs:
- Long-term goal (where do we want to be in 6–12 months?)
- Sprint questions (what assumptions must be true for the goal to be achieved?)
- A simple map of the customer journey
- A specific target: one customer type, one critical moment
“After interviewing the experts and organizing your notes, the most important part of your project should jump right out of your map, almost like a crack in the earth.”
— Sprint
The Monday exercise “starting at the end” forces pessimistic thinking: if the project fails in one year, what caused the failure? This converts assumptions and risks into explicit sprint questions.
Tuesday: Sketch Solutions
Individuals (not groups) sketch competing solutions. The day begins with Lightning Demos — three-minute tours of inspiring ideas from other products and domains.
“We know that individuals working alone generate better solutions than groups brainstorming out loud. Working alone offers time to do research, find inspiration, and think about the problem.”
— Sprint
The sprint explicitly rejects traditional brainstorming in favor of individual parallel work. This avoids groupthink, anchoring, and social conformity — all of which reduce the quality of ideas generated by group processes.
The sketching process follows four steps: notes, doodles, crazy 8s (eight rapid rough concepts in eight minutes), and a single solution sketch with three annotated panels.
Wednesday: Decide
The team critiques all solutions and selects one to prototype. The process:
- Art museum: Solutions go on the wall silently
- Heat map: Dot stickers mark interesting elements
- Speed critique: Facilitator narrates each solution’s highlights; a Scribe captures ideas
- Straw poll: Each team member votes
- Supervote: The Decider makes the final call
“Sometimes when people work together in groups, they start to worry about consensus and try to make decisions that everybody will approve—mostly out of good nature and a desire for group cohesion… Well, democracy is a fine system for governing nations, but it has no place in your sprint.”
— Sprint
Wednesday afternoon produces a storyboard — a step-by-step plan for the prototype, approximately 10–15 frames representing the customer’s journey through the product.
Thursday: Prototype
The team builds a realistic but disposable prototype in one day. The “Goldilocks quality” standard: realistic enough that customers react honestly, disposable enough to build in eight hours.
“The ideal prototype should be ‘Goldilocks quality.’ If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish.”
— Sprint
Roles are divided: Makers (build components), Stitcher (assembles them coherently), Writer (ensures realistic copy), Asset Collector (gathers existing imagery/content), Interviewer (prepares for Friday).
Key insight: the longer you work on something, the more attached you become, and the less receptive you are to negative feedback. One day is the correct amount of time to invest before testing.
Friday: Test and Learn
Five interviews with target customers. Each interview follows a structured format: warm-up, context questions, prototype interaction with think-aloud protocol, debrief. The rest of the team watches a video stream from another room and takes notes in a shared grid — one column per customer, one row per prototype section or sprint question.
Five interviews is the magic number:
“With only five interviews, it’s important to talk to the right people.”
— Sprint
Research consistently shows that five usability test participants surface approximately 85% of usability issues. More interviews yield diminishing returns.
At the end of Friday, patterns emerge across the five customers. The team looks for consistent reactions — both positive (clues about what to build) and negative (critical flaws to address or eliminate).
The Prototype Mindset
The sprint embeds a specific philosophy about prototypes:
“Prototype mindset. You can prototype anything. Prototypes are disposable. Build just enough to learn, but not more. The prototype must appear real.”
— Sprint
This extends to non-digital products. A service can be prototyped with a script and human actors. A physical product can be prototyped by showing the marketing brochure or website that would sell it (the “Brochure Facade”).
Tony Fadell’s Complementary View
Build reinforces sprint thinking at a higher level. Fadell argues that teams should prototype the entire customer journey — not just the product:
“Don’t just make a prototype of your product and think you’re done. Prototype as much of the full customer experience as possible.”
— Build
Fadell also uses the “write a press release first” technique — similar to the sprint’s goal-setting discipline — to force clarity about what success looks like before building begins.
The Sprint’s Best Uses
Knapp identifies optimal conditions for a sprint:
- High-stakes decisions with a lot at risk
- Not enough time (real-world pressure to converge quickly)
- “Stuck” teams who have been discussing the same problem without resolution
- New concepts with deep customer uncertainty
“You can run a sprint anytime you’re not sure what to do, or struggling to get started, or dealing with a high-stakes decision. The best sprints are used to solve important problems.”
— Sprint
Conflict and Limitations
The design sprint optimizes for speed of learning, not depth. Five customer interviews in one city cannot replace longitudinal research across diverse markets. The sprint is a diagnostic tool, not a substitute for ongoing user research. It answers "does this direction have promise?" — not "have we found definitive product-market fit?"
Related Concepts
- Product-Market Fit — What the sprint helps validate or disprove in five days
- Disruptive Innovation — The sprint is particularly valuable when exploring disruptive directions with no market data