Design Sprint

Most teams pay three months of engineering to learn what five days could have told them.

A design sprint is a five-day process for answering a big, risky product question before you commit months of building to it. In one week a small team maps the problem, sketches competing solutions, decides on the strongest one, builds a realistic prototype, and puts it in front of real customers on Friday. Jake Knapp created it at Google in 2010, brought it to GV (Google Ventures), and refined it there with John Zeratsky and Braden Kowitz. The three of them wrote the manual, a book called Sprint. The pitch is the whole appeal in one line: compress months of work into a single week.

This one isn't mine, and I won't pretend otherwise. The sprint is Jake Knapp's, and the ideation exercises I teach carry that credit right on the slide: "from Jake Knapp's Sprint." So here's the shape of the full week, then when it's worth running and when it isn't.

Think of this page as the map. The five activities that make up the week each get their own page in this part, taught step by step, because every one of them is just as useful pulled out of the sprint as it is inside it. This page is the route. Those pages are the stops.

The bet a sprint replaces

A team picks a direction. They build for a quarter. They launch. And then, finally, they find out what customers actually think.

If the direction was wrong, you just paid three months of engineering to learn it. That's the most expensive tuition in product work, and teams pay it constantly, because building feels like progress and testing feels like delay.

The sprint flips the order. You find out what customers think first, in five days, with a prototype that only looks real. No code shipped, none of your planned build time spent. When the bet is big and nobody has put anything in front of a customer yet, one week of test-and-learn is the cheapest insurance you can buy against a quarter of build-and-hope.

The five days

Here's the shape of the week, per Knapp, Zeratsky, Kowitz, and GV. I'm keeping each day short, because the full play-by-play lives on the activity pages and in the book.

Monday: map. You start at the end. The team agrees on a long-term goal, maps how customers move through the problem, and the one person who owns the decision, the Decider, picks the single target the week will attack. The Decider is whoever actually has authority over this bet, the product owner or the senior leader in the room, named for the week so the call has a clear home. Nobody pitches solutions on Monday. You're agreeing on what's worth a week.

Tuesday: sketch. The morning is Lightning Demos: a fast tour of products worth stealing an idea from, so everyone walks in with raw material. The afternoon, everyone sketches solutions alone, on paper, using the Four-Step Sketch. Critical thinking over artistry. Ugly is okay.

Wednesday: decide. Tuesday's stack of sketches goes up on the wall, and the team narrows it without an open-mic debate. The narrowing runs as a fixed Decide sequence of silent looking, dot voting, and timed critique, with the Decider casting the final, weighted vote at the end. The winning sketch becomes a storyboard, the shot-by-shot script for tomorrow's prototype.

Notice what that sequence does. The sprint knows authority is in the room. The HiPPO, the Highest Paid Person's Opinion, doesn't vanish because you booked a workshop. Left alone, the most senior voice steamrolls the best idea and the room stops thinking and starts agreeing. So the sprint gives authority one job, at one moment, after everyone else has already had a voice. The Decision Jam, the one-hour group deciding workshop on its own page in this part, solves the same problem a different way: silent voting dots, so nobody can sway the room. Same disease, two cures.

Thursday: prototype. Knapp calls Thursday's mindset "fake it." You build a fake front, just real enough that a customer on Friday believes it's the product. Not production code. Not even good code. One day of work, and that constraint is the point: a prototype you built in a day is a prototype you won't fight to keep. The how-to is on the Prototype Day page.

Friday: test. Five real customers, one at a time, talking through the prototype while the whole team watches. This is the moment the week is built around. By the end of the day you know whether Monday's target survived, and which assumptions just died in front of witnesses. Why five? Knapp borrows the number from usability researcher Jakob Nielsen of the Nielsen Norman Group, whose 2000 article found that watching about five real people try to use a thing surfaces roughly 85% of the spots where people get stuck or confused, and five one-hour conversations happen to fit in a single day. One rule carries the room: read what people do, not what they say. The 5-customer Test page walks the interview, and The Mom Test by Rob Fitzpatrick is the whole discipline in one book.

That's the week. Five days, five activities, one validated direction at the end of it.

Can you do it in less than five days?

Five days is a lot to ask for. So here's the question that actually comes up in the room: can you do it in less? Yes, sometimes. But only if you understand what you're cutting.

The three-day version is real. And the thing the room loves most about it isn't the speed. It's getting to go deep on a single idea, together, for days, with nothing else allowed in. Most people never get that. Their work is forty open tabs and a calendar that won't let them think about one thing for more than thirty minutes. A sprint, even a short one, is permission to put everything else down and chase one idea all the way to a customer's reaction. That alone is worth clearing the week for.

But how much you can compress depends on two things: how much alignment the team already has, and how narrow the challenge is. You have to understand the tools and the methodology before you start cutting, or you'll cut the wrong thing. So here's the principle that tells you what's safe to cut and what isn't.

Never cut the prototype or the test. Those two days are the payoff. Thursday and Friday are where real direction comes from, because that's the only place a real customer touches a real-feeling thing and reacts. Pull either one out and you don't have a shorter sprint, you have a meeting. The whole reason you cleared the calendar was to get to that Friday room.

Everything before Thursday is alignment work, and alignment work compresses to the degree you've already done it. Monday's map, Monday's target, Tuesday's sketching, Wednesday's deciding, all of it exists to get a team that disagrees onto the same page about what to build. If the team is already on that page, you can move fast.

Compress the front of the week by the amount of alignment you already have:

• Skip or shorten Monday's map when discovery and empathy are already done and the team shares the picture. ("Discovery and empathy already done" means you've already talked to real users and understand the problem from their side, so the map would just re-draw a picture you've got.) The map exists to build a shared understanding. If you have one, don't rebuild it. AJ&Smart's compressed sprint runs the entire map in a fraction of the book's time for exactly this reason.
• Drop goal-setting on a follow-up sprint. If this is iteration two on a problem the team already sprinted once, the goal and the questions are already set. Don't re-litigate them.
• Compress the sketching when the direction is already clear. If you're refining a known solution rather than discovering one, you need fewer competing sketches.
• Replace storyboard-by-committee with a fast facilitator-led decision. Instead of the whole group hashing out the storyboard together, line by line, a confident facilitator (the person running the sprint) drives Wednesday's call in a fraction of the time a full group debate takes.

Three things have to be true before you compress safely:

1. An experienced facilitator. A short sprint runs on someone who knows the format cold and can adjust on the fly when a step runs long. This is the crux. First time facilitating? Run the full five.
2. Participants with sprint experience or strong pre-work. Compression assumes the alignment is pre-loaded, either because the team has sprinted before or because the prep work front-loaded the map and the goal.
3. A narrow, well-defined challenge. Compress a simple, contained problem. A big, contested, never-tested bet is exactly the case where you want all five days, because there the alignment is the whole job.

Knapp himself, on the three-day version, said it plainly: "Three days is super intense, and I wouldn't sign up for it myself." He's not against it. He's telling you the full five is the default, and the short version is a thing you earn. Steph Cruchon, who runs sprints for a living, says much the same: he tries to run five-day sprints because the ideas come out deeper, and treats anything shorter as the exception rather than the rule.

The full week is the default for a genuinely open, expensive bet. The compressed version works to the degree the alignment is already there and the challenge is narrow. And the two days you never touch are the two that produce the answer.

When to spend the week

The test for the full sprint is short. Big, expensive, risky bet, the team can't agree, and nothing has been in front of a customer? That's a sprint-shaped problem. Clear five days.

An hour's decision is a Decision Jam. A quarter's bet is a sprint.

One warning if you clear the calendar. Don't half-commit. A sprint where people drift out for other meetings isn't a sprint, it's an expensive retreat. The compression is the mechanism. The same handful of brains hold the whole problem for days, and Friday's deadline is what forces Wednesday's decision. Lose the room and you lose both, the shared head full of the problem and the deadline that forces the call. If you can't get the room, don't run a watered-down version. Run a Decision Jam plus a lean experiment instead, and be honest that you made the smaller bet.

And whatever survives Friday isn't a launch. It's a prototype that one round of five customers liked. That direction still goes to the Lean Experiments page, the sibling method for cheaply testing assumptions, as the next experiment, this time against the real build.

That's the whole reason any of this exists. Not the sticky notes, not the five days, not the format. The point is to learn what works before you pay to build it. There is no shortcut to outcomes.