How we handle a client who wants to skip the discovery phase

"Can we just skip straight to design, we already know what we want" is a request we hear regularly, usually from a founder eager to see visible progress as quickly as possible. We understand the impulse completely. We still push back on it almost every time, because discovery is rarely the delay it looks like from the outside, it's the step that determines whether everything built after it actually fits together.

Discovery doesn't produce anything visually exciting, which is exactly why it's the first thing an impatient client wants to cut. It produces clarity, a shared understanding of the actual problem, the actual users, and the actual constraints, and skipping it doesn't remove that work, it just delays it to a much more expensive point in the project.

Misaligned assumptions between stakeholders who never explicitly discussed what they each individually pictured. Technical constraints from existing systems that weren't mentioned because nobody thought to ask about them directly. A target audience that's more varied, or more specific, than the founding team's own mental model of who they're actually building for.

We've caught real, project-altering issues in discovery on the majority of projects where we ran it properly, issues that, left undiscovered, would have surfaced midway through design or development, at a point where fixing them costs real time and real money that discovery itself never would have.

A project that skips discovery still eventually has to resolve the questions discovery would have answered, it just resolves them reactively, mid-project, once a design or a build reveals a gap nobody anticipated. Resolving these questions late means redoing work that was built on an incomplete or wrong understanding, which almost always takes longer than answering the question correctly the first time would have.

We've tracked this directly across projects that skipped discovery versus ones that didn't: the ones that skipped it consistently took longer overall, once you count the rework, even though they appeared to start moving faster in the first couple of weeks.

We size the discovery phase to the actual complexity of the project, a straightforward marketing site needs a much lighter discovery pass than a multi-sided marketplace with several distinct user types. Treating every project with the same heavy discovery process regardless of complexity is its own mistake, and it's part of why discovery sometimes earns a reputation for being bureaucratic overhead rather than genuinely useful work.

For simpler projects, discovery might be a single focused working session rather than a multi-week phase. The goal is always proportionate rigor: enough structured thinking to catch the real risks specific to this project, without padding the timeline with process for its own sake.

We ask directly: what happens if we're wrong about something significant three weeks into design, how expensive would that be to fix at that point compared to now. Most clients, once they actually picture the cost of a mid-project correction concretely, reconsider the value of a short discovery phase upfront rather than skipping straight ahead.

For clients who are still certain after that conversation, often because they've genuinely already done significant thinking on their own before coming to us, we shorten discovery accordingly rather than insisting on a fixed, one-size-fits-all process regardless of how much groundwork has already been done independently.

On a recent project, a client was confident the site needed a simple contact form and nothing more elaborate. Discovery conversations with her actual sales team revealed that qualified leads needed multiple pieces of specific information upfront, not currently captured, or the sales team wasted real time on unqualified calls chasing details a smarter form could have gathered automatically.

That single insight, caught in a two-hour discovery conversation, changed the entire form and lead-routing design, and it was information the founder herself simply didn't have, because she wasn't the one on the actual sales calls dealing with unqualified leads every week.

A project that starts from real discovery moves faster once design and development actually begin, because far fewer fundamental questions come up mid-build, and the ones that do come up tend to be small implementation details rather than significant, direction-altering surprises. The visible early slowdown of discovery consistently pays for itself in a smoother, faster middle and end of the project.

We show clients this tradeoff explicitly with real numbers from past projects, because it's a much more convincing argument delivered with actual data than as an abstract claim about process. Seeing the comparison in real project timelines tends to settle the debate quickly.

We stopped calling it "discovery" in early sales conversations for a while, because the word itself had started to sound like unnecessary process to clients who'd been burned by slow, bureaucratic agencies before. We now describe it plainly as the specific work of catching expensive mistakes while they're still cheap to catch, which lands very differently even though the actual work underneath the label hasn't changed at all.

That reframing alone has reduced how often we have this pushback conversation in the first place, because clients understand immediately what problem this phase is solving for them, rather than assuming it's generic agency overhead standing between them and the work they actually came to us for.

Discovery feels like a delay because it doesn't produce anything visually impressive to show a client in the moment. It's actually the step doing the most work to prevent the kind of expensive, disruptive surprises that genuinely do delay a project later on.

We'd rather have the uncomfortable conversation about spending time upfront than the much more uncomfortable one, three weeks in, about why a project needs to be substantially reworked because a foundational question never got asked.

Every client who's initially resisted discovery and gone through it anyway has told us afterward it was worth the delay, once they saw what it caught. That track record is the best argument we have for holding the line on it consistently, project after project.

We keep a short internal file of these specific stories, the exact issue discovery caught and what it would have cost to find later, and we share a relevant one during the pushback conversation instead of arguing the principle in the abstract. A concrete story from a similar project tends to land faster than any general explanation of why the process matters.