How to Run a Design Sprint (Step-by-Step Guide for PMs)
A design sprint is a five-day structured process for answering a critical product question through rapid prototyping and user testing. Developed at Google Ventures and detailed in Jake Knapp’s book Sprint, the design sprint framework has been used to validate products, features, and strategies at companies ranging from early-stage startups to enterprises with millions of users. Run enough of these and a pattern holds every time: the sprint doesn’t fail because the framework is wrong, it fails because someone skips the parts that feel like they’re slowing things down.
Understanding how to run a design sprint, and when to use one, is a valuable skill for any product manager working on problems that require cross-functional alignment and fast validated learning.
What Is a Design Sprint, and Where Did It Come From?
A design sprint is a time-boxed process, typically five days, that takes a team from a defined problem to a tested prototype without writing a single line of production code. The design sprint was developed by Jake Knapp while he was a design partner at Google Ventures, initially to help portfolio companies make high-stakes product decisions faster.
The design sprint compresses months of iterative product development into one week by focusing the team on one critical question, building a realistic prototype, and testing it with real users, all before committing to building anything at production quality.
The design sprint matters because it addresses one of the most expensive problems in product development: discovering that a major product decision was wrong after months of engineering investment. Running a design sprint before a major build investment can reveal whether the underlying concept works in five days at minimal cost.
What distinguishes a design sprint from other product processes is its strict time-boxing and its emphasis on divergent thinking before convergent decision-making. Most teams jump to alignment too quickly; the design sprint forces breadth before commitment. Google’s own Design Sprint Kit frames this as the core value of the methodology: it exists to develop a hypothesis and test it with as little investment as possible, in as real an environment as possible, before anyone writes production code.
How to Run a Design Sprint Step by Step
Learning how to run a design sprint starts with understanding the five-phase structure. Each day has a specific focus and outputs, and the discipline of staying within the structure is what makes the process work.
Day 1 — Map. The team maps the problem space. The Decider (typically the product leader or business stakeholder with final authority) articulates the long-term goal: “In two years, where do we want to be?” The team then maps the user journey for the specific challenge, identifying the key moments and the critical question the sprint will answer. Building this out as an actual customer journey map rather than a rough sketch on a whiteboard makes Day 2’s sketching sharper, because the whole team is working from the same picture of where the problem actually lives. Day 1 ends with the team aligned on one specific target: a particular moment in the user journey that the sprint will focus on.
Day 2 — Sketch. Each team member independently generates solution ideas. The day begins with inspiration: reviewing existing solutions, analogous products, and prior research. Then each person sketches detailed solution concepts individually. The key is that sketching is individual, not collaborative. This prevents groupthink and produces a wider solution space.
Day 3 — Decide. The team reviews all sketches, votes on promising elements, and makes a decision. The Decider has final say. The output of Day 3 is a storyboard: a step-by-step plan for the prototype, typically 10–15 frames showing exactly what the prototype will include.
Day 4 — Prototype. The team builds a realistic-looking prototype in one day. This is not a full product build; it is a facade, typically built in a tool like Figma, that looks and feels real enough to elicit genuine user reactions. The goal is “good enough to test,” not pixel-perfect.
Day 5 — Test. Five users test the prototype in individual one-on-one sessions, following the same structured approach you’d use in any round of user interviews. One team member facilitates each session. The rest of the team watches from another room and takes notes. Five users is the standard; it consistently surfaces the major patterns without the diminishing returns of larger studies.
By the end of Day 5 of the design sprint, the team has real evidence from real users about whether the core concept works. This evidence informs the go/no-go decision on the full build.
Design Sprint at a Glance
| Day | Focus | Output | Most Common Failure |
|---|---|---|---|
| 1 — Map | Problem framing | One target moment in the user journey | Jumping to solutions before the problem is agreed on |
| 2 — Sketch | Divergent thinking | Individual solution sketches | Collaborative sketching that converges too early |
| 3 — Decide | Convergence | A storyboard of 10–15 frames | Blending sketches into a muddy hybrid |
| 4 — Prototype | Realism over completeness | A believable facade, not a working product | Prototyping too many flows at once |
| 5 — Test | Learning from real users | Evidence for a go/no-go call | Treating sessions as confirmation instead of discovery |
The Five Phases of a Design Sprint Explained
Each phase of the design sprint has a specific role in the overall process. Here is what each phase is actually trying to accomplish and the most common mistakes teams make in each one.
Map (Day 1): The goal is to create shared understanding, not to generate solutions. The most common mistake is spending Day 1 brainstorming solutions when the team has not yet agreed on the problem. Protect this day for problem framing only.
Sketch (Day 2): The goal is divergent thinking. The most common mistake is collaborative sketching, which tends to converge on consensus solutions rather than generating a wide solution space. Keep sketching individual and private until the Day 3 review.
Decide (Day 3): The goal is to make a clear decision with the Decider’s authority. The most common mistake is trying to blend all the sketches into a hybrid solution. Hybrids tend to produce muddy prototypes that do not test clearly. Pick one clear direction.
Prototype (Day 4): The goal is realism, not completeness. The most common mistake is prototyping too many flows. Focus on the specific 3–4 screens or interactions that test the core concept. Leave everything else out.
Test (Day 5): The goal is learning, not validation. The most common mistake is treating user sessions as confirmation exercises. Users who struggle, get confused, or do not understand the prototype are giving valuable signal; the goal is to hear it accurately, not explain it away.
Take a realistic case: a design sprint run at an 18-person logistics startup to test a new dispatcher dashboard. Going into Day 1, half the team is convinced the problem is “dispatchers can’t see truck locations fast enough.” Mapping the actual journey on Day 1 shows something different: dispatchers can see locations fine, but they can’t tell which delayed shipments actually matter to a customer relationship versus which ones are routine. The whole sprint retargets around that narrower problem. By Day 5, three of five test dispatchers independently use the word “finally” when they see the reprioritized alert view: a small thing, but it signals the team found the real problem, not just a plausible one.
Where Design Sprints Break Down
Beyond the day-by-day mistakes above, there are a handful of structural ways a design sprint falls apart before it even gets to Day 5.
No real Decider, or a Decider who won’t decide. The entire model depends on one person having the authority and willingness to make a call on Day 3. A sprint can stall for hours because the nominal Decider keeps deferring to “what the group thinks,” which defeats the purpose. If nobody on the team can actually own the decision, fix that before the sprint starts, not during it.
Running it remote without adapting the format. A design sprint compressed into five days of back-to-back video calls is a worse experience than the in-person original, and pretending otherwise burns out the team by Wednesday. If you’re remote, spread the same five phases across more calendar days with shorter, more focused sessions; don’t just port a five-day in-person agenda onto Zoom.
Recruiting the wrong five users. A design sprint without access to real, representative users on Day 5 is just a week of internal opinions with better production values. Teams that substitute coworkers or friends of the team “just to keep momentum” tend to get feedback that’s almost always too polite and too forgiving to be useful.
Treating the sprint as the whole answer. A design sprint tells you whether a concept survives contact with real users for one week. It does not tell you whether it will hold up at scale, whether it’s technically feasible at the complexity you actually need, or whether it makes commercial sense. Conventional sprint enthusiasm sometimes treats a good Day 5 as a green light to build; the more disciplined read treats it as permission to invest in the next, more expensive round of validation.
Design Sprint vs Discovery Sprint: Key Differences
Product managers often encounter both design sprints and discovery sprints, and the distinction between them matters.
A design sprint, as described above, is a specific five-day process with a defined structure, culminating in a tested prototype. It works best when you have a defined problem and need to rapidly explore and validate solution directions.
A discovery sprint is a broader, more flexible research process, typically 1–2 weeks, focused on understanding the problem space before moving to solutions. See our guide on how to run a product discovery sprint for a full breakdown of that approach.
The key difference is this: a design sprint assumes you know the problem and need to test solutions. A discovery sprint is appropriate when you are still defining the problem. In practice, a discovery sprint often precedes a design sprint: you use discovery to clarify the opportunity, then a design sprint to rapidly prototype and test solutions. Teams that skip discovery and go straight to a design sprint usually end up re-running Day 1 halfway through because the “problem” they started with wasn’t the real one, which is exactly what happened in the logistics example above.
For retrospective learning after a sprint, see our guide on how to run a sprint retrospective.
When to Run a Design Sprint (And When Not To)
A design sprint is a high-value investment but it is not the right tool for every product problem. Here is when to use it and when to choose a different approach.
Run a design sprint when: You have a high-stakes product decision with significant uncertainty. You have a clear question that can be answered by testing a prototype with users. You have a cross-functional team available for five full days. You have executive or stakeholder support for committing to the Decider model.
Do not run a design sprint when: The problem is well-understood, and the solution is clear (in that case, just build it). You cannot get the team together for five consecutive days (a fragmented design sprint loses most of its value). The question cannot be answered by a prototype (some technical or business model questions require different validation approaches). You do not have access to users for Day 5 testing (a design sprint without user testing is just a week of internal opinions).
The facilitators at AJ&Smart, who have run design sprints commercially for years, make a similar case for restraint: the method is powerful specifically because it’s expensive to run well, and using it on low-stakes decisions just burns team goodwill for the next time you actually need it.
For connecting design sprint learnings to your Figma workflow, see our guide on Figma for product managers. If you’re weighing whether to run one at all, the honest test is simple: can you name the specific decision that’s currently stuck, and would five days of focused work plausibly unstick it? If the answer to either half is no, fix that first; don’t book the week and hope the process finds the question for you.
References
- Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster.
- Google. Design Sprint Kit. designsprintkit.withgoogle.com
- AJ&Smart. Design Sprint Academy. ajsmart.com
