Strategy-Led Innovation Playbook · Technique

Design Sprint

  METHOD · Jake Knapp, with John Zeratsky and Braden Kowitz, Sprint (2016), developed at Google Ventures. Design Sprint 3.0 is a separate, re-engineered variant by the Design Sprint Academy (John Vetan, 2019). Selection logic and decision integration on this page: Exponential Scout.

What a Design Sprint Is

A Design Sprint compresses months of debate into one week of structured decision-making. A small cross-functional team takes one significant question — should we build this, will customers understand this, which of these directions survives contact with a user — and moves from problem to tested prototype in four to five days. By the end of the week you are not holding opinions. You are holding a realistic prototype and the reactions of real users to it.

The sprint’s power is not creativity. It is compression and forced choice. Most organizations can generate ideas; few can decide between them quickly, and fewer still can put a decision in front of a customer before committing a quarter of engineering time to it. The sprint exists to fix that: structured individual work instead of group brainstorming, a single accountable decider instead of consensus, and a hard deadline that makes “let’s discuss further” impossible.

What a Sprint Is Not

Not a Scrum sprint. The name collision causes real damage. A Scrum sprint is a recurring delivery cadence for building software. A Design Sprint is a one-time decision-compression event. Recommending one when you need the other is a category error: Scrum will not tell you whether to build something, and a Design Sprint will not build it.

Not a substitute for discovery. A sprint accelerates reaching an evidence bar; it never lowers one. If you do not yet know whether the problem exists — who has it, how often, what they do about it today — a sprint will produce a beautifully tested solution to an unvalidated problem. Run Discovery first.

Not a workshop. A workshop ends with aligned stakeholders and a wall of sticky notes. A sprint ends with user evidence. If your week does not include real users reacting to a realistic prototype, whatever you ran was not a sprint.

When to Run One, and When Not To

Run a sprint when all four hold: the decision is large (expensive to get wrong), urgent (a deadline or a window), stuck (analysis has stopped producing movement), and testable (the concept can be faked convincingly in a prototype within a day).

Typical fits: a new product direction before committing a roadmap; a make-or-break feature where the team is split; a market entry where two credible concepts compete; a stalled initiative that needs evidence to break a leadership deadlock.

Do not run a sprint when:

The problem space is unmapped. No amount of prototyping resolves a discovery gap. Go to the Discovery Phase.
The decision is small. A sprint costs a team-week. Reversible, cheap decisions should just be made.
You cannot get users. Testing with colleagues is rehearsal, not evidence.
The decider will not attend. A sprint without its decision-maker produces recommendations, which is to say it produces nothing.
The blocking uncertainty is market, not usability. A sprint tests whether people understand and want to use a concept. It does not test whether anyone will pay, whether the economics work, or whether the channel exists. Those need different experiments.

The Arc of the Week

Every sprint variant follows the same underlying arc, whatever its day count:

Frame. Map the problem, hear from internal experts, and choose the one target the week will attack. The scope decision is the highest-leverage moment of the sprint; a vague target guarantees a vague result.
Diverge. Team members produce competing solution sketches — working alone, in structured silence, rather than brainstorming aloud. Individual work first, then exposure to the group, reliably outproduces open ideation, which rewards volume and confidence over quality.
Decide. The sketches are critiqued in a structured, time-boxed way, and the decider — one named person — picks what gets prototyped. Not a vote. A decision.
Prototype. Build a facade: something that looks and feels real to a user for fifteen minutes, built in a day. The prototype is a question wearing a costume, not a product.
Test. Five one-on-one sessions with people from the target segment. Patterns appear fast: by the third user you know which parts land and which confuse. You end the week with evidence.

The named facilitation exercises that structure these days — the sketching formats, the critique rituals, the voting mechanics — belong to their authors. Knapp’s Sprint (2016) teaches the original five-day format step by step; the Design Sprint Academy’s 3.0 materials teach their re-engineered four-day variant with an added problem-framing front end. For facilitation detail, go to the sources; both are excellent and they are not the same method.

Roles

The Decider. One person with the authority to commit to the outcome — and accountability for implementing it. If the decider cannot commit the week, shrink their role to the two decision moments, but never remove it.
The Facilitator. Neutral, ruthless about time, owns the process so the team can own the content. Facilitation is a skill; a first-time facilitator with a high-stakes sprint is a bad pairing.
The team. Four to seven people spanning design, engineering, the business, and — non-negotiably — someone who knows the customer from direct contact, not from dashboards.

The Decision Discipline (the part most sprints skip)

A sprint is an evidence event, and evidence events need pre-registered decisions. Before Day 1, write three things down:

The decision this sprint informs. Not the question you are curious about — the resource-allocation decision the evidence will feed.
The threshold. What user behavior on Friday would justify advancing? What would kill the direction? Write both before you see a single test.
The owner. Who acts on the result, and by when.

A sprint that ends with “great learnings” and no decision was an expensive workshop. The Friday evidence maps directly to three outcomes: advance (behavior met the bar — move to validation of the business assumptions the prototype could not test), iterate (the concept communicated but a specific element failed — fix and re-test that element, not the whole sprint), or kill the direction (users did not understand or did not care — which is the sprint doing exactly what you paid it for: killing a bad direction in one week instead of two quarters).

Cost and Return

Count the cost honestly: a team-week (5–7 people at loaded day rates), facilitation, participant incentives, and the opportunity cost of everyone’s paused work. Weigh it against the avoided cost of the alternative: N weeks of development on a direction that would have failed on first user contact. The arithmetic usually favors the sprint precisely when the four conditions above hold — large, urgent, stuck, testable — and usually does not when they fail. That is not a formula; it is the judgment call, and it should be made before the sprint, in writing, like everything else.

Variants and Remote Formats

The format has evolved: four-day compressions, remote sprints on shared whiteboard tools, and specialized shapes (problem-framing sprints before the sprint proper, technical-feasibility sprints, strategy sprints). The arc — frame, diverge, decide, prototype, test — survives every variant; the day boundaries move. Choose the variant by the decision at stake, not by novelty.

A Day-by-Day Guide (Four-Day Format)

A four-day schedule, with a problem-framing session before it. Times are a guide: protect the sequence, not the clock.

Before the sprint: problem framing (half a day to a full day)

Who attends: the main stakeholders (usually executives), the person who will be the sprint’s Decider, key domain experts, and someone who speaks for customers.

Business context (60 min): strategy and current objectives, current metrics, market and competitors, priorities and constraints.
Problem exploration (90 min): each person writes possible problems; cluster them; map impact against effort; tie each problem to customer evidence you already have.
Challenge definition (60 min): the sprint goal, how success will be measured, what is in and out of scope, and the technical, business and resource limits.

You leave with a sprint challenge tied to strategy, the right team for it, stakeholders committed to acting on the result, and success criteria written down before the sprint starts.

Day 1: Understand and define

9:00 to 9:30, Kickoff: introductions and roles, the sprint goal from problem framing, ground rules and timeline.
9:30 to 11:00, Lightning talks: each team member takes 5 to 7 minutes on the problem (insights, experience, concerns, opportunities). Review the pre-sprint research.
11:15 to 12:30, Map: build a customer journey map from the research. Mark touchpoints, pain points and where improvement would matter most, and add the business and behavior data you have.
1:30 to 2:30, How Might We: everyone writes How Might We questions; cluster them, vote, and keep the 3 to 5 that matter most.
2:45 to 3:45, Sprint goal and questions: note and vote, debate, then fix one measurable goal for the week and 2 to 4 sprint questions.
3:45 to 4:45, Target: choose the part of the map to attack, weighing impact against what can realistically be prototyped and tested. The Decider makes the call.
4:45 to 5:00, Homework: each person finds solutions to similar problems in other fields and prepares a 3-minute lightning demo.

Day 2: Ideate and decide

9:00 to 9:45, Lightning demos: 2 or 3 examples each, 3 minutes per person. Capture features worth borrowing.
9:45 to 10:00, Evil 8s: eight deliberately bad solutions in eight minutes, to loosen the room. Bad ideas sometimes reveal good ones.
10:15 to 12:00, Solution sketch, working alone: notes (20 min), ideas (20 min), Crazy 8s (8 variations in 8 minutes), then a detailed, self-explanatory sketch with a title (45 min or more).
12:00 to 1:00, Art museum and speed critique: post sketches anonymously and review them in silence (15 min), heat-map dot voting (15 min), a quick critique of each (30 min).
2:00 to 2:15, Decision: straw poll, then the Decider picks one or two solutions to prototype. Write down why.
2:15 to 3:45, Storyboard: plan the test scenario (30 min), then a 6 to 15 panel storyboard of the user’s experience, including the key moments and decisions (60 min).
4:00 to 5:00, Review and prep: close gaps, finalize the storyboard, assign Wednesday’s roles, and list the content and assets needed.

Day 3: Prototype

9:00 to 9:30: look at the storyboard again with fresh eyes, adjust it, and confirm the scope fits one day.
9:30 to 10:00: assign roles, break the prototype into parts, set milestones.
10:00 to 5:00, Build:
- Makers (1 or 2) build the screens or pieces users will see, realistic enough to test.
- The Stitcher (1) joins the pieces into one flow that tells the whole story.
- The Writer (1) writes realistic copy, including error messages and edge cases.
- The Asset collector (1) gathers images, icons and data, and keeps the look consistent.
- The Interviewer (1) writes the test script, sets up the room, and recruits and confirms five testers.

Prototype rules: a facade that looks real but doesn’t work underneath; only what the test needs; real enough to get genuine reactions; stop building when time is up.

Day 4: Test and learn

9:00 to 10:00: check the prototype end to end, test the devices, set up the room and recording, finalize the script, brief the team.
10:00 to 4:45: five one-hour interviews, starting at 10:00, 11:15, 1:15, 2:30 and 3:45. Each one runs:
- welcome and consent to record (5 min)
- background questions to confirm the person fits the target profile (10 min)
- the prototype walk-through, with the tester thinking aloud and the interviewer observing without leading (35 min)
- closing questions on overall impressions and specific moments (10 min)
While the interviews run, the team records behaviors, exact quotes, patterns across testers, and which sprint assumptions were supported or challenged.
4:45 to 5:00, Findings: the main patterns, which beliefs held and which didn’t, the key insights, and next steps.

Five interviews show how people react to a prototype. They tell you whether a direction is worth pursuing, not whether customers will pay. Treat the result as evidence for Discovery, and write the pass/fail line for your next test before you run it.

Go Deeper

Jake Knapp, John Zeratsky, Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016) — the original method, step by step.
Design Sprint Academy — Design Sprint 3.0, John Vetan’s re-engineered variant with a dedicated problem-framing phase. A separate method by a separate organization; do not conflate the two.
When the decision at stake is large enough that facilitation quality matters, this is a standing escalation point: Schedule a working session →