How to run a design sprint that does not waste a week

A design sprint costs a week of your most expensive people. Done well, it replaces two months of circular argument with a tested answer. Done badly, it produces a Figma file everyone admires and nobody builds, and it costs the same either way.

We are not going to explain the five days again. Google Ventures wrote that and you can read it in an hour. This is about the part that actually determines the outcome, which happens before anyone books a room.

Why sprints waste a week

In our experience there are four failure modes, and none of them are about the process.

• The decider was not in the room. If the person who can say yes is dropping in on Thursday, you have run a workshop, not a sprint, and the decision will be relitigated the following week.
• The question was too big. "Fix onboarding" is not a sprint question. "Should verification happen before or after the first transaction" is.
• Nobody talked to a user. A sprint that ends without contact with a real customer has produced an opinion, and you already had plenty of those on Monday.
• There was no build slot. If engineering has no capacity for eight weeks, the output goes stale before it is built and you will run the sprint again from scratch.

Notice that three of those four are decided before the sprint starts. That is the point of this article.

What has to be true before day one

• A question narrow enough to answer in five days and specific enough that two reasonable people could disagree about it.
• A decider who is present for the whole week and has actually agreed to decide, not to consider.
• Five to six people, including someone who talks to customers and someone who will build it. Not eleven.
• Users booked for the test day before the sprint begins. This is the single most common reason a sprint collapses on Thursday night, and it is entirely preventable on the Monday two weeks earlier.
• Existing research, analytics and support tickets gathered in advance, so Monday is spent deciding rather than hunting for context.
• A build slot in the roadmap for what the sprint concludes. If you cannot name the sprint after which it gets built, do not run it.

That list takes about a week to arrange properly. Teams that skip it in order to start sooner reliably lose more time than they saved.

The five days, briefly

Monday is for agreeing the problem and the target, not for solving anything. Tuesday is for sketching independently, because the loudest person wins a group brainstorm and that is not the same as being right. Wednesday is for deciding and storyboarding, which is where the decider earns their place. Thursday is for building one realistic prototype rather than three vague ones. Friday is for five customer interviews, which is enough to see every pattern that matters.

That is genuinely all of it. The framework is not complicated and it is not where sprints go wrong.

When not to run a sprint

This is the section most articles leave out, because most articles are written by people selling sprints. There are several situations where a sprint is the wrong tool and running one anyway is a way of looking busy.

• You already know what to build and you are avoiding the work of building it. A sprint is not a substitute for a decision you have already made.
• The problem is technical rather than a design question. No amount of sketching resolves whether the architecture can support the feature.
• You cannot get a decider for five days. Reschedule until you can, or accept that you are running a workshop and set expectations accordingly.
• The question needs quantitative data. Five users will tell you why something confuses people. They will not tell you which of two pricing models makes more money.
• You have run three sprints this year and shipped none of them. The bottleneck is delivery, and another sprint will make it worse.

What to do on the Monday after

This is where most of the value leaks away. The sprint ends, everyone is energised, and then the file sits in Figma while the team returns to the roadmap it had before. Three months later nobody can remember what was decided or why.

So on the following Monday, write down the decision and the reasoning in a place people will find it, break the outcome into tickets that are in the actual backlog rather than a document, name the person accountable for each, and set a date to check whether the change did what the sprint predicted. That last one is the step everyone skips, and it is the only way a sprint teaches you anything beyond the week it ran.