There is a sentence I use occasionally that sounds absolutely dreadful if you remove all the context.
I'm not going to give you what you want. I'm going to give you what you need.
Excellent. A warm, collaborative opening from a man you'd definitely like to hire.
Fortunately, that is not how the conversation actually starts.
It starts with me listening.
Somebody tells me what they want built, changed, fixed or promoted. They may already have chosen the platform. They may have screenshots. They may have written a feature list. Somebody may have told them they definitely need an app, a membership system, an AI chatbot or a complete new website.
All of that is useful information.
It is not necessarily the brief.
People naturally describe problems through the solutions they already know about. If somebody says, “I need a new website,” they may genuinely need a new website. They may also need a better way to publish. They may have a sales problem that happens to end on the website. They may have three broken pages and have somehow convinced themselves the only respectable response is to rebuild everything.
Or they may be completely right from the beginning.
My job is to find out which.
The thing somebody asks for is evidence, not an inconvenience
I do not think clients are foolish for arriving with a proposed solution.
I do exactly the same thing.
If something annoys me, I immediately start imagining how I would fix it. By the time I involve somebody else, there is a good chance I have already designed half the answer in my head.
That makes the proposed solution valuable. It tells you what the person has noticed, what they care about and how they currently understand the problem.
What it does not automatically tell you is whether the proposed solution is the best use of their money.
Take a media-rich website. A lean site with embedded video can be exactly right. But if the owner needs to publish written posts, video, audio and podcasts themselves every week, “website” is only the visible part of the job. The underlying need is an editorial workflow.
The noun in the request is evidence.
It is not always the brief.
Saying yes is often the easiest answer
If somebody asks whether I can build something, the answer is frequently yes.
Yes, I can build the feature.
Yes, we can use that platform.
Yes, we can add another workflow.
Yes, we can make the system substantially more complicated if that is what everybody would like to do with the afternoon.
Saying yes is commercially convenient. The client feels heard. The scope grows. The invoice may grow with it.
Then everybody discovers later that an impressive amount of work has gone into solving something that was never particularly important.
I have become much more comfortable saying no as I have got older.
Not the performative consultant version of no, where disagreeing with somebody is treated as proof of superior intelligence. Just a straightforward: I don't think that's the best use of your money, and here's why.
Sometimes that means, “We can do it, but I wouldn't do it yet.”
Sometimes it means, “You don't need the custom system you've described.”
Sometimes the supposedly technical problem turns out to be a process problem.
And sometimes, after asking all the questions, the conclusion is: yes, you were right. Let's build exactly that.
The aim is not disagreement.
The aim is that agreement should be a conclusion rather than a reflex.
The consultation is part of the work
I used to undervalue the initial conversation because it felt like the bit before the real work began.
I think almost the opposite now.
On plenty of projects, some of the most valuable work happens before anybody opens a design tool or writes code.
What are you actually trying to achieve? Who is this for? What do they do now? What happens after launch? What changes every week and what changes once a year? Who has to maintain this? Which part is essential to the business and which part has made its way into the brief because everybody currently seems to be talking about it?
Those questions are not ceremony. They change the answer.
Sometimes the result of a good consultation is a larger project because the original request did not account for the real operational need.
Sometimes the result is a much smaller one.
I like the second outcome more than you might expect for somebody who earns money from projects.
If I can tell somebody they do not need to spend £10,000 solving a £1,500 problem, I would rather do that. It gives me a much better chance of still being the person they call when a real £10,000 problem arrives.
AI lets us execute the wrong idea faster than ever
This matters even more now because production has become incredibly cheap in certain areas.
Give a capable AI system a coherent goal and it can move towards it with remarkable speed. Code, copy, research, images, structure — the first plausible answer can appear before the problem has been properly understood.
That is brilliant when the direction is right.
When it is not, you have simply industrialised the mistake.
This is one reason I think experience remains useful in an AI-assisted workflow. Not because experienced people have exclusive access to the tools. They do not. Most of the interesting tools are available to anyone with a browser and a subscription.
The value is recognising when a brief is incomplete, when one feature is about to create three more jobs, when the elegant technical answer is wrong for the person who has to operate it, and when the sensible thing is to leave something alone.
I use AI constantly. I just do not particularly want to become better at building the wrong thing.
There is no clever diagnostic framework
This is the point where an article is normally expected to provide a five-step method.
Listen. Diagnose. Reframe. Recommend. Heroically save client.
No.
Real conversations are not that tidy.
You listen to what somebody says and, just as importantly, what they keep returning to. You ask what happens next. You look at the workaround they are using now. You notice which details they care about and which ones they have simply assumed must be part of the solution.
Then you make a judgement.
Experience helps, but experience can also make you dangerously confident. Once you have seen a pattern ten times, it becomes easy to decide that the eleventh person must have the same problem before they have finished explaining it.
That is why the provocative line only works if the listening comes first.
If I am asking somebody to ignore their first instinct and spend money in a different direction, I should be able to explain exactly why.
What problem does my route solve that theirs does not? What trade-off are we making? What are they giving up? What happens if my diagnosis is wrong?
If the recommendation cannot survive those questions, it may just be my preference wearing a professional jacket.
The best outcome should feel obvious, not victorious
I do not want the client to leave thinking I have defeated them in a strategic argument.
The best outcome is much less dramatic.
We talk long enough that the better route becomes obvious to both of us.
“Oh. Yes. That makes more sense.”
Good.
No ceremony required.
They have to live with the thing after I leave. They have to operate it, explain it, pay for it and maintain it. The solution should still belong to them.
So yes, the line remains true.
I'm not going to give you what you want. I'm going to give you what you need.
But only if, after properly understanding what you want, I have a genuinely better reason for suggesting something else.
Otherwise I'm not consulting.
I'm just being difficult professionally.