Most teams run a design sprint for the first time and walk away wondering if they did it right. The output looked good. The prototype was realistic. The Friday test session generated interesting reactions. And then everyone went back to their desks, and nothing materially changed.
That is not a sprint methodology problem. It is a sprint setup problem. And it starts before the first day of the sprint, not during it.
What Is a Design Sprint?
A design sprint is a structured, time-boxed process for answering a specific product question through rapid prototyping and testing with real users, without building anything permanent.
The method was developed by Jake Knapp at Google starting in 2010, applied initially to products like Gmail and Google Hangouts, and published as a formal five-day framework in the book Sprint in 2016. Google Ventures then used it as the primary method for working with portfolio startups, running sprints at companies including Slack, Uber, 23andMe, Nest, and Flatiron Health.
Since then, teams at Airbnb, Amazon, LEGO, MIT, Mercedes-Benz, Harvard Business School, and the United Nations have adopted the process. AJ&Smart, the Berlin-based product team that has run more than 200 sprints across global companies, developed Design Sprint 2.0 with Jake Knapp in 2018, compressing the process from five days to four.
The core mechanism is the same across both versions. Instead of spending months debating direction, building a product, and learning from it in production, a sprint compresses that cycle into one week by testing a realistic prototype with real users before any development begins.
Each word in the phrase carries a specific meaning:
| Word | What It Means |
|---|---|
| Design | The solution is shaped and simulated, not just discussed |
| Sprint | Fixed time, full focus, defined output at the end |
| Process | Structured sequence of activities, not a brainstorm or workshop |
One distinction that trips up most teams: a prototype is not an MVP. A prototype is never released publicly. It is a realistic simulation built to generate a signal about a specific question. An MVP is released to real users and generates real market signals about demand. Treating them as the same leads to misread results and misapplied methods. The relationship between sprint output and MVP build is covered in the How to Scope an MVP guide.
The Design Sprint Versions in Use Today
| Version | Duration | Who Attends Full Run | Key Change |
|---|---|---|---|
| Original GV Sprint | 5 days | All team members | The baseline was published in Sprint (2016) |
| Design Sprint 2.0 | 4 days | All teams for days 1 and 2 only | Executives released after day 2; condensed exercises |
| Lightning Sprint | 1 to 2 days | Core team only | AI-assisted research and prototyping; used for lower-risk questions |
| Remote Sprint | 4 days | Distributed team | Miro for collaboration, Figma for prototyping, and video facilitation |
Design Sprint 2.0 is now the more widely used format. The four-day structure is practical because it keeps executives involved only where their authority matters (days one and two) and hands prototyping and testing to a smaller, faster-moving group. The full-team-for-five-days requirement of the original format was the most commonly cited reason organizations delayed running sprints.
Remote sprints, which AJ&Smart documented during and after 2020, produce equivalent quality to in-person sprints with the right tools and facilitation. The main adjustment is tighter time-boxing per activity because digital collaboration drains attention faster than in-person work.
How a Design Sprint Works: Day-by-Day Breakdown
The original GV framework ran Monday through Friday. Design Sprint 2.0 condenses this to four days by restructuring the first two days into a single packed day and releasing the decider and executive team after day two rather than requiring them for the full run.
Here is what actually happens:
Day 1: Understand, Map, and Sketch.h In Sprint 2.0, what was originally Monday and Tuesday gets compressed into one day. The team begins with expert interviews and How Might We questions to surface the problem from multiple angles. They map the customer journey, set a long-term goal, and define the sprint question: the specific thing the team will try to answer by Friday. Individual solution sketching happens in the afternoon. Each person works alone, avoiding the groupthink that collaborative brainstorming produces.
Day 2: Decide and Storyboard. The team reviews all sketches independently, votes on the strongest ideas, and builds a storyboard: a step-by-step plan for the prototype. The decider makes the final call when the team cannot reach consensus. In Design Sprint 2.0, executives are only needed for these first two days. This was one of the most significant practical improvements in the updated format because clearing an executive's calendar for five days consistently blocked sprints from happening at all.
Day 3: Prototype A realistic but fake product is built quickly using Figma, slide software, or whatever tool produces a simulation close enough to real that users respond naturally. The full team is not needed for this day. A smaller group of three to four handles prototyping while others continue their regular work.
Day 4: Test Five real users test the prototype in individual sessions while the team observes. Nielsen Norman Group research shows that five users uncover roughly 85 percent of usability issues. Each session runs independently. The team watches for patterns across sessions. By the end of day four, the sprint question has a real answer.
What Does a Design Sprint Produce?
Teams going into a sprint for the first time expect validation. The sprint produces one of three outcomes, and the other two are just as valuable as the one most people want.
A successful failure: The prototype tested poorly. Users could not complete the core task, were confused by the flow, or were simply uninterested. This is not a failed sprint. A four-day process that prevents six months of development on the wrong product direction is one of the highest-return activities a product team can run. XPLANE documented a case where a sprint prototype's poor test results stopped a significant mobile application investment before a single line of code was written.
A flawed win: Parts of the prototype worked. Other parts generated consistent confusion. The team now knows exactly which elements to iterate on, which is more actionable than a vague internal sense that something needs to improve. Most sprints produce this outcome.
A resounding confirmation: Users completed the core task, responded positively, and confirmed the hypothesis the team was testing. The team has a clear direction and a prototype that communicates the vision to stakeholders and investors.
All three outcomes justify the sprint. The worst output is ambiguity, which usually comes from a sprint question that was too broad, not from the process itself.
What to Do Before the Sprint Starts
New Haircut, a product design firm that ran 47 sprints over a two-year period, found that the single most consistent predictor of sprint quality was the work done before day one, not the execution of the sprint activities themselves.
A design sprint cannot exist without a clear, specific problem. Teams that arrive on day one, still debating what the sprint is about, spend the first day doing work that should have been done two weeks earlier. By the time the sprint question is written down, the team is already a day behind.
Pre-sprint work typically takes one to two days and covers three things:
Problem framing: The sprint challenge needs to be written as a single falsifiable question before the sprint begins. Not "how do we improve our product" but "will a first-time user be able to set up a workflow without contacting support?" The question defines everything that follows. If it cannot be written specifically, the team is still in problem discovery, not sprint preparation.
Research distribution: Relevant customer research, competitive benchmarking, and existing data should be compiled and shared with the team before day one. Doing research inside the sprint wastes hours on work that does not require the full team.
Team confirmation: Each person in the room needs relevant experience with the specific challenge being tested. A sprint team with no direct connection to the problem produces shallow sketches and consensus decisions with no grounding in actual user behavior. One session at New Haircut failed specifically because none of the sprint participants had first-hand experience with the challenge. By the end of the week, they had barely identified the right questions to ask.
Who Should Be in a Design Sprint Team
Design sprints were named poorly. The word "design" leads teams to fill the room with designers. That is the wrong composition for a process designed to make product decisions.
The ideal sprint team, according to GV, is four to seven people. The composition matters far more than the number:
The decider. The person with the authority to commit the organization to a direction. Without this person present for days one and two, the sprint output becomes a recommendation that gets overruled afterward. This is the most commonly cited reason sprints produce nothing actionable.
The facilitator. Focused entirely on running the process. The facilitator does not contribute to the content and does not advocate for any particular direction.
A customer-facing voice. Someone who talks to users regularly and can represent real user behavior rather than internal assumptions about it.
A technical representative. Who can flag what is and is not feasible before the team commits to a prototype direction.
A marketing or go-to-market perspective. Who thinks about how the solution reaches the people it is built for.
Domain experts. Relevant to the specific challenge being tested.
A team of designers can execute sprint activities more fluently than a mixed team. But the decisions that matter in a sprint reflect product, technical, business, and user perspectives simultaneously. A designer-only sprint produces design conclusions. That is different from the product direction a sprint is designed to generate.
Design Sprint Examples: How Real Companies Used It
The most instructive sprint case studies are not the obvious ones. The way teams have applied the process beyond standard new product development reveals the actual flexibility of the method.
Google Meet: Jake Knapp ran the sprint that produced what would become Google Hangouts after a trip to Stockholm to test a concept for video meetings. The goal was to prototype a way to maintain genuine social contact across distributed teams. The tested prototype became the foundation of the product now used by hundreds of millions of people.
Slack: Slack's design sprint was not about the product at all. It was about marketing. The team was moving from a gaming company called Glitch into the B2B space and needed to communicate what Slack was to people outside Silicon Valley without typecasting it as "just a messaging app." The sprint produced the Tenacious Tour, an animated guided walkthrough that explained Slack's value through a user's actual workflow. That concept won in user testing over competing ideas, including a bot team simulation.
LEGO: In 2017, LEGO's internal agency used design sprints to change how the entire company approached product design. They ran 10 sprints concurrently in the first week and completed more than 150 sprints in the first year. The goal was not to validate individual products but to embed a culture of structured experimentation across teams. The sprint became their standard operating method.
Facebook News Feed: The Facebook team ran a sprint specifically to identify which changes to the news feed would generate more meaningful user engagement. Rather than releasing features and measuring in production, they tested design treatments with real users and applied targeted changes based on observed behavior.
The pattern across these cases: the sprint question was specific, the team had direct experience with the challenge, and a decider was present to make calls when the team disagreed.
When a Design Sprint Is Worth Running (and When It Is Not)
Worth running when: The problem is significant enough to justify pulling four to seven people out of regular work for a week. There is a specific, falsifiable question to answer. A prototype can represent the solution realistically enough for users to respond to it meaningfully. The team is genuinely uncertain about the right direction, not running a sprint to build consensus around a decision already made.
Not the right tool when: The team already knows the answer and is using the sprint to get organizational buy-in. The challenge is too narrow (a single UI component a designer can test in a day) or too broad (an entire go-to-market strategy). The problem is primarily about execution, not direction. The company cannot get the decision in the room for the first two days.
One test that works reliably: can the sprint question be written as a single specific sentence before the sprint begins? If not, the problem is not ready for a sprint.
After the Sprint: The Step Most Teams Skip
A sprint ends on day four. The question is what connects the output to Monday morning.
A tested prototype with user observations does not automatically become a product direction. Without a clear post-sprint commitment, the output circulates as a slide deck for two weeks and then sits in a folder.
Three outputs a sprint should produce to be actionable:
- A documented prototype with annotated observations from each user session, not just a recording.
- A written decision on next steps: whether the team is moving to build, running another sprint on a refined question, or discontinuing the concept.
- A named owner for the next step with a defined date.
When a sprint confirms a direction, the next step is scoping what to build. That decision, which features belong in the first version and which do not, is where most post-sprint momentum gets lost. The How to Scope an MVP guide covers exactly this transition in detail.
When a sprint invalidates a direction, the output is equally important. Understanding specifically which part of the prototype failed and why prevents the team from rebuilding the same problem with a different visual.
The Relationship Between Design Sprints and MVP Development
A design sprint and an MVP serve related but different purposes. A sprint tests whether a direction is worth pursuing. An MVP tests whether a product finds real market demand.
The correct sequence: sprint first to validate direction, then build the MVP to validate demand. Teams that build first and sprint later are using the process to justify decisions already made. That is not discovery. It is a theatre.
Before committing to a multi-month MVP build, a sprint surfaces the highest-risk assumptions in the product concept and tests them against real user behavior in four days. The cost is four days of focused team time. The alternative is finding out six months into development that the core assumption was wrong.
Ready to Run a Sprint That Produces an Answer?
A design sprint works when the challenge is framed before day one, the right people are in the room, and the output connects to a clear decision on the other side.
Ellenox works with product teams and founders to frame sprint challenges, facilitate the process, and connect sprint output to a build path. If you have a product question that is currently stuck in debate or needs validation before committing to development, talk to Ellenox.