Technology companies have traditionally been very good at understanding their customers’ technology. Account teams know which platforms they operate, which products they have installed and where infrastructure is likely to change. Technical specialists understand architectures, workloads, integration patterns and performance requirements. Product teams can explain increasingly sophisticated capabilities in considerable depth.
AI creates a problem with this model. Knowing a customer’s technology does not necessarily tell you where AI can create value. The most consequential AI opportunities often begin somewhere else entirely: with a business outcome that needs to improve, a process that produces that outcome and a decision within that process that could be made better. Finding those opportunities requires a different kind of expertise, one that many AI technology companies have historically treated as peripheral to how AI opportunities are created. It requires understanding the customer’s business.
Knowing the industry is not the same as understanding the domain
Technology companies frequently describe themselves as having industry expertise. The distinction between industry familiarity and domain expertise, however, is important. Knowing that a customer is a bank, insurer, retailer or healthcare organization provides context. Knowing its technology estate provides another layer of understanding. Neither necessarily means someone understands how that business actually operates.
Banking provides an obvious example. A bank is not a single collection of generic banking workloads. Payments alone span issuing, acquiring, merchant acceptance, authorization, clearing, settlement, disputes and multiple payment schemes. Fraud manifests differently across those journeys. The available evidence, decision window, intervention and economics change depending on where in the journey the problem occurs.
Consider a proposal to use AI for fraud detection. It sounds like a legitimate use case, but it is barely a use case at all. Is the problem card-not-present fraud on the issuer side, merchant fraud on the acquiring side, account takeover, authorized push payment scams, mule activity or something else? At what point can a decision be made? What information is available at that moment? What action can follow the prediction? What happens when the model is wrong? Without those questions, “fraud detection” describes a category of problems rather than a problem that can be solved.
The same applies elsewhere. “Claims fraud” is not yet a healthcare or insurance use case. “Customer churn” is not yet a telecommunications use case. “Predictive maintenance” is not yet a manufacturing use case. Each becomes meaningful only when it is placed inside a business journey, attached to a specific decision and connected to an intervention that changes an outcome. That requires considerably more than knowing which technologies the customer uses.
AI changes where opportunity discovery has to begin
Traditional enterprise technology selling could often begin with a recognizable technology requirement. A customer needed additional capacity, a database, middleware, storage, security, an application platform or a technology refresh. The requirement created the opportunity, and the technology organization frequently controlled both the evaluation and much of the investment decision. Some AI markets continue to work this way. Organizations are actively establishing AI capabilities and acquiring the infrastructure and platforms required to support them. In those situations, technology-led selling is entirely rational because a recognized technology requirement already exists.
The mistake is assuming that demand for AI in general automatically creates demand for every AI technology. Where customers are not already seeking a particular capability, the vendor has a different problem. It cannot simply capture existing demand. It has to help create a reason to invest. Describing model support, inference performance, accelerators, deployment architectures or data locality may establish technical credibility, but none necessarily establishes why the customer needs the capability in the first place.
That changes opportunity discovery. Instead of beginning with “Where could you use our AI technology?”, the conversation has to begin much closer to “Which business outcomes are currently unacceptable, and which decisions are preventing them from improving?” The difference sounds subtle. Commercially, it is enormous.
Domain expertise finds where AI matters
Once the starting point moves from technology to business outcomes, domain expertise stops being an optional addition to the conversation. A genuine domain expert can decompose a business into the journeys through which value is created, protected or lost. Within those journeys are decisions. Some are already automated with static rules. Some depend on intelligence that arrives too late. Some rely on incomplete information. Others remain manual because the consequences of making the wrong decision are significant. These are potential AI opportunities, but the task is not to brainstorm everything AI could conceivably do. It is to identify decisions where better prediction, classification, detection or recommendation can change an action while there is still time to influence the outcome.
Fraud illustrates the distinction particularly well. A generic conversation about fraud detection can quickly become a discussion about models, accuracy and inference. A domain-led conversation starts with the fraud vector and works backwards through the journey. It asks where the institution first has sufficient evidence to recognize the behavior, which decision can be changed at that point and which interventions are operationally possible. That understanding also reveals where AI is unnecessary. Some problems are better solved through deterministic controls, process changes or existing systems. Others may be interesting analytically but have no practical intervention. Domain expertise does not simply create more AI opportunities. It helps eliminate weak ones, an important commercial function when technical possibility is almost unlimited but customer budgets are not.
Economics determines whether it is worth doing
Finding a decision that AI can improve is still not enough. The next question is what improving it is worth. This is where another capability is frequently missing from technology-led AI conversations. Technical improvement and economic value are not the same thing. A relatively small improvement to a decision made millions of times can be enormously valuable, while a dramatic improvement to a low-value or infrequent decision may have little economic consequence.
The economics also need to include what happens after the prediction. Detecting more fraud has value, but false positives create customer friction, investigation costs and potentially lost transactions. Improving payment authorization can increase revenue, but only if additional approvals are legitimate. A retention model creates value only when an intervention changes the behavior of a customer who would otherwise have left. Model performance alone therefore tells us surprisingly little about the value ultimately created.
The business case needs to follow the entire chain from prediction to decision, from decision to intervention and from intervention to economic outcome. Predicting an outcome without changing it creates insight, not necessarily economic value. It is only when the chain between AI and economic outcome becomes credible that the opportunity becomes genuinely investable.
The missing role connects technology, domain and economics
The critical role is now easier to define. Technical expertise determines what the technology can do and where it is genuinely differentiated. Domain expertise determines where that capability matters inside the customer’s business. Economic expertise determines whether changing the resulting decision creates enough value to justify investment. The missing role connects all three.
It requires enough technical depth to understand the company’s AI capabilities without being constrained by them, sufficient domain expertise to understand the customer’s journeys, processes and decisions rather than merely its technology estate, and enough economic understanding to translate an improvement in a decision into a credible business outcome. This is not simply solution architecture, traditional account management, product management or management consulting. Elements of all four are involved, but the accountability is different. Its purpose is to discover where a technology company’s capabilities can create differentiated business value and turn that discovery into something specific enough to implement, valuable enough to fund and repeatable enough to sell again. Crucially, this role has to exist before the opportunity does.
The role also needs to create repeatability rather than dependency. If every engagement depends on finding the one person who understands a particular business process, the organization has acquired expertise without creating scale. If the same business journey appears across multiple customers, it should become understood systematically. The consequential decisions should be mapped, common signals and counter-signals identified, economic value pools understood and technical patterns made repeatable. Where appropriate, models, integration patterns, accelerators and implementation methods should emerge around them. The first customer teaches the organization; the next should benefit from what was learned.
Over time, this creates something much more valuable than a catalogue of AI use cases. It creates a portfolio of business problems that the company understands deeply, can quantify economically and knows how to solve with its technology. That is a far stronger foundation for growth than asking hundreds of sellers independently to find somewhere AI might fit.
Why technology companies struggle to fund it
The role sits awkwardly between established organizational boundaries. Product management owns the technology and its roadmap. Sales owns revenue and customer relationships. Technical sales organizations establish feasibility. Consulting and services may own deeper business transformation. The domain and economic discovery required to create an AI opportunity can therefore appear to belong partly to everyone and completely to no one.
Each organization can reasonably conclude that another should provide it. Product management can argue that its responsibility is to create competitive capabilities and enable the field to sell them. Sales can argue that it needs propositions, references and technical support from the product organization. Technical teams can demonstrate what is possible. Consulting can provide deep domain expertise once there is a sufficiently developed customer engagement. The gap remains between them.
Traditional performance measures can reinforce the problem. Sellers are measured on pipeline and revenue. Product organizations are measured on adoption and portfolio performance. Technical teams can count demonstrations, workshops and proofs of concept. Domain discovery is harder to represent on a dashboard. Someone can spend considerable time understanding a business journey, reject several superficially attractive AI opportunities and identify one decision capable of producing substantial economic value. That may create considerably more commercial value than conducting several successful demonstrations, while generating much less visible activity. The role can therefore look expensive precisely because its value is being measured using the wrong outputs.
Many technology companies already have substantial domain expertise somewhere in the organization. It may sit in consulting businesses, industry practices, professional services or specialist teams. The problem is not necessarily that the expertise does not exist. It is where and when it enters the commercial process. If domain expertise is introduced only after an opportunity has been qualified, an important assumption has already been made: that somebody knew enough about the customer’s business to identify the right opportunity in the first place.
For AI, that assumption is increasingly questionable. Domain expertise is not simply required to deliver the solution; it may be required to discover the opportunity. Someone has to recognize that a particular decision inside a particular business journey is producing an avoidable economic loss before there is an AI project to scope, an architecture to design or a consulting engagement to deliver. Not every seller needs to become a banker, clinician, underwriter or manufacturing engineer, but the organization needs people who understand those domains deeply enough to lead discovery at the level where business problems actually exist. Otherwise the conversation naturally gravitates back toward the thing the organization understands best: its own technology.
This is ultimately a leadership decision
If sellers are measured on pipeline, product teams on adoption and technical teams on successful demonstrations, none can reasonably be expected to build a capability whose purpose is to challenge weak opportunities, develop domain expertise and establish the economics before an opportunity exists.
That is not an execution failure. It is an organizational design decision.
This distinction becomes important when AI adoption fails to meet expectations. The natural response is to examine sales execution. Perhaps the field needs more training. Perhaps marketing needs stronger messaging. Perhaps more demonstrations, customer references or proofs of concept are required. Perhaps customers simply need more time. Any of those explanations may be true, but leadership should ask a harder question first: did the organization create the capability required to discover where its AI technology could produce sufficiently important business outcomes to create demand?
Did someone understand the customer’s business deeply enough to identify consequential decisions? Could they quantify the economics of improving those decisions? Could they explain where the technology provided meaningful differentiation? Could they turn what was learned into something the wider organization could repeat? If the answer is no, disappointing commercial results should not automatically be interpreted as evidence that the field failed to execute. The organization may have asked people to sell a technical capability without first establishing enough reasons for the business to buy it.
AI go-to-market needs business expertise at its core
AI has exposed a weakness that was easier to tolerate when enterprise technology demand began with an infrastructure requirement. Knowing a customer’s technology estate remains important, but it is not equivalent to understanding the customer’s business. For AI technology companies responding to explicit infrastructure demand, traditional technology selling can continue to work extremely well. For companies that need to create demand for a differentiated AI capability, the requirements are different. They cannot assume that enthusiasm for AI generally creates a reason to invest in their particular technology.
Technical expertise explains what AI can do. Domain expertise identifies where it matters. Economic expertise determines whether it is worth doing. The critical role connects all three.
When that role is absent, product organizations can continue building increasingly impressive capabilities and sales organizations can continue generating activity around them. If adoption remains disappointing, it is tempting to ask which part of the field failed to execute. There is a more important question for leadership to ask first: did we give them something the business had a compelling reason to buy?
I have increasingly found myself working in the space between these organizational boundaries, connecting technical capability with domain expertise and business economics, then turning what we learn into approaches that others can repeat. It is work that does not sit neatly within product management, sales, technical sales or consulting, yet it often determines whether those functions ultimately connect.
Perhaps that is why the role is so easily overlooked. It belongs completely to none of the traditional functions, while holding together something that all of them depend upon: the path from technical capability to business value.
