Every engagement I take begins with a stated problem. It is almost never the real one.
That is not a criticism of clients. The stated problem is what the business can see from where it is standing, and it is usually a genuine symptom. But it is a symptom, and the difference between a build that changes a business and a build that adds a dashboard nobody opens is almost entirely down to whether someone checked.
Three examples, all recent, all with the client's stated ask in the first line.
"We need faster quotes"
The client was a paraplanning firm working on fixed fees rather than hourly rates. Fixed fees sound simpler than they are: the price depends on which of five service domains a case touches, how complex it is, how many products are involved, and which discounts apply when domains combine.
The ask was a calculator. The real problem was that none of those rules existed anywhere outside people's heads. Two advisors quoting the same case could reach different numbers and both be able to defend them, which is a quiet disaster for a fixed-fee model, because the thing being sold is a price you can stand behind.
So the first fortnight of the project produced no software at all. It produced a written specification of the pricing logic, including several rules nobody in the firm had ever articulated, like exactly what happens when a multi-domain discount collides with a product surcharge. That document was most of the value. The calculator was the easy half and it only worked because the mapping came first.
Quotes now take under two minutes and there are no arithmetic errors, because there is no arithmetic being done by a person. The gain that matters more is that two advisors reach the same number.
"Our systems do not talk to each other"
A luxury yacht brokerage was running six disconnected parts: website, broker workflow, client communication, documents, back office, leadership reporting. The stated problem describes an integration project, and integration work is easy to scope and easy to sell.
The binding constraint was not the connections. It was that no single record existed for a deal. Brokers held the relationship, the website held the enquiry, the inbox held the conversation, and leadership held none of it. Wiring those systems together without first deciding where the truth lived would have produced faster movement of exactly the same confusion.
So the CRM became the centre of the system rather than the website, and everything else resolved into it. In week one that decision looked like scope creep. It was the only reason the rest of the build worked, and the integrations turned out to be straightforward once there was somewhere for data to be integrated into.
"The platform needs rebuilding"
A travel platform had grown faster than its own build. Slow navigation, drifting interface, broken forms, missing basics like password reset and SEO tags. The stated diagnosis was that it was past saving.
A rebuild is the easier sell. It sounds decisive, it produces something visibly new, and it is worth considerably more in fees.
The audit said the foundation was sound and the accumulated mess was not. So I repaired instead: navigation, page hierarchy, homepage logic, form errors, data connections, real user accounts. Less time, less money, and a platform that still carries some decisions I would not have made from scratch, which I said at the time and wrote into the roadmap so the next call could be made deliberately.
The pattern
In all three cases the stated problem was real and the fix for it would have been visible, defensible, and roughly useless.
The question I ask before building anything is not "what do you want" and it is not "what is broken". It is which constraint is actually binding, because everything else you fix is decoration. Sometimes the answer is that the software is not the answer.
That conversation costs me revenue every time I have it. It is also the single best predictor of whether a client comes back.