Thirty years ago, a consultant newly arrived in Hong Kong spent the first week on the job being shown a system the company was proud of. Sit down, watch the demo. Afterwards came a single question: how did this get designed the way it did? The answer was not an explanation but the fact itself — it was completely wrong. Millions of dollars and hundreds of hours of work, and the thing was entirely wrong. The person brought in to fix it happened to be the one who would actually have to use it.
Guessing Isn’t the Mistake; Guessing to the End Is
Some say the IT people were doing their best, that guessing wrong is not negligence — requirements are inherently hard to state. True, users can describe today’s pain but not tomorrow’s shape; that half is conceded. But precisely because requirements are hard to state, the cost should buy earlier and smaller confirmations: ask, revise, ask again. Not a full round of guessing, built to completion, with the finished product presented to users for the first time. The error is not in guessing; it is in guessing all the way down. Requirements that cannot be stated call for a denser rhythm of confirmation, not for never asking at all.
Silence Is Trained Into People
Others dig up the original exchange: why didn’t anyone ask the people who would actually use it? The answer: they didn’t want to get involved. Sounds like the users should carry the blame. But the silence was engineered — a history of asking and being ignored teaches people to stop raising a hand. Suggested, no follow-up; changed, no feedback; round after round, anyone learns to save the effort. Making people willing to speak up is the project’s first investment, not the users’ obligation. Where no one invests, no one speaks; and a system built without a word has every cell filled in by guesswork.
New Tools, Same Absence
Still others say agile and MVP solved this long ago — the story is thirty years old. The tools updated; the absence did not. An MVP still designed by the people guessing at requirements merely slices one big error into a stream of small ones — the trial-and-error cycle got faster, but the target is still drawn on the user’s behalf. The old military saying — no plan survives first contact with the enemy — says the same thing: everything before contact is a hypothesis. Only the person taking the bullets can draw the target accurately.
After Launch, the Error Becomes a Fact
Then build first and fix later — progress is value, isn’t it? For the millions of dollars spent on that “completely wrong” system, the priciest part of the bill was not the rework. Once launched, the thing grew into the correct shape: processes bent around it, reports flowed from it, and everyone who came later treated it as a fact to be maintained. Changing a system nobody uses is hard; changing an erroneous system the whole company runs is ten times harder — it has been wrong so long that wrong looks right. Users need over a hundred hours with a new technology before it really clicks, and the cost of learning it wrong equals the cost of learning it right, except the tuition is only paid once.
Ask Who Was Consulted, and Learn How Deep the Error Goes
This category of failure is not technical; it is failure by absence: who drafted the requirements determines how deep the errors run. To judge whether a system will work, skip the demo and read the draft — check whether the draft carries the end users’ fingerprints. No fingerprints, no system; just a riddle. A lucky guess is luck; a wrong one is millions of dollars. Tools have changed generations in thirty years, but one clause never changed: questions no one asked will eventually be answered, with interest.
