The brief that starts with a solution

“We need an app.”

“We need a new website.”

“We need a dashboard that shows everything.”

These are reasonable requests. They are also solutions to problems that nobody has fully described yet.

And that distinction matters. Because the fastest way to waste a development budget is to start building something before everyone agrees on what it is supposed to solve.

The problem behind the request

A customer asks for a mobile application. After a few conversations, it turns out their actual problem is that customers cannot track orders without calling support.

An app might solve that. So might a customer portal, a notification system, or a small improvement to an existing website.

The right answer depends on the problem, not the format in which the request arrived.

Before discussing frameworks, features, or delivery dates, we want to understand a few things:

• Who is the user? Not just their demographic, but what they are trying to accomplish.

• What is failing today? A slow process, missing information, unnecessary manual work, or something else.

• What does success look like? Fewer support requests, faster transactions, better conversion, or measurable time saved.

• What already exists? Sometimes the required functionality is already there but difficult to find or use.

None of these questions requires a development sprint. All of them can prevent an unnecessary one.

The expensive word is “just”

“Just add a filter.”

“Just connect it to our CRM.”

“Just make it work on mobile.”

Small sentences can hide significant technical decisions.

A filter depends on data structure, performance, and how results should behave. A CRM integration depends on authentication, data mapping, error handling, and the limitations of another system. Mobile support means more than shrinking a desktop layout.

The problem is rarely that these things are impossible. It is that nobody accounted for them when estimating the work.

Good discovery makes the invisible parts visible before they become unexpected costs.

Build the smallest useful version

There is a difference between a minimum viable product and an unfinished product.

A useful first version should solve one meaningful problem completely. It does not need every possible feature, but the features it includes should work properly.

That means defining what belongs in the first release, what can wait, and which assumptions still need validation.

For example, a customer portal might initially need only three things:

• A clear view of order status.

• Access to relevant documents.

• A way to contact support.

Advanced reporting, custom notifications, and integrations can follow once there is evidence that users need them.

This is not about cutting corners. It is about investing in the right order.

Clarity is a deliverable

A good discovery phase does not have to produce a hundred-page document.

It should produce something more useful: a shared understanding of the problem, a realistic scope, identified risks, and clear priorities.

Designers know what experience they are creating. Developers understand the expected behaviour. Stakeholders know what they are paying for and what will be delivered.

The best projects do not start with everyone agreeing that the idea sounds good.

They start with everyone understanding what they are actually building, and why.