Here is a strange thing about large enterprises. Ask a bank who owns their credit card product and you will get a name in ten seconds, probably with a title like VP of Cards and a P&L attached. Ask the same bank who owns the loan origination software that two thousand employees use every day, and you will get a vendor name, a project code, and a steering committee that dissolved in 2021.
Enterprises are not bad at product. A shampoo company will run four hundred consumer tests before changing a fragrance. An airline will model seat configurations to the centimeter. When the product is the thing they sell, enterprises are as obsessive as any startup. But the technology inside the company was never the product. It was overhead. And that single classification, made decades ago and never revisited, explains most of what is about to go wrong with enterprise AI.
The org chart never lies
If you want to know what a company truly believes, ignore the vision statement and read the org chart.
In most enterprises, technology reports up through a cost center. The IT function was built to be measured on cost and uptime, not outcomes. The operating model followed: the business writes requirements, throws them over a wall, and IT delivers them. Somebody owns the budget. Somebody owns the timeline. Nobody owns the question "should this exist, and is it any good?"
Everything else flows from that. Enterprises fund projects, not products. A project has an end date; you finish it, declare success, and disband the team. A product is never finished; it lives, gets used, gets measured, gets better. Tech companies figured out long ago that software is the second thing. Enterprises kept treating it as the first, which is why success was defined as on time and on budget, and why nobody ever asked whether anyone actually used the thing.
There is a deeper reason no taste ever developed, and it is worth naming: internal users are captive. An employee cannot churn from the expense tool. There is no market signal, no revenue consequence, no one-star review that matters. Every discipline improves through feedback, and enterprise software lived for thirty years in a feedback vacuum. Bad software persisted, so nobody learned what good felt like, so the muscle never formed.
The SaaS era then made the muscle even weaker. "Buy over build" was correct advice for its time, but look at what it did: it outsourced product judgment entirely. The most important product decision an enterprise made was a vendor evaluation. Procurement became the product management function. Twenty years of that, and it is no surprise that when enterprises finally need to build, the job of deciding what to build does not exist in the building.
Why it was fine, and why it stopped being fine
I want to be fair to the old model, because it was not stupid. It was rational for its era, for one simple reason: old software followed rules. If a system only ever does what it is told, then a requirements document really can capture what you need. The gap between mediocre internal software and great internal software was an annoyance, not a competitive variable. Treating it as plumbing was a defensible call.
Two things just broke that logic at the same time.
The first: AI systems do not follow rules, they exercise judgment. You are no longer specifying a form with seven fields. You are defining behavior. What should the agent do when the invoice does not match the PO? When should it escalate to a human? What does a good answer even look like, and how will we know when quality slips? These are not requirements. They are product decisions: tradeoffs, edge cases, taste, and endless iteration against data. You cannot write a requirements document for judgment. Someone has to own it, continuously.
The second is quieter and, I think, bigger: building became cheap. For the entire history of enterprise IT, engineering capacity was the bottleneck. Deciding what to build was the easy part precisely because building it was so hard; the backlog enforced discipline for you. AI has inverted this. Software that took a team a quarter now takes a small pod a fortnight, and the curve is still bending. When execution becomes abundant, the scarce input shifts. The bottleneck is no longer "can we build it." It is "should we, and what exactly, and how will we know it worked."
For thirty years, engineers were scarce and opinions were plentiful. That equation is flipping, and most enterprise talent strategies have not noticed.
You can already see the consequence in the data everyone quotes: the majority of enterprise AI pilots produce no sustained impact. The standard explanations are model quality, data readiness, or engineering talent. I do not buy any of them. The models are extraordinary, the engineers are hireable, and the data is never as ready as anyone wants but never the real blocker. What is missing is an owner. AI initiatives are being run as IT projects by organizations that structurally do not contain the job the initiative actually requires.
What the job actually is
I should be precise here, because "hire product people" is exactly the kind of advice that gets destroyed by title inflation. Most enterprises already employ hundreds of people called product owners, and most of that is agile theater: backlog administrators who translate other people's requirements into tickets. That is not the job. The job has three parts.
Judgment. The core act of product management is deciding what not to build. An enterprise that suddenly finds building cheap will drown in its own ideas; every function will want its agent, its copilot, its dashboard. Someone has to rank ruthlessly by outcome, kill the plausible-but-pointless, and concentrate force. The discipline of no is the whole game.
Taste. This word makes enterprise leaders uncomfortable because it sounds unmeasurable, but every great product organization runs on it. Taste is knowing what good feels like before the data confirms it: the sense that this workflow has two steps too many, that this agent's tone will erode trust, that this ninety percent accuracy is delightful in one context and disqualifying in another. Taste is what thirty years of captive users prevented enterprises from developing. It can be hired.
Data-backed roadmaps. This is where the craft has genuinely evolved. Modern product work on AI systems means instrumenting outcomes, not outputs: eval suites that catch quality regressions the way tests catch bugs, adoption and trust metrics for the humans in the loop, and a roadmap where every item traces to a number the CFO recognizes. Evals are the new A/B tests. A product person who cannot read them is a project manager with a different title.
And notice what the surface of the work now is. When you rebuild a process around AI, the process itself becomes the product. The claims workflow, the onboarding journey, the demand forecast: each one now ships, versions, regresses, and improves like software, with employees and customers as its users. Reimagined processes do not come from process consultants documenting the as-is. They come from product people asking what the process would be if it were designed today, and then iterating it against reality.
The scarcest hire of the next five years
So here is my actual claim. The defining talent battle of enterprise AI will not be for ML engineers, and it certainly will not be for prompt engineers. It will be for genuine product leaders willing to work inside a bank, a retailer, a manufacturer. They are rare, they are concentrated in tech companies, and the enterprises that pull them out will look prescient in five years.
But hiring them is the smaller half of the problem. The larger half is not wasting them. A world-class product leader parked under a cost-center CIO, feeding a steering committee, is an expensive way to change nothing. The role has to report where the business lives, own an outcome metric wired to the P&L, hold real authority to kill initiatives, and be paired with the deep domain operators who carry context no outsider can. Judgment plus domain is the compound. Either one alone is a pilot that dies in month four.
One more thing, said with my cards face up: I run a firm that builds these systems for enterprises, and the entire industry right now, from the largest cloud providers down, is effectively renting out this judgment through embedded engineering teams. That model works, and I obviously believe in it. But I will tell you the part that is against my commercial interest: partners can seed the capability, transfer the craft, and build the first products with you. The judgment about your business has to end up living in your business, because it compounds, and compounding only works if you own the asset.
Enterprises have never lacked capital, engineers, or ambition. What they lacked, for thirty years, was a chair at the table for someone whose entire job was to decide what deserves to exist and to care how it feels to use. The technology finally makes that chair the most important one in the room. The only question is who you put in it.
