Design sprints aren't for everything

Design sprints have a remarkably good PR operation. The book sold well. The case studies are compelling. The structure (five days, a defined problem, a tested prototype) sounds like exactly what organizations chronically allergic to decisions need.

The problems with sprints are not problems with the method itself. The Sprint process, applied to the right situation, is genuinely effective. The problem is that "design sprint" has become a generic answer to a generic question: "how do we make progress on something without committing to anything." That's not what it's for, and using it that way produces a specific kind of expensive failure.

What sprints are actually good at

The original Sprint method was designed for a narrow and specific situation: you have a big, uncertain, customer-facing problem, you don't know which of several approaches is worth investing in, and you need to find out before committing engineering time to any of them. Five days, one team, one focused question, a testable prototype, five users.

That situation exists. When it does, sprints work. The time pressure forces decisions that would otherwise be deferred indefinitely. The structured exercises surface assumptions people didn't know they were making. The prototype test gives the team real signal from real users in a context where they'd otherwise be guessing.

The method works because it's calibrated to those constraints: a bounded problem, a team that can be pulled out of normal work for a week, users who can be recruited and interviewed in the time available, and a question specific enough that a prototype can actually answer it.

What sprints are bad at

Sprints don't work well for problems that are ongoing rather than discrete. If the question is "how should we approach monetization for the next three years," a sprint won't answer that, because a prototype can't test a three-year strategy. The output of the sprint will be a prototype of some specific expression of one monetization idea, which gets confused for a test of the strategy. This is how sprints produce false confidence.

They also don't work well when the problem is actually a people problem. A team that disagrees about product direction because of underlying disagreements about company priorities will not resolve those disagreements in a sprint. What they'll do is simulate alignment for five days, produce a prototype everyone can claim represents their view, and then disagree again the moment implementation decisions need to be made. Sprints can look like they've solved problems they've actually deferred.

The facilitation-heavy format can also suppress the people who should be most influential. A well-run sprint involves voting, dot stickers, silent ideation, and structured time-boxing. These formats reduce the influence of seniority and expertise, which is useful when you want to hear from quieter voices. They're actively harmful when the person who should be most influential gets one vote like everyone else. The domain expert. The senior designer. The person who's thought about this problem for eighteen months.

The week-long meeting problem

The biggest practical failure of design sprints as commonly run is that they're extremely expensive in senior time. Pulling a product manager, a designer, an engineer, a researcher, a stakeholder or two, and a facilitator out of regular work for five full days is not a small cost. The cost is often underestimated because it's distributed. No single person's sprint time shows up in a budget line. But it's real.

That cost is worth it when the sprint answers a question that would otherwise take weeks or months to answer through normal work. It's not worth it when the same question could have been answered by a designer doing two weeks of exploratory work and a quick research session. The sprint becomes a forcing function that creates accountability through structure rather than solving a problem that actually required the format.

Teams that run a lot of sprints are sometimes teams that have trouble making decisions in the normal course of work, and the sprint is a mechanism for creating enough external pressure to force a decision. That's worth examining. If you need a five-day simulation to make a call, the underlying process problem is probably more important to fix.

When the prototype test is the weakest part

A sprint ends with user testing. Five users, a few hours, qualitative reactions to a prototype. This is presented as validation, and sometimes it is. It's also sometimes five people reacting to a prototype in a context that has very little to do with how they'd actually encounter the product.

Prototypes shown in a testing session have a limited fidelity ceiling and a context ceiling: the person is being asked to evaluate something they didn't discover organically, in a time-limited session, without their actual history with the product. Their reactions are real. Their conclusions are often different from what would happen with a shipped product used over time.

This doesn't make user testing useless. But treating the sprint test as a definitive answer rather than a directional signal is a mistake the sprint format actively encourages. "We tested it" is too easily heard as "we know it works."

What to use instead

For most design questions that get incorrectly escalated to a sprint: a focused design phase with a clear brief, one or two designers working exploratory work for one to two weeks, followed by a structured review, followed by a targeted research session. This takes roughly the same calendar time as a sprint and produces comparable signal without the coordination cost.

The situations that genuinely need the full sprint format are real but rare. The method is worth knowing well enough to recognize those situations when they appear.