Writing
Four engagements with the same underlying problem, running from a few thousand dollars to a migration in the millions. What separated the two that moved from the two that did not was not the work, and not the client.
A large US bank was trying to decide what to sell where. They operated across several geographies, and every product decision involved trade-offs between markets, competing internal views, and a lot of assumptions nobody had written down. The way it worked was spreadsheets, email and long meetings. A decision that mattered could take months, and by the time it landed some of the reasoning behind it had gone stale.
We proposed a simulator. You put the variables in, you move them, you see what the trade-offs do to the outcome, and the argument happens against a shared model instead of against six versions of a file. Then we built a working prototype, so they could see for themselves what it was worth rather than take our word for it.
It looked like the most straightforward piece of work I had been near. Nothing to displace, no sunk cost to argue against, an obviously slow process. They used the prototype, said encouraging things, and stopped replying.
I decided they had not felt the problem enough. That is a comfortable conclusion, because it puts the failure in the client.
What undid it was a console manufacturer with the same underlying problem. They also had to decide what to sell in which market, and they had been doing it with a choice simulator built in a spreadsheet for several years. They did not need the problem explained to them. They could tell you where their version broke: two people working from files that disagreed, a launch decision made from the wrong copy, the week it took to reconcile afterwards.
They went ahead. On my theory they should have been the harder case. They already had something. The bank had nothing at all.
Then a global beverage business and a toy company, both with working manual versions of the same kind of decision, one a spreadsheet and one a PDF survey.
Both clumsy. Both functioning. Neither went anywhere, and in both cases what we showed them did more than what they had.
So it is not the presence of a tool and it is not the absence of one. What separated the console manufacturer from those two is that their version had actually broken, and somebody in the building had worn the consequence when it did.
The one that settled it is running now. A pharmaceutical client with a CRM that is failing their commercial teams received no prototype from us at all. What they got was an assessment of why it was failing: where the data goes stale, which decisions are being made without it, what the field teams have quietly stopped using. That work advanced, and is heading towards a migration worth many times more than any of the simulators.
No artefact, nothing to handle. The prototype was never the variable in any of the four.
There is an easy version of this that I want to avoid, because it would be self-serving.
If the point were that clients should be able to articulate their own problem, it would amount to blaming people for being inarticulate and excusing me from the hardest part of the job. Helping someone find language for something they have lived with unnamed is the work. So is finding the person carrying a cost, and getting them in front of whoever can spend against it. None of that is a client's responsibility to have finished before I arrive.
The line that does hold is between the event and the account of it. Something either broke or it did not. Somebody either wore the consequence or nobody did.
I can help a client name it, size it and carry it upstairs. I cannot make it have happened.
So there are three things worth checking, and all three are events rather than words.
The bank fails the first. Nothing had been attempted, so nothing had broken, so there was no consequence for anyone to have worn. The beverage business and the toy company fail the second: they had built something and it was still working, which meant there was nothing there to articulate and no amount of skill on my side would have produced it. The console manufacturer and the pharmaceutical client clear all three.
Those four run from a simulator worth a few thousand dollars to a migration in the millions. Roughly a thousandfold in value and the same thing operating underneath.
A failed attempt is the commonest way the first one gets satisfied, not the only one. A regulatory date will do it, because it arrives whether anyone acts or not. So will an incident, an audit finding, a merger that forces two incompatible processes together, or the quiet departure of whoever had been holding a fragile arrangement together. Any of those creates the event. None of them creates the person it landed on, or that person's route to money.
Ask before anyone is committed. Not what the client needs, but whether something has actually gone wrong for somebody. That fits inside a first conversation and costs nothing to find out.
If nothing had, do not record it as having been lost to a competitor. You will send people off to sharpen what you offer, when what you offer was never the problem. The two failures want opposite responses. One says improve the work. The other says stop spending time here.
And be careful what gets counted. Interest is easy to produce and tells you very little, which is how a team stays extremely busy and finishes the year with nothing much to show.
The prototype is one instance of all this. Leading with it fills the room with people who find it interesting, because attending a demonstration costs nothing and owning a problem costs something. It is useful for reducing risk, and for arming someone who has to make your case in a room you are not in. It was never going to create a reason to move.
I did not work this out from the bank. That one sat unexplained for years, filed under bad luck.
It was the engagement running at the moment that made it legible. We brought no prototype, made no demonstration, and it moved anyway, which sent me back to look at the others properly. What I found was that I had used the same move in every situation. I built something. Building was the part I was best at, and it let me avoid asking whether anything had happened to anyone in the building at all.
Clients described by type rather than name.