Design Sprints

---

Origins

The Design Sprint was developed by Jake Knapp during his time at Google and later refined at Google Ventures (now GV), the firm's venture capital arm. Knapp and his collaborators Braden Kowitz and John Zeratsky published the canonical version of the method in 2016 as Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days¹.

The format draws on several traditions — design thinking from IDEO and Stanford's d.school, the lean startup tradition of fast validation, and the rapid prototyping practices of Google's own product teams. What Knapp's version added was a precise, time-boxed structure that gave non-design-led teams a way to do focused customer-validated design work in less than a week. A great deal of the format's appeal is that it has an agenda: a team can run a Design Sprint without having to first invent how to run one.

What a Design Sprint Is

A Design Sprint is a five-day workshop in which a cross-functional team takes one significant product question from problem to validated prototype. Each day has a specific focus and clear deliverables.

The sprint compresses what would otherwise be months of design conversation into a single intense week. The compression is intentional — it forces convergence rather than letting discussion sprawl. By Friday, the team has tested a real prototype with real users and has evidence to act on.

The Five Days

Monday — Map

The team aligns on the problem. They listen to a series of "lightning talks" from experts (internal stakeholders, customer-facing colleagues, technical leads) to gather context. They draw a high-level map of the customer journey. By the end of the day, they pick a specific target on the map — the part of the problem the sprint will focus on. The target is one user, one moment, one outcome.

Tuesday — Sketch

Each team member independently sketches solutions to the target. The day starts with "lightning demos" of relevant inspiration from outside the team's normal references. Then individual sketching: a four-step structured process that produces a detailed solution sketch from each participant. No talking during sketch time. The sketches are deliberately rough; the point is variety and individual thinking, not polish or consensus.

Wednesday — Decide

The team reviews the sketches as a gallery, votes on the most promising ideas, and the Decider makes the final call. The chosen sketches are combined into a single storyboard — a step-by-step plan of what the prototype will need to demonstrate. By the end of Wednesday, the team has a clear, ordered set of frames to build on Thursday.

Thursday — Prototype

The team builds a realistic facade. Not a working product — a prototype convincing enough that test users will react authentically. Most Design Sprint prototypes are clickable Keynote, Figma, or paper mockups with just enough fidelity to feel real for 15 minutes of user testing. The Maker, Stitcher, Writer, and Interviewer roles divide the work to ship the prototype by end of day.

Friday — Test

Five real customers test the prototype in 1-on-1 sessions, while the rest of the team watches from another room. Jakob Nielsen's research on usability testing showed that five participants surface most major issues; the Design Sprint adopted that number. After the fifth session, the team debriefs: what did we hear, what surprised us, what do we do Monday?

The Roles

The Decider

The single most important role. The Decider is the person with authority to call the final shot on what gets prototyped and tested. Without a Decider in the room, the team converges through committee and rarely reaches the sharp focus the sprint requires. The Decider is usually a senior product or business leader.

The Facilitator

Runs the timeboxes, owns the agenda, ensures the sprint moves on schedule. The Facilitator should have run sprints before — the format depends on disciplined facilitation. They are not the Decider; they own the process, not the content.

The Team

5–7 people total, cross-functional: product, engineering, design, customer-facing roles. Larger teams water the discussion; smaller teams miss perspective.

When a Design Sprint Works

• The problem is significant enough to justify five days of senior people in one room.
• The team can clear the calendar — phones away, no parallel meetings.
• There is a real Decider with authority to make the calls.
• Customer access exists — five suitable test participants can be recruited in time for Friday.
• The team is willing to act on what testing reveals, including walking away from the direction.

When It Doesn't

• The team already has a strongly committed direction and is looking for endorsement rather than validation.
• The problem is too narrow for five days of work — or too broad for a single prototype to test.
• No Decider is available, or the Decider can only attend "part of the time."
• The team cannot recruit relevant test participants in time.
• The output won't be acted on — the sprint is theater rather than a real bet.

Variations

The original five-day format has spawned shorter variations as practitioners adapted it for different contexts.

• 4-day sprint: Map and Sketch compressed into one day. Sacrifices depth for speed; works best for clearer problem spaces.
• 3-day sprint: Often used for less-novel problems or focused feature decisions. Time is mostly cut from Map.
• Remote Design Sprint: Knapp's later work formalizes a fully-remote version using Miro, Zoom, and digital sketching tools. Slightly longer than in-person sprints because remote conversation moves slower.
• Asynchronous sprint: Some teams stretch a sprint over two weeks to accommodate distributed time zones. Effective when the team has the discipline; loose when they don't.

Common Pitfalls

• No Decider: the sprint produces consensus-shaped mush. Knapp is explicit that without a Decider the format does not work.
• Skipping Friday's test: "we ran out of time, we'll test next week" produces a sprint that delivers a prototype with no customer feedback — the whole point of the format was Friday.
• Wrong target on Monday: a problem definition that is too vague or too sweeping produces a prototype that can't be meaningfully tested. Push to be specific.
• Team too large: 10+ people in the room slows everything down and dilutes accountability. Stay at 5–7.
• Pre-baked solution: a team that arrives with the solution already decided wastes the sprint on confirming what they already believed.
• No follow-through: Monday after the sprint, the team is in regular meetings and the sprint outputs gather dust. Plan the post-sprint work before the sprint starts.

Coaching Tips

Confirm the Decider

Before scheduling the sprint, confirm the Decider can be in the room for all five days. If they can only attend "key parts," reschedule or run a different format.

Lock the Calendar

Phones in a basket. No parallel meetings. The five days are the bet; protecting them is the first job of the Facilitator and Decider.

Recruit Test Users Early

Friday's customer testing depends on having the right five participants. Start recruiting before Monday — not Wednesday.

Pick a Specific Target

"Improve our onboarding" is too vague for a sprint. "What would convince a new user to invite a teammate in their first session?" is testable. Push for specificity Monday.

Resist Polish on Thursday

The Thursday prototype should be just real enough for testing. Engineers who try to make it actually work will burn the day. Coach toward facade, not function.

Plan Next Monday Now

Before the sprint ends, the team needs to know what happens with the result. Without that plan, the sprint outputs go on a shelf and the energy fades by Tuesday.

Summary

The Design Sprint is one of the most adopted workshop formats in product work, and one of the most often misapplied. The full five-day discipline — one team, one room, a real Decider, five customers on Friday — produces remarkably strong evidence for the design direction it tests. The lighter versions (skipping Friday, no Decider, "we'll test later") produce something that resembles a sprint but rarely produces sprint-quality output.

Treat the sprint as a bet, not as a workshop. The cost of the five days is significant; the cost of skipping the format's hardest constraints is higher, because the team walks away believing they validated something they only debated.

Back to Discovery Workshops