I have run a lot of design sprints. Some of them changed what a company built for the next year. Others produced a beautiful clickable prototype, a wall of sticky notes, and a genuine sense of progress that had entirely evaporated three weeks later.
The difference was never the facilitation. It was almost always something decided before the week started, or something left undone after it ended. Here is what I have learned to check.
The question is the whole thing
A sprint answers exactly one question. If you cannot write it on a single line, the week will diffuse into a workshop, 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 validates a conclusion reached in a meeting nobody in the room attended.
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.
If everyone in the room would be equally happy with either outcome, you have a good question. If a particular outcome is expected, you are running a rehearsal.
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 wearing a sprint costume. "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 is exactly backwards. Big questions produce vague answers, and a vague answer after five days of six people's time is the most expensive outcome available.
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 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 Monday kickoff and the Friday tests, 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, in about four minutes, that the thing you are sketching depends on data the system does not have. That is not obstruction, it is the single most valuable input available that week, and hearing it on Monday costs nothing while hearing it three weeks later costs the whole sprint.
The prototype should be embarrassing
The most common way to waste Thursday is to make the prototype good. Real components, real copy, real states, 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. A team that spent a day making something look finished is measurably 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 single biggest difference 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 readout. A recommendation, with a specific decision requested.
For the ones that did not, Friday ended with genuine energy, a Miro board, 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
A trick that has served me well: 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 Friday-evening 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.
What a sprint is bad at
For balance, the things I have stopped using sprints 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 the funnel 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.
The version I run now
Shorter than the canonical five days, in most cases 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.
None of this is a departure from the method. It is 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.