Why discovery comes before code

Picture the scene: a client shows up with a brilliant idea for a new app they’re sure will be a hit. They talk excitedly about the software they want to launch, but once you ask a few questions slightly outside common knowledge, it becomes clear they don’t have much clarity on what exactly needs to be built. That’s not a failing on their part — knowing that isn’t their job. It’s ours, the people building it, and it’s a software studio’s job to ask before a single line of code gets written. That’s where a term common inside software companies, but unfamiliar to most people outside them, comes in: “product discovery.”

What discovery actually solves

Discovery isn’t red tape, and it isn’t a decorative step before the “real work” starts. It’s when ambiguous scope turns into written decisions: which flows exist, what data goes in and out of the system, what’s mandatory for the first release, and what can wait.

Without it, every architecture decision is a guess. And a wrong guess in week one costs far more to fix than the same guess in week ten, once there’s real code, real data, and real users depending on it.

The cost of fixing a scope problem grows as the project advances — low during discovery, high once there’s code, real data, and users already in production.

Marty Cagan, of the Silicon Valley Product Group and author of INSPIRED, describes discovery as what separates teams that validate an idea before building it from teams that just build and hope it works out. Teresa Torres, author of Continuous Discovery Habits, pushes the discipline further — not as a one-off event at the start of a project, but as an ongoing habit throughout the product’s life. We apply the same logic at the start of every project: validate before committing development time.

The real cost of skipping it

The problem with skipping discovery doesn’t show up right away. It shows up later, as rework:

• A feature built the wrong way, because nobody asked how the process actually works in the client’s day-to-day
• An architecture that can’t handle a use case that only came up in the second meeting
• A deadline that seemed reasonable and becomes impossible once the real scope surfaces halfway through the project

This cost isn’t hypothetical — it’s the most common reason software projects run late or over budget. And the root cause is almost always the same: someone started coding before fully understanding the problem.

A practical example

Take a common scenario: a client asks for a system to manage appointments. The scope looks straightforward — register time slots, professionals, clients. But before any code gets written, a few basic questions reveal the company actually has two locations with independent schedules that sometimes share the same professional between them: an obvious detail to anyone who works there every day, but no one had mentioned it because it never occurred to them it was worth saying.

Caught in week one, that’s a tweak to the database design. Caught in week ten, with schedule, professional, and client already modeled as fixed entities belonging to a single location, it means rebuilding the whole foundation.

How this works

Before any code, the discovery phase produces an objective document: scope for the first release, core flows, technical decisions that can already be made, and open questions that still need an answer from the client. That document isn’t a formality — it’s what guides every architecture decision that follows.

That means a bit more time before writing the first line of code. In practice, it’s time that pays for itself: less rework, fewer reversed decisions, fewer meetings that start with “this isn’t quite what I wanted.”

Nobody does discovery out of distrust. They do it because fixing a system built on the wrong problem costs far more than spending one extra week understanding the right one.

That’s why, when a client shows up excited, idea in hand but not yet sure what needs to be built, the first thing we do isn’t open the code editor. It’s ask the right questions.