The instinct when pursuing AI is to start with what is available. What data do we have. What capability can we access. What has the vendor demonstrated that looks relevant to our industry. That sequence feels productive because it generates activity quickly. Teams are engaged, proofs of concept are scoped, and the organisation feels like it is moving. What it is actually doing is building solutions before it understands the problem, and the consequences of that sequencing error show up months later when technically capable models sit in staging environments because nobody can make a credible case for why the business should deploy them.
I have seen this pattern repeat across banking, insurance, government, and retail with enough consistency to be confident it is structural rather than incidental. The technology is not the problem. The starting point is.
The model should follow from the decision. It almost never does.
A model built before the target decision is understood is a model built around the data that exists and the capability that is available rather than around the specific improvement the business needs. It optimises for what can be built rather than for what would be valuable. The difference sounds subtle and produces enormous consequences downstream.
When an organisation maps the decision before building the model, three things become clear immediately that are almost impossible to recover later. First, what the model actually needs to predict or classify, which determines the label definition for training data and the feature set required. Second, where in the decision process the model’s output will be used, which determines the latency requirements, the explainability requirements, and the human oversight design. Third, what the economic value of improvement is, which is the only basis on which to justify the investment and measure whether it worked.
None of those things can be retrofitted reliably after a model is built. The label definition shapes what data gets collected and how it gets annotated. Change it and the training data is wrong. The intervention point shapes the architecture. Change it and the latency and explainability requirements may invalidate the model design. The economic baseline shapes the measurement framework. Establish it after deployment and there is nothing credible to compare against. Every shortcut taken at the starting point becomes a structural constraint downstream.
What decision mapping actually involves
Decision mapping is not a workshop. It is an analytical exercise that produces a specific document with specific attributes for each candidate decision. The decision itself, stated precisely enough that two people would independently identify the same moment in the business process as the one being described. The owner, meaning the person accountable for the outcome the decision produces. The frequency, because volume determines the scale of the opportunity. The current quality, expressed in measurable terms — error rate, loss rate, false positive rate, cycle time — not in qualitative assessments of whether people feel the decision is made well. The cost of error, which is the product of frequency and consequence per error and is the number that turns an operational observation into an investment case. And the intervention point, the specific moment in the decision process where a model output, if available in time and at sufficient quality, would change what happens.
A decision map built to that specification is not a strategy document. It is an engineering brief and a business case in the same object. The engineering team knows what to build. The business knows what it will be worth. The governance question — who owns the outcome — is answered before anyone writes a line of code.
Compare that to the typical alternative. A use case identified in a workshop, assessed against vendor capability, scoped into a proof of concept, built to demonstrate what the model can do, and then handed to the business to figure out how to integrate into an operational process that was never part of the original conversation. The technical work is often good. The connection to a specific business outcome almost never is.
The silver bullet instinct is the enemy of this discipline
The reason organisations skip decision mapping is that the technology feels like the point. AI is presented — by vendors, by consultants, by the media — as the capability that changes everything, which produces the instinct to acquire the capability and then identify what to do with it. That instinct is not irrational. It is a reasonable response to a market that leads with capability and treats business application as secondary.
But AI does not create value by existing. It creates value by improving a specific decision, at a specific point, often enough and accurately enough to justify its cost. Everything before that — the capability, the model, the infrastructure — is cost. The value lives in the decision. And the decision has to be understood before anything else can be designed to serve it.
The organisations I have seen extract consistent, compounding value from AI are not the ones that moved fastest to acquire capability. They are the ones that were most disciplined about identifying which decisions they needed to improve before they selected a single technology or engaged a single vendor. The model followed from the decision. The measurement framework was designed before the first training run. The business case was built before the first line of code was written.
That discipline is not slow. It eliminates the rework, the failed deployments, and the politically difficult conversations about why the programme has not delivered that consume far more time than the mapping exercise would have. It is the fastest path to a model in production that the business will use and can measure. It just requires resisting the instinct to start with the technology, which is the instinct the entire market is organised to encourage.
