A design sprint, if you have not been in one, is a week in which a small team takes one big question about a product, builds a rough version of an answer, and puts it in front of real people on the last day. Sprints tend to fall into one of two piles. Some change what a company builds for the next year. The rest produce a polished clickable prototype, a mock-up you can tap through as if it were real, a wall of sticky notes, and a sense of progress that is gone three weeks later.
In my experience the difference is rarely how well the week itself is run. It is usually something decided before the week started, or something left undone after it ended. These are the things worth checking.
The question is the whole thing
A sprint answers exactly one question. If you cannot write it on a single line, the week will spread out into a brainstorm, which is a different and much less useful activity.
The failure mode is a question that is really a decision someone has already made. "How should we design the new onboarding?" is not a sprint question. It assumes new onboarding, it assumes onboarding is the problem, and it invites five days of work that confirms a conclusion reached somewhere else.
A real sprint question is uncomfortable to write down, because writing it down admits the answer might be no. "Will people trust us enough to connect their bank account in the first session?" is a sprint question. It has a version of the week that ends with the answer being no, and that version is not a failure.
Scope it to something you can put in front of a person
The second half of a good question is that it can be tested in five days by a prototype that one designer can build. "Should we move into the German market" is a strategy question, too big for a sprint. "Would a German small business owner give us their VAT number on the first screen" can be prototyped by Wednesday.
The instinct to make the question bigger is strong, because bigger questions feel more worth the week. It works the other way round. Big questions produce vague answers, and a vague answer after five days of six people's time is the most expensive outcome available.
Write the question as a bet
A useful test: can you state the question as a bet with odds you would actually take? "I think seven of ten small business owners will hand over their VAT number on the first screen" is a bet. "I think onboarding could be better" is not.
Making people say a number before the week starts does two useful things. It surfaces that the room disagrees, often wildly, which is itself worth knowing on Monday rather than Friday. And it makes the result legible: if you said seven and got two, nobody can absorb that into "it went quite well, with some things to work on", which is how sprint findings usually die.
Who is in the room decides whether anything happens after
This is the part that most sprint write-ups underplay. A sprint does not produce a decision. It produces evidence, and evidence needs someone who can act on it.
If the person who owns the roadmap, the plan for what gets built next and in what order, is not in the room, the sprint output becomes a presentation. Presentations get scheduled, then rescheduled, and by the time they happen the context has to be rebuilt from scratch for someone who did not watch a single user struggle. Whatever conviction the room had does not survive that translation.
I now treat this as a precondition rather than a preference. If the decision maker cannot commit to the first day and the test day, the sprint gets moved. A sprint without them is research, and research is fine, but it should be called research and budgeted like it.
The engineer is not there to build
The other person people leave out is an engineer, usually on the grounds that there is nothing to build yet. That misreads what they are for.
An engineer in the room on Monday will tell you, quickly, that the thing you are sketching depends on data the system does not have. That is not obstruction, it is one of the most useful things you can hear that week, and hearing it on Monday costs nothing while hearing it three weeks later costs the whole sprint.
Five people, chosen badly, tell you nothing
The number is not the hard part. Five is usually enough (opens in a new tab), because each extra person mostly repeats what the first few showed you. Who those five are is where sprints go wrong.
The failure is recruiting people who are easy to reach, which usually means existing customers who already understand the product, or colleagues, or a panel that does this for a living. All three are unrepresentative in the same direction: they are more patient and more fluent than the person you are actually designing for.
If the question is about a new audience, the five have to come from that audience, and finding them takes longer than the sprint does. That is an argument for starting recruitment a week before the sprint, not for lowering the bar. Five people can sail through a flow and teach you nothing, because none of them was the person the flow was for.
The prototype should be embarrassing
The most common way to waste Thursday is to make the prototype good. Real buttons, real wording, every screen for every situation, all polished by someone who is good at polishing.
None of it changes what you learn on Friday. Five people looking at a flow for fifteen minutes each will not notice your spacing. They will notice that they do not understand what the product is for, which they would have noticed just as clearly on grey boxes.
Worse, a polished prototype creates a sunk cost: effort already spent, which people then feel they have to defend. I think a team that spent a day making something look finished is less willing to hear that it is wrong, and a sprint whose entire value is the willingness to hear that it is wrong cannot afford that.
Build the least thing that lets someone try to do the task. If it works only on the exact path you plan to test, that is not a compromise, it is the correct amount of prototype.
Friday is not the end
The biggest difference I have seen between sprints that mattered and sprints that did not was what was booked before the week started.
For the ones that mattered, there was a slot on the following Tuesday with the roadmap owner, and the output of the sprint went into it as a recommendation with a proposed next step. Not a summary of what happened, but a recommendation, with a specific decision requested.
For the ones that did not, Friday ended with real energy, a digital whiteboard full of notes, and an intention to write it all up. The write-up was always going to happen next week, and next week always had its own emergencies.
Write the recommendation before you have the results
One habit that helps: on Wednesday, draft the two versions of the recommendation. One for if the answer is yes, one for if the answer is no. Both are one page, both name a next step, and both are ready to go.
It takes an hour, it removes the end-of-week writing task that never gets done, and it forces the room to confront early what a no would actually mean. Occasionally the team discovers on Wednesday that they have no plan for a no, which is worth knowing while there is still time to change the question.
Watching is a skill, and most rooms are bad at it
The observation half of Friday gets treated as a formality: everyone dials in, half of them keep working, and the notes are whatever the facilitator remembers.
Two habits fix most of it. Give every observer one thing to watch rather than "take notes", so one person is tracking where hands hesitate, another is tracking what people say out loud versus what they do, another is only writing down direct quotes. Notes written to a brief are usable; notes written in general are a transcript nobody rereads.
And separate observation from interpretation by an actual break. The pull towards explaining away a struggle is strongest in the minute after it happens, usually by the person who designed that screen. Collect first, argue later, with the arguing done as a group rather than by whoever speaks first.
What a sprint is bad at
For balance, the things sprints are not good for.
They are bad at incremental improvement. A flow that works and could work better does not need five people and a week. It needs someone to look at where people drop off and ship three changes.
They are bad at anything that depends on long-term behaviour. A week can tell you whether someone understands a habit-forming product. It cannot tell you whether they will form the habit.
They are bad at consensus. A sprint is a decision-making tool that works by narrowing quickly, and a room that wants everyone to feel heard will fight the format all week. If the real problem is that a team disagrees, solve that first, in a different meeting, with a different structure.
Two failure modes worth naming
The sprint that validates
Everything goes well, all five people succeed, the room is delighted. More often than not, I think, this means the prototype tested the part that was never in doubt. A week that could not have produced a no did not answer a question; it was a demonstration.
The sprint that becomes a project
The week ends without an answer, so another week is scheduled, and then a third. Sprints do not compound like that. The value came from the deadline; removing it turns the format into a slower version of normal work with worse tooling. If a week was not enough, the question was too big, and the fix is a smaller question rather than more weeks.
A four-day version
The textbook version is five days, as set out in the design sprint Jake Knapp developed at Google Ventures (opens in a new tab) and described in the book Sprint he wrote with John Zeratsky and Braden Kowitz. I would usually run four. Monday to map and pick the question. Tuesday to sketch and decide. Wednesday to build and draft both recommendations. Thursday to test with five people and write the real one. Friday is left free on purpose, because the follow-up conversation is more valuable than a fifth day of sprinting, and because a team that has just had a hard week produces better thinking with a day of space than without it.
It is still the same method, with the parts that carry the value protected: one uncomfortable question, the person who can act on the answer in the room, a prototype nobody is proud of, and a meeting already in the calendar for the week after.