Design Sprint
Back to the frameworks catalog
A Design Sprint is a compressed week for answering a dangerous question before you spend months of engineering on it. In five days the team sharpens the problem, puts solutions on paper, builds a realistic prototype, and tests it with real users.
Jake Knapp built the method at Google Ventures and wrote it down in Sprint. Very different companies have used the same skeleton. The power is the rhythm, not the slides.
This is not an endless brainstorm. Brainstorming is one Tuesday move. The rest of the week is focus, decision, and evidence.
When a sprint works — and when it does not
Use it when:
- The problem is large and the team does not agree on the solution.
- Real build cost is high and you want to kill the hypothesis first.
- You need product, design, engineering, and the business in one room.
- You can reach five real users inside the week.
Do not use it when:
- The problem is still “we should build something” and the customer job is unknown. Start with JTBD.
- The decider is absent and the week becomes a report for people who were not there.
- You want to clear a backlog. A sprint is not a feature factory.
- You confuse the prototype with a shippable product.
If discovery and delivery must run together, a sprint is an intervention, not the weekly system. For the habit, go back to Dual-Track and Continuous Discovery.
Who should be in the room
A good sprint is seven people or fewer:
- Decider: the person who can say “we continue” on Friday. Without this role the sprint is theatre.
- Facilitator: holds time, energy, and the “less talk, more work” rule. Usually does not compete on sketches.
- Product, design, engineering: so desirability and feasibility are heard together.
- A customer, sales, or support voice: so market guesses stay honest.
- A subject expert on Monday, even if they do not stay all week.
Block the five days on every calendar. A part-time sprint almost always fails.
The five days, without the usual oversimplification
Monday — map and target. Write the long-term goal, pull out sprint questions, map the journey, ask the experts, and pick one target for the week. If Monday still holds two problems, Tuesday is wasted.
Tuesday — sketch. Lightning demos of other products, private notes, Crazy 8s, then a three-panel solution sketch that each person draws alone. Solo work is deliberate. Groups converge too early on the loudest idea.
Wednesday — decide. Sketches are reviewed without a pitch, a heat map and vote appear, the decider supervotes, and the team storyboards the prototype. Endless debate is replaced by a testable decision.
Thursday — prototype. The goal is a convincing fake, not an architecture. The prototype must look real enough that Friday’s user behaves naturally. The tool does not matter — Figma, slides, or a fake page will do. Do not build the real product.
Friday — test. Five structured interviews. After the third person, patterns usually repeat. Write what recurs on the board, not decorative quotes. By the end of the day you should know: continue, pivot, or stop.
A four-day version is common now: Monday and Tuesday are compressed. Do that only when the problem is already narrow and the decider is ready.
What you do after Friday
A finished sprint means the hypothesis is cheaper, not that the roadmap is written. A good output is three things: a prototype, five pieces of evidence, and a decision. If the decision is “go,” that is when a sharper opportunity assessment starts. Review Cagan’s ten questions there.
Tool: sprint planner
Check team readiness, set a start date, and tick the five-day checklist. The state stays in this browser so it does not get lost mid-week.