Training · Cross-cuttingTrackprovenverified

Design Sprint

also known as Google Ventures sprint, GV sprint, five-day sprint, Knapp sprint

Tags: design-sprintfive-dayprototypeuser-testingproduct

A structured five-day process for answering critical business questions through design, prototyping, and testing ideas with real users — compressing months of iterative development into a single focused week. Jake Knapp created it at Google starting in 2010 and refined it at GV (Google Ventures) with Braden Kowitz, Michael Margolis, John Zeratsky, and Daniel Burka. It was published in Knapp's 2016 book Sprint. The GV website defines it as 'a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.' The design sprint's educational value is distinct from its product value. Participants learn to move from an ambiguous problem to a testable hypothesis to real user data in five days. They practise the cognitive moves of product reasoning, rapid prototyping, and hypothesis-driven decision-making under time pressure.

How the learner advances

Intent. Move a team from a critical, ambiguous question to real user validation data in five focused days — replacing months of assumption-driven iteration with one week of structured learning.

When to apply. Apply when a team faces a critical, ambiguous question that would otherwise generate weeks of inconclusive debate or months of build-then-discover cycles. Use a design sprint when the question is genuinely open — not 'how do we implement this?' but 'should we build this at all, and in what form?' A realistic prototype must be buildable in one day. Real target users must be recruitable for Friday testing. A decision-maker who can commit to next steps must be present throughout the week. Do not use a design sprint when the question has already been decided. Running a sprint to create the appearance of process is the most common misuse.

Threshold — earns the next step. The team can move from an ambiguous question to a tested prototype in five days, and can articulate what they learned from real user feedback that they could not have learned from internal discussion.

Masterpiece — the artifact that proves it. A tested prototype and a documented set of user observations that directly answers the sprint question — with clear evidence for what to do next, based on data from real users rather than internal assumptions.

Facets

  • Container — workshop
  • Mode — appliedcollaborativeconcept
  • Reach — team
  • Persona — developermanager-leaderanalyst-ops
  • Craft (AI Fluency) — synthesisdiscernmentcollaboration
  • Learner — human
  • Trainer — human

Inputs

  • Sprint team (4–7 people) — A cross-functional team including a decision-maker (who must be present and empowered to commit), a designer, an engineer, a domain expert, and a customer research lead. The decision-maker's authority and presence is non-negotiable — without it, the sprint produces recommendations, not decisions.
  • Critical business question — A specific, answerable question about a product, service, or strategy where the cost of being wrong is high and the current path is unclear. The sprint is for questions where rapid learning is more valuable than additional planning.
  • Five uninterrupted working days — The full team's calendars cleared for Monday through Friday with no competing meetings or obligations. A team that is also doing their regular jobs during sprint week does not run a sprint — they run a meeting series.
  • Five real target users for Friday — Actual members of the target user population, recruited before the sprint begins, available for one-hour individual interviews on Friday. Without real users, the sprint produces a prototype but no validation data.

Outputs

  • A more capable learner — A team member who has practised the full product reasoning cycle — from ambiguous question to testable hypothesis to prototype to real user data — in five days, making those cognitive moves faster and more reliable in future work.
  • Validated or invalidated prototype with user data — The masterpiece: a realistic prototype tested with five real users, accompanied by documented observations about what worked and what did not — answering the sprint question with real evidence rather than internal debate.

Steps (5)

  1. Monday — map and set the target

    The team establishes the long-term goal and maps the problem space end-to-end — from customer first contact to resolution. They consult internal experts through structured 'How Might We' interviews. Then they select one specific moment in the map to target for the sprint. The day ends with one focused target chosen by the decision-maker.

  2. Tuesday — sketch competing solutions

    Each team member sketches their own solution to the target using a structured four-step method: notes, ideas, crazy-8s (eight sketches in eight minutes), and a solution sketch. Solutions are individual and diverse — the goal is divergence before convergence.

  3. Wednesday — decide and storyboard

    The team critiques Tuesday's sketches using silent voting and structured discussion, selects the most promising approach (the decision-maker has final authority), and builds a step-by-step storyboard — the blueprint for Thursday's prototype.

  4. Thursday — build a realistic prototype

    The team builds only the customer-facing surface of the prototype — realistic enough that users will react to it genuinely, using the fastest tools available. Engineers focus on the façade; the prototype does not need to work under the hood. The goal is something testable by Friday morning.

  5. Friday — test with real users

    One team member interviews five users one-on-one, following a prepared script but reacting to what users actually do. The rest of the team watches a live stream and takes structured notes. By end of day, the team has real user data answering the sprint question — and a clear decision about next steps.

Principles

  • Real user data beats internal debate — any internal discussion of what users will think or do is worth zero compared to one hour of watching a real user interact with a prototype.
  • The prototype is not the product — building only the façade needed for testing is a skill, not a shortcut. The decision to not build the backend is the design sprint's most important scope discipline.

Known uses (3)

Known failure modes (3)

  • [decision-maker-absent]

    The anti-pattern of running a sprint without the actual decision-maker present and empowered throughout the week. Without someone who can commit to next steps based on Friday's data, the sprint produces a prototype and a recommendation that must then go through the real decision process — eliminating the format's primary value.

  • [sprint-as-theatre]

    The anti-pattern of using a design sprint when the question has already been decided and the sprint is being run to create the appearance of user-centred process. Participants detect this within the first day. The sprint format requires a genuinely open question; a closed question produces a Potemkin prototype and no real learning.

  • [fake-users]

    The anti-pattern of testing the Friday prototype with colleagues, friends, or other employees rather than actual target users. Internal 'users' already know the context, the product language, and the team's intent. Real users reveal the gaps internal testing cannot surface.

Related trainings (4)

Sources (2)

Provenance

  • Ecosystem: product development / AI
  • Added to catalog:
  • Last updated:
  • Verification status: verified