New capability often gets mistaken for a reason to build. The harder task is to define, in advance, what should be different once the work is done.
The tool is never the constraint
It is tempting to believe that the limit is technical, that with a better model, more data, or a larger budget the result would arrive. Occasionally that is true. Far more often the project was never blocked by capability. It was blocked by the fact that no one had said, in a single unambiguous sentence, what was supposed to be different once it worked.
Clarity is the scarce resource, and it has been scarce in every era. The abacus, the spreadsheet, and the language model all reward the same thing: a precise account of the decision you are trying to change. Give a mediocre tool a sharp problem and you will get something useful. Give a brilliant tool a vague one and you will get an expensive demo.
A vague problem cannot be rescued by a powerful solution. It can only be made more expensive.
Clarity is a discipline, not a document
People hear "clarity" and reach for a requirements document, as if understanding were something you write down once and file away. But clarity is closer to a practice than an artifact. It is the willingness to keep asking a slightly uncomfortable question, what, exactly, are we trying to make true, until the answer survives being said out loud to the person who has to live with the result.
This is unglamorous work, and it does not photograph well next to a flashy interface. It is also the only part of the process that does not go out of date. The frameworks we use today will be quaint within a decade. The habit of refusing to build until you understand will be exactly as valuable then as it is now.
Three questions that age well
Before anything gets built, we sit with three questions. They have nothing to do with which model is current, which is why they keep working.
- 01Whose decision changes? Not whose task. A faster task with no change in judgment is motion, not progress.
- 02How would we know it worked? If you cannot name the signal in advance, you will rationalise any result after.
- 03What has to bend? Every real solution forces a workflow, an incentive, or a habit to change. Name it, or it will quietly defeat you.
The three questions remain useful as tools change: name the decision that changes, the signal that shows it worked and the workflow or habit that must change with it.
