Software is not a diagnosis
Q2 2026There is a phrase in medicine for prescribing before examining: malpractice. In enterprise software it is called a sales process.
I say this as someone who spent more than a decade on the vendor side, closing and delivering large deals. The best work I did in those years always ran the same way: understand the operation deeply enough that the proposal read like a description of the client's own business, then fit technology to that description. The worst deals in the industry run in reverse. The vendor arrives with the prescription written, the discovery call is a formality to find quotes for the deck, and the software goes live against a problem nobody actually examined.
The failure is well documented. Industry surveys keep finding that the large majority of enterprise AI projects fail to reach production value, and the reasons cited are rarely the model or the code. They are the surrounding facts nobody diagnosed: data that turned out to be unstructured and disconnected, workflows that were never actually defined, costs that were never weighed against a measured baseline. Those are diagnosable conditions. They were simply never diagnosed, because diagnosis was not in anyone's commission plan.
Buyers are not innocent in this. Software is a comfortable purchase precisely because it substitutes for diagnosis. Choosing a platform feels like progress and requires no one to say anything uncomfortable about the org chart. If the real problem is that two executives have not agreed on what a qualified lead is, a new CRM postpones that conversation for eighteen months at a cost of several hundred thousand dollars. The invoice is easier than the meeting. I have watched companies buy the same category of tool three times in six years, each time configuring it faithfully around the same undiagnosed process, each time getting the same result with a newer interface.
The test I use is simple. A prescription is legitimate when it names the condition, and the condition has to be stated without reference to any product. "Deals stall because we have no shared definition of qualification, and reps improvise discovery" is a diagnosis. "We need better pipeline visibility" is a symptom wearing a vendor's vocabulary. If the problem statement only makes sense in the language of a product category, the category wrote it.
None of this is an argument against software. I build with software constantly; the automation work I am proudest of took a three-hour manual task down to minutes. But the sequence was diagnosis first: weeks mapping how the work actually ran, where the errors originated, and what a minute of latency cost, before a line of automation was written. The software worked because it was fitted to an examined condition. The same software, bought off a demo a year earlier, would have automated the wrong process faster.
So the discipline, for a buyer, comes down to a few questions asked in order. What is the problem, stated with no product nouns in the sentence? What is the evidence, and what did it cost us last quarter, measured, not felt? What would we expect to observe within ninety days if the problem were actually fixed? Only then: what is the smallest intervention, tool, process, person, or nothing, that produces that observation? Vendors who welcome those questions are worth your time. Vendors who route around them are telling you what their discovery was for.
Software is a prescription. Prescriptions are wonderful, on one condition that medicine figured out long ago and enterprise buying keeps forgetting. Examine first.