Design Sprint

Origin & evolution

Jake Knapp created the design sprint at Google around 2010, refining a structured week he had been running internally for teams building products such as Gmail and Google Meet. He carried the format to Google Ventures, where he ran it with portfolio🧸PortfolioPortfolioA grouping of products by strategic axisView reference → startups alongside John Zeratsky and Braden Kowitz, who had founded the firm's design team. The three codified it in Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (2016), having by then run the process with more than a hundred companies including Slack, Uber, and One Medical.

The book's structure is a five-day arc. Monday maps the problem and picks a target. Tuesday sketches competing solutions🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →. Wednesday the team decides and storyboards. Thursday builds a realistic prototype, a façade convincing enough to react to. Friday tests it with five customers in moderated interviews. The wager is that a week of focused work answers the expensive question, "is this worth building?", before a quarter of engineering commits to it.

Practice has since compressed the format. Remote and distributed teams found five contiguous days hard to clear, and many facilitators moved to a four-day version, with the prototype-and-test phases tightened. AJ&Smart's "Design Sprint 2.0" popularised a two-day variant🆎VariantGrowthA variant in an A/B testView reference → aimed at busy leadership teams. The underlying claim survived the trimming: structured divergence followed by forced convergence, capped by a real test, beats open-ended deliberation. The risk🎲RiskComplianceA risk to the product or businessView reference → the shorter formats run is sacrificing the user test, which is the part that makes a sprint more than a fast workshop.

How it works in practice

A B2B analytics company suspects its onboarding loses new admins at the data-connection step, but it has three competing theories about why and no agreement on a fix. Building all three would cost a quarter, so it runs a four-day sprint instead. Monday the team interviews two support engineers and maps where admins stall. Tuesday five people sketch flows independently, no group brainstorm. Wednesday they vote, and one storyboard wins: a guided connector with sample data pre-loaded. Thursday a designer builds a clickable prototype in Figma that looks shipped. Friday five real admins try it; four reach a live dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →, and three stumble on the same unlabeled permission toggle. The company has its answer in a week. It builds the guided connector and fixes the toggle, and skips the two theories that the test quietly killed.

Design sprint vs. its neighbours

• Prototype is an artefact; a design sprint is the process that produces and tests one. The prototype is the sprint's Thursday output, the thing Friday's users react to. A sprint without a prototype has nothing to test, which is why the format protects build day so fiercely.
• Experiment🧫ExperimentValidationA test designed to validate a hypothesisView reference → is a broader category of structured test that can run for weeks (an A/B test, a fake-door, a concierge trial). A sprint is one bounded, qualitative, five-user experiment compressed into days, optimised for early-stage direction rather than statistical confidence.
• Opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → is the gap a sprint investigates; the sprint is how a team interrogates it before committing. The opportunity says "admins abandon onboarding"; the sprint produces evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → about which fix actually moves them through.

In the graph

In the Unified Product Graph, a design sprint sits in the discovery region as a method node, linked to the gap it interrogates through opportunity_investigated_via_design_sprintOpportunityinvestigated viaDesign Sprinthierarchy. That edge encodes the sequencing the method depends on: a sprint earns its place when there is a named opportunity worth a week of the team's time, and its outputs (a prototype, a tested concept, a kill decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →) trace forward from there. Modelling the sprint as connected to its opportunity stops it becoming a ritual run on a schedule, because a sprint that points at no real opportunity is visibly a workshop wearing a deadline.