The problem is rarely where you point

You have a product. Or a brand. Or a marketing strategy. Or an urge to leverage AI before your competitors do. So you go looking for someone to build the thing, and you arrive with the thing already named. That name may be your first problem, because it is often wrong, and not through any fault of yours. A named deliverable is a guess at the solution, arrived at before anyone looked at what is actually broken. Sometimes the guess is right, the deck really is the deck, and we build it without fuss. More often the request has passed through a few silent translations on its way to a name, every one of them dropping something, until what is left is tidy, specific, fundable, and pointing in the wrong direction.

A request is a compressed problem

A problem travels through a company in stages. Someone hits friction, a task that eats twenty minutes it should not. They mention it to support. Support writes a ticket. The ticket gets a category. The category becomes a line on a roadmap that reads “add export button.” By the time anyone with authority sees it, the person and the situation are gone.

The company is no longer solving the original problem. It is processing the latest representation of it. Some compression is unavoidable; nobody carries the full weight of every situation into every meeting. But there is a difference between compression, which drops noise, and distortion, which drops the part you needed. “Add export button” is distortion in the costume of a clear brief.

The tell is a spec that skipped a step

There are two ways to ask for the same help. The first: “We need a rebrand, a new website, and a bigger ad budget.” The second: “Sales have been flat for a year and nobody can tell me why.”

The first sounds like a plan. It is also three solutions to a problem nobody has said out loud. The second is useless as a brief and much closer to the truth. Start from the first and you will deliver exactly what was ordered, and possibly the wrong thing, on time and on budget. A client should not have to diagnose their own business to buy help with it. When a service quietly hands the hard reasoning back to the customer, it has failed at the one job it had.

A worse question than it looks

“What do you need” sounds helpful and asks for the earth. To answer it well you would already have to know the problem, its cause, the range of fixes, and the right one among them, then translate all of that into our vocabulary. Four jobs before we lift a finger.

So we start lower and truer:

What currently makes your work harder than it should be?

That question does not begin from a solution. It begins from friction, which is where the problem actually lives. A problem is never only the state of a thing. It is the relationship between that state and the person stuck with it, and the second half is the half everyone forgets to look at.

Put the decision where the competence is

None of this means ignoring what you asked for. It means placing each decision where the knowledge for it sits. You are the authority on your own reality: what you are trying to do, what it costs you, what you already tried and quietly abandoned. We are the authority on the solution space: the cause, the options, the trade-offs.

A badly run project makes one side do the other’s reasoning. The client hands over a spec they had to guess at, or the specialist assumes a context they never bothered to look at. A good one keeps the line clean, then tests the fix against your actual situation instead of the neat internal version we would prefer to be true.

Where this leaves the invoice

Sometimes the diagnosis points straight back at what you first asked for. Good. Now we build the website knowing why, which tends to produce a different and better website than the one in the brief.

Other times the honest answer is smaller than what you came to buy. A clearer sentence instead of a rebrand. Three form fields instead of eleven. A price you were afraid to raise. When that is the fix, we say so, and the invoice shrinks to match. This is not generosity, it is arithmetic. The cheap honest answer you remember beats the expensive one you resent, every time you go to recommend someone.

This is not just my hunch

The pattern shows up wherever anyone measures it. The Standish Group’s most quoted finding is that 45 percent of software features are never used and another 19 percent rarely, two thirds of the work delivering close to nothing.¹ The figure is soft, drawn from only four applications, and even its author would not push it too hard, but nobody who has shipped software argues with the direction.

McDonald’s is the cleaner case. It wanted to sell more milkshakes, so it asked milkshake buyers what to fix and tuned flavour and size on their answers. Sales did not move. Only when someone spent a day watching who actually bought them did it click: most sold at dawn, to lone commuters hiring a thick, slow drink to make a dull drive bearable.² The job was the commute, not the milkshake, and every fix aimed at the drink had missed it. In the older phrasing, nobody wants a quarter inch drill, they want a quarter inch hole.³ Most briefs order the drill.

The inconvenient part

The name on the request is where you are pointing. It is rarely where the problem is. Finding the difference costs an hour of uncomfortable questions before any money is spent well, which is exactly why most people skip it. The only real question is whether anyone in the room is willing to look in the more uncomfortable direction: at themselves, and at the company they run.

From words to done.

Sources

1. Standish Group CHAOS findings on unused features, presented by Jim Johnson at XP 2002; summary and critique by Mike Cohn, Mountain Goat Software. https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used
2. Clayton Christensen, the “Jobs to Be Done” theory and the McDonald’s milkshake study, Harvard Business Review. https://hbr.org/podcast/2016/12/the-jobs-to-be-done-theory-of-innovation
3. The “quarter-inch hole” formulation is usually credited to Theodore Levitt, Harvard Business School.