A business owner calls and says: we need a new website.

The commercially obvious response is to ask about pages, timelines and budget. It is also, quite often, the response that wastes their money.

Because "we need a new website" is not a problem statement. It is a solution the owner has already selected, on their own, based on incomplete information. The actual problem is somewhere behind it, and they have not been asked about it yet.

What is usually behind the request

Ask why, a few times, and the requests resolve into something quite different:

"We need a new website" → enquiries have dropped → they dropped after a competitor started ranking above us → nobody has looked at search visibility in three years. The website may be fine. The problem is that nobody can find it.

"We need a mobile app" → customers keep calling to ask about order status → nobody can answer without checking three systems → the systems do not talk to each other. An app would be a fourth place the same disconnected data fails to appear.

"We need a CRM" → leads are getting lost → they get lost because four people handle enquiries with no shared record → and none of them agree on what counts as a lead. Buying a CRM before settling that definition produces an expensive shared record of a disagreement.

In each case the request was reasonable. In each case, building it would have cost real money and left the underlying problem untouched.

Why owners arrive with a solution

Not because they are naive. Because of how the situation reaches them.

They noticed a symptom — revenue, complaints, workload. They looked around at what similar businesses have. They read something. They asked someone. Then they translated all of that into the most concrete-sounding thing they could name.

Naming a deliverable feels like progress. "We need a new website" is actionable. "Something in how customers reach us is broken and I am not sure what" is uncomfortable and harder to act on, even though it is more accurate.

So the specific request is not the diagnosis. It is the owner doing their best with the information available, and it deserves to be taken seriously as evidence rather than accepted as an instruction.

How to run this conversation

If you are the one being asked, or you are the owner asking yourself, these questions do most of the work.

"What changed?" Almost nobody wants a new website in a stable, satisfactory situation. Something moved. Revenue, a competitor, a complaint, a departure. Whatever changed is usually much closer to the real problem than the request is.

"What would be different if this worked perfectly?" This converts a deliverable into an outcome. "More enquiries" is a different project from "the site stops embarrassing us in client meetings" — and both are legitimate, but they are not the same build.

"How will you know it worked?" If there is no answer, there is no problem definition yet, and building anything is premature. This question is uncomfortable and it is the most valuable one on the list.

"What have you already tried?" Previous attempts tell you what has been ruled out and, often, that the same misdiagnosis has been made before.

"Walk me through what happens when a customer contacts you." Step by step, no technology talk. This is where the real problem usually surfaces, because the owner is describing reality rather than a plan. Listen for the pause where they say "and then it depends who is around".

When the request turns out to be right

Sometimes it is. Sometimes the website genuinely is the problem, and the diagnosis confirms it.

That is a good outcome, not a wasted exercise. You now build with a clear definition of what it needs to achieve and a way to tell whether it did. The same build, with a target attached, is a substantially better project than the same build with a page count attached.

The uncomfortable version

This principle has a cost, and it is worth being straight about it.

Sometimes the honest conclusion is that the thing being asked for should not be built at all. Sometimes it is that the constraint is not something a supplier can fix — a pricing problem, a staffing problem, a market problem.

Saying so means declining work. That is the actual test of whether a supplier is diagnosing or selling, and it is not a comfortable test to pass.

But the alternative is building something well that solves nothing, taking the money, and watching the client conclude that digital investment does not work for businesses like theirs. That outcome is worse for everyone, including the supplier, just on a longer delay.

If you are the owner

You do not need to arrive with a diagnosis. That is not your job.

Arrive with the symptom. What changed, what it is costing you, what you have tried. Then be suspicious of any supplier who agrees with your proposed solution before asking what made you propose it.

The right first question is not "what should we build?" It is "what is actually wrong?"