The Discovery Sprint Template I Use With Every New Client

A week spent before the build saves weeks, sometimes months, during it. Almost every client agrees with that sentence in principle and then tries to skip straight to wireframes anyway.

The instinct to jump to solutions is understandable. Wireframes feel like progress in a way that a week of interviews doesn't. But a wireframe built before the problem is actually understood isn't progress, it's a guess with good production values, and it's expensive to unwind once stakeholders have seen it and started forming opinions about button placement instead of the actual problem underneath.

The fix I use with every new client is the same five-day structure, run before any design tool gets opened.

Why five days, not more or less

Three days isn't enough to run real interviews, synthesize them, and stress-test the resulting direction. Two weeks is too long: momentum dies, stakeholders start multitasking through it, and the extra time gets absorbed by scope rather than depth. Five days is the tightest window that still forces genuine rigor without losing the room's attention. The constraint is doing real work here, not just imposing arbitrary urgency.

The day-by-day structure

Day 1: structured interviews. Talk to the people who will actually use the thing, not just the stakeholder who commissioned it. The questions are open-ended and steer nothing: how do you do this today, what's the annoying part, what have you tried already. The goal is letting real workflows surface rather than confirming whatever assumption walked in the door with you.

Day 2: problem mapping. Take everything from day one and map it from the customer's perspective, not the business's. Where does the current process actually break down, and for whom specifically. This is the day most teams are tempted to skip because it doesn't produce a visible artifact, and it's the day that prevents the most expensive mistakes later.

Day 3: competing solutions, sketched not designed. Generate multiple rough directions, deliberately still ugly, so the conversation with stakeholders stays about the underlying approach rather than aesthetic preferences. Polishing anything at this stage invites feedback on the wrong layer entirely.

Day 4: stress-test the assumptions. Take the direction that's emerging and actively try to break it. What happens for the edge-case user. What happens if usage looks nothing like the happy path everyone's been assuming. This is where scope creep gets caught early, while it's still a conversation and not a change request against a signed-off spec.

Day 5: the brief. Write down what everyone now agrees on, not a polished deliverable, just clarity. This is the document that governs the build from here, and its entire value is that everyone in the room actually believes it, because they watched it get built across the previous four days rather than receiving it as a finished handoff.

The three questions that have to be answerable by the end

By the close of a good discovery sprint, everyone on the team, not just the person who ran it, should be able to answer three questions without hesitating: who exactly is this for, what specific problem are we solving for them, and what is the minimal functionality that actually addresses it. If any of those three still gets a hedge or a "well, it depends" from someone in the room, the sprint isn't done yet, regardless of what day the calendar says it is.

What this actually prevents

Scope creep rarely arrives as a dramatic mid-project reversal. It arrives as a slow accumulation of "while we're at it" additions from people who were never fully aligned on what the minimal version was supposed to be in the first place, because that alignment never got built explicitly. A discovery sprint isn't a research nicety bolted onto the front of a project timeline. It's the thing that makes the rest of the timeline mean anything at all.