Here is how most digital and AI transformations die. A budget is approved, a platform is chosen, an IT team is handed a mandate, and eighteen months later the company owns a data lake, a dashboard suite, and a model or two — and the business runs exactly as it did before. The technology works. The transformation didn't happen. In BCG's analysis of more than 850 companies, only 35% of digital transformations reached their value targets — and the failures cluster not on technology but on strategy, ownership, and culture.
The diagnosis is almost always the same, and it is uncomfortable: it was run as an IT project. And digital transformation is not an IT project. It is a business transformation that happens to use technology — and the moment you treat it as the former, you have already lost.
The tell: who owns the outcome
There is a fast way to know which kind of transformation you are running. Ask who owns the outcome. If the answer is "IT is delivering it and the business will adopt it," the ownership is misplaced and the project is on the failure track. When delivery teams figure out implementation while business stakeholders disengage once requirements are "handed over," adoption never comes — because nobody on the floor or in the P&L ever owned the result.
This is not a knock on IT. It is a statement about where value is created. Technology is the amplifier. The business process is the signal. Amplify a signal nobody owns and you get a louder version of nothing.
Why data mesh got this right
The clearest articulation of the fix comes from an unlikely place — data architecture. When Zhamak Dehghani defined data mesh, the lead principle was not technical. It was domain-driven ownership: the business domain that creates the data owns it, not a central IT data team. Built directly on Eric Evans' domain-driven design, the idea is to align responsibility with the business — marketing, finance, the production line — and not with the warehouse or the lake.
The second principle is just as pointed: data as a product. The domain doesn't dump data into a pipe; it serves a product, with consumers treated as customers who must be delighted. Self-serve platform and federated governance round it out — but notice the order. Ownership and product thinking come first; the platform serves them.
That is the whole transformation thesis in miniature. Put the people who own the business outcome in charge of the asset, make them accountable for it as a product, and let the technology platform serve that — not the other way around.
The lenses tell different stories
The reason transformations fail is that different parts of the organization are looking at the same initiative through incompatible lenses:
- The IT lens sees systems, integrations, and uptime. Run alone, it produces a graveyard of well-built tools nobody adopted.
- The operations lens sees throughput, downtime, quality, cycle time. It is where the actual problem lives — and where the value will or won't show up.
- The product lens sees outcomes: does this change what a customer experiences and what the business captures?
- The strategy lens asks whether today's strong capabilities are even the right ones for where the market is going.
A transformation that only wears one lens fails predictably. The job is to align them — and the connective tissue is ownership sitting with the domain, not the toolset.
The role that rises: the product manager
If the domain owns the outcome and the asset is a product, then the pivotal role is no longer the systems integrator — it is the product manager. Marty Cagan has been blunt about this: in the AI era the real product manager, the "product creator" accountable for both value and viability, has never been more in demand — while those who only manage process and hand off requirements are the ones generative AI exposes first.
This is the human core of the shift. Transformation elevates the people who can own a problem end to end — sense what the business needs, seize it with the right solution, and reconfigure the operation around it. It does not elevate the people who just operate the tooling.
AI as the equalizer — if you're built to use it
There is a reason to do this now rather than later. AI has become an equalizer. Capabilities that once required an enterprise budget are now plug-and-play: 58% of small businesses report saving more than twenty hours a month with AI, and two-thirds report cutting meaningful monthly cost. The mid-market manufacturer can now field analytical and automation capability that used to belong only to the giants.
But the equalizer only pays out for organizations built to absorb it — domain-owned, product-oriented, outcome-accountable. Bolt AI onto an IT-owned, handoff-driven org and you get the data-lake graveyard again, faster. The structural thinkers — Salim Ismail's work on exponential, increasingly AI-native organizations — are describing the same destination from the top down: purpose-led, decentralized, built around small teams that own outcomes rather than layers that own functions.
Where this leads
This is the precursor to the actual work of Transform, and it sets the sequence. Enablement first — build the foundation and upskill the people who will own the outcomes. Then product development — build the data and AI capabilities as products, owned by their domains. Then domain-driven value capture — focus on the specific problems that move the business and realise the value there.
And underneath all of it, the same rule that governs the plant floor governs the enterprise: solve the problem first, then automate. A transformation that fixes the business problem and puts ownership where the value is created will compound. One that buys technology and hopes the business changes around it will join the 65% that miss. It was never an IT project. It never will be.