There is a moment in most digital projects when the team realises the question they should have answered first is the one they are now answering with code already shipped. A workflow that was assumed turns out not to be the workflow. A user who was imagined turns out not to be the user. A data model that was reasonable for the prototype turns out not to be reasonable for the production system the prototype became. Each of these is recoverable in principle. Each of them is expensive in practice.

The cost of building the wrong thing almost always exceeds the cost of taking time to figure out what to build. The work that prevents this cost is called discovery, or clarity, or scoping. It is the most under-invested phase in product development, and the reason it is under-invested is also the reason it pays for itself many times over.

What gets skipped, and why

Discovery feels like a delay. The team has an idea, the budget is approved, the stakeholders are excited, and the temptation to start building is strong. Building is visible. Discovery is not. A week of stakeholder interviews and architectural planning produces no demo and no screen. A week of building produces a working login page. The instinct to skip the first and start the second is rational under the pressure most teams operate under.

It is also wrong. The reason it is wrong is that the decisions made in the first few weeks of a project determine almost everything that follows, and those decisions are being made whether discovery happens or not. They are just being made implicitly, by the first engineer to open a code editor, instead of explicitly, by a process designed to surface them.

A few examples of what those implicit decisions look like.

The data model gets chosen by whoever sets up the database, based on what the prototype seems to need. Two years later, the system processes ten times the volume the original model can handle. The data layer gets rebuilt at a cost that would have funded the original discovery several times over.

The user gets defined by whoever writes the first user story. The product gets shaped around that user. Six months in, customer interviews reveal that the actual user is a different person with a different workflow and different incentives. The product is now half-built for the wrong person.

None of these are hypothetical. All of them are the kinds of things Product Clarity is designed to prevent.

What discovery actually produces

The output of a discovery phase is not a deck. It is a small number of decisions, made deliberately and documented in a way the build team can work against.

What to build, defined precisely enough that the team can say no to scope that does not serve the outcome. Who it is for, defined precisely enough that the team can build for that person and not for a composite of guesses. What the architecture has to be true of, so the system can carry the load it will eventually need to carry. Where the risks are, so they can be addressed in the first iteration rather than discovered in the third.

What this looks like in practice is a deliberate sequence of work. The studio runs structured stakeholder interviews to surface the real users and the workflows they need. The team maps the experience from first interaction through core workflows, in flows and wireframes that make the product tangible before code is written. Architectural decisions are made early, when they are cheapest to revisit. Risks are surfaced and addressed in the first iteration rather than discovered in the third. The output is a roadmap, a set of UX flows, and a system direction the build team can work against with confidence.

The studio's Project Polaris impact story engagement made the discovery investment particularly visible. Before any visual design was produced, the information architecture was mapped around four distinct audiences and the specific questions each would arrive with. The site that shipped performed well at a moment when the stakes were highest, because the audience analysis was already done and the team was not improvising under pressure.

In both cases the discovery work cost less than the rebuild that would have been required without it.

What changes when AI is in the toolkit

The argument above is not new. What is new is that the cost of doing discovery itself has come down. AI is genuinely useful for the early-phase work that discovery involves, and the studio uses it daily.

A few specifics. AI can draft user personas from interview transcripts in minutes. It can surface patterns across stakeholder input that a human reviewer might take days to notice. It can produce first-pass workflow maps from a description, generate architecture option sketches that would have taken a senior consultant a week to write by hand, and summarise research at scale. Work that used to consume the most expensive hours of a discovery phase can now be compressed into the output of a single afternoon. The case for discovery is easier to make, not harder.

What has not changed is the work that turns AI output into a decision. A persona generated from transcripts is a draft. A workflow map produced from a description is an artifact. An architecture option surfaced by an AI is a starting point. None of them are yet a defensible position. The work of deciding what is true, what is wrong, what is worth investing in, and what should be cut, is the expert's job, and that work gets harder, not easier, when there is more raw material in front of the team.

The studio's position is consistent: AI accelerates the draft, the expert turns the draft into a decision. The regional market is increasingly being offered the acceleration as a complete solution. It is not. It is a useful first half. The second half is what makes the discovery investment defensible.

Why the case for skipping discovery is easier to make

The honest reason discovery is often skipped is not that anyone has thought it through and decided against it. The reason is that the cost of skipping is invisible until much later, while the cost of doing the work is visible right now.

A client looking at two proposals, one with a two-week discovery phase and one without, is looking at one number that is higher and one number that is lower. The higher number requires a defence. The lower number requires nothing. The defence has to be made against a counterfactual, the rebuild that did not happen because the discovery did happen, and counterfactuals are weaker arguments than line items.

The case looks something like this. A two-week discovery phase typically costs around five to ten percent of the eventual build budget. The most common architectural rebuild required when discovery is skipped costs forty to sixty percent of the original build budget, on top of the original build. Even a single avoided rebuild pays for the discovery phase several times over, and most projects that skip discovery require more than one.

That argument is harder to make than "we can start tomorrow." But it is the argument that turns out to be true in retrospect.

What this looks like in practice

Discovery is not always called discovery. The studio calls it Product Clarity. Some teams call it scoping, or pre-build, or strategy. The label matters less than the practice. What matters is that someone is responsible for translating an idea into a buildable thing before the building starts, and that the translation is documented, agreed, and used to scope the work that follows.

Three signs that a project is heading into a build phase without enough clarity:

First, the team cannot describe the user in a single sentence that everyone agrees with. If the user is "businesses" or "stakeholders" or "the market," the user is not yet defined. If the team has different mental models of who the user is, the product is going to be built for several different people simultaneously and serve none of them well.

Second, the team cannot describe the success measure in a single sentence. "Better user experience" is not a success measure. "Customers can complete the loan application in under five minutes without calling the branch" is. If the success measure is not crisp, the build cannot be scoped against it.

Third, the architecture decisions are being made one at a time by the first available engineer rather than as a deliberate set. Architecture made this way usually works for the prototype, sometimes works for the launch, and rarely works for the second year.

None of these signs mean the project will fail. They mean it will be more expensive than it needs to be, and that the expense will be paid in rebuilds rather than in upfront work.

The case for clarity is not that it eliminates risk. It is that it moves the cost of the project's hardest decisions to the phase where they are cheapest to make.

‍