An AI product operating model is the structural shift that separates the 7% who scale AI from the 93% who do not. The standard pattern is familiar to every CIO. A budget gets secured, a project team stands up, a design is scoped, an implementation runs, and the result is handed to operations to sustain. The failure rate of that pattern, applied to AI, is now well-documented.
In Brief
- Approximately 80% of enterprise AI projects fail — nearly double the rate of conventional technology programs.
- The primary cause is a category error: treating AI as a project with an end state rather than a product with a lifecycle.
- Only 7% of organisations have fully scaled AI; fewer than one in ten report measurable cost-of-delivery reduction at scale.
- High performers run a product operating model with persistent teams, outcome-based funding, and continuous workflow redesign.
- A CIO running AI as a project is funding the appearance of progress while the structural conditions for value remain unaddressed.
AI fails at the same rate across industries because the delivery model is the constant
Approximately 80% of AI projects fail, nearly double the rate of conventional technology programs (Lisowski, 2025). A 2024 BCG study of 1,000 CxOs across 59 countries found that only 26% of companies have built the capabilities needed to move beyond proof of concept, while 74% have yet to generate tangible value from AI (BCG, 2024). Gartner forecasts that at least 30% of generative AI projects will be abandoned after proof-of-concept by the end of 2025 (Gartner, 2024). Despite 88% of organisations reporting some form of AI use, only 7% indicate AI has been fully scaled (McKinsey & Company, 2025a).
Project governance violates three assumptions AI cannot satisfy
Assumption #1: Value is delivered at go-live
Project governance treats the go-live date as completion. Budgets are released and teams are disbanded. The trouble is that AI capability does not deliver full value at deployment. Value accrues incrementally across the full product lifecycle in AI — as the organisation learns how to use the capability, as workflows are redesigned around it, and as the capability itself evolves. Disbanding the team at go-live removes adaptive capacity exactly when it is most needed.
Assumption #2: Scope can be defined before the work begins
Approved business cases, defined scope, and fixed deliverables are then required before AI work begins. Snowden and Boone (2007) established that in complex systems, cause-and-effect can only be understood in retrospect. Organisations that fund AI as a project are committing capital based on assumptions they cannot yet test.
Assumption #3: Governance tracks delivery, not value
The third assumption is that governance tracks delivery against scope, time, and budget. This focus on outputs disconnects teams, leaders, and stakeholders from the value they are creating (Planview, 2025). The result is McKinsey’s most-cited finding: despite widespread adoption, fewer than one in ten organisations report measurable reductions in cost of delivery at scale (McKinsey & Company, 2025b). Adoption is an output. Earnings before interest and taxes (EBIT) impact is an outcome. The project model optimises for the first and has no structural mechanism to drive the second.
A CIO who runs AI as a project is not making the conservative choice. They are funding the appearance of progress while the structural conditions for value remain unaddressed.
The pattern persists not because CIOs are uninformed about AI’s complexity. It persists because the institutional machinery surrounding them was built for project delivery. Budget approval frameworks, investment committees, and procurement rules were designed to approve capital expenditure with a defined scope, a fixed timeline, and a depreciation schedule. Proposing a product funding model requires reclassifying that investment, approving open-ended scope, and shifting the performance framework from milestone delivery to outcome metrics. Project governance is not chosen because it works for AI. It is chosen because it is what the existing institutional machinery can approve.
Seven in ten CIOs will run a product model within five years
Under a product operating model (POM), technology capabilities that continuously evolve are conceived as long-lived product value streams rather than one-off initiatives. This is the project-to-product shift Mik Kersten (2018) describes: funding, team structure, release cadence, and the measure of success all change as a consequence.
Gartner research finds CIOs expect 70% of their work to use a product-based delivery model within five years. The defining attributes are empowered product teams, value stream-based organisation, outcome-driven metrics, and sustainable funding (Planview, 2025). None of these can be retrofitted onto a project team at a handover point.
The evidence on what this produces is consistent across the major research bodies. McKinsey, drawing on more than 200 at-scale AI transformations, finds that an agile product delivery organisation with well-defined delivery processes is strongly correlated with the achievement of value from AI (McKinsey & Company, 2025a). BCG’s AI at Work 2025 study, drawing on 10,600 worker responses across 11 countries, finds that while 72% of respondents use AI regularly, the value is captured by the smaller subset of companies that go beyond tool deployment to redesign workflows (BCG, 2025). Workflow redesign is not a project activity that can be completed and handed to sustainment. The team that handed it to sustainment is no longer watching what changes.
The four structural shifts of the product model
Four structural shifts distinguish the product operating model from a project delivery model.
Shift #1: The IT function is built around technology, not the customer
The first shift is from technology systems to customer outcomes. The traditional IT function is organised around technical affinity: infrastructure, application, data, and security teams, each accountable for a technology domain rather than a demand segment. That structure made sense when technology was a support function that responded to business requests. It does not make sense to embed AI within the workflows through which citizens and customers are served, decisions are made, and value is delivered. Customer-centricity in an AI product model means starting from a customer need or a demand signal — what are customers trying to accomplish, where does friction accumulate in that journey, and what would value delivery actually look like — and then designing AI capability to fulfil that need. The product team’s north star is customer outcome, and every technical decision is downstream of that orientation.
A Target Operating Model (TOM) cannot reliably drive this shift because, as a design instrument, it clusters functions by technical or organisational affinity and then defines how those clusters interact. The output is an accountability map, not a value delivery system. It describes who owns what, but it does not hardwire the feedback loop between customer demand and the capability that serves it. So, while a TOM promises reduction in duplication, costs, throughput, and other benefits, it fails to deliver.
An AI product model built on TOM logic will tend to reproduce the same siloed ownership patterns in a new form: an AI centre of excellence that governs models, a data function that owns pipelines, a business unit that owns outcomes, and no persistent team that holds all three together in service of a specific customer need. The organisations that scale AI have replaced the TOM’s static ownership structure with a product team that continuously adapts to what customers need.
Shift #2: Long-lived product teams
In a project model, teams are assembled around a scope and disbanded at completion. In a product model, a stable, cross-functional team owns a product value stream across its full lifecycle. That team accumulates institutional knowledge about what the product does, how it behaves in production, and where its current limits sit. That knowledge is the primary asset that enables adaptation, and it cannot be transferred via a handover document to an operations team.
Shift #3: Continuous funding over project budgets
The AI funding model is the third structural change. Continuous funding replaces project budgeting. The product model substitutes cost-centre budgeting and organisational charts with flow metrics that connect technology investment to business results (Kersten, 2018). Product funding allocates capacity to a value stream and adjusts that allocation based on outcomes delivered. The accountability question changes from “did we deliver what we said we would?” to “are we delivering the value we committed to?” For AI, where value is harder to predict in advance and larger in scope than any single project can capture, the second question is the only one worth asking.
Shift #4: Outcome metrics over outputs
Outcome metrics then displace output metrics. Gartner finds the top 20% most effective organisations are 3.2 times more likely to use product teams measured on outcomes. McKinsey’s research is consistent. Embedding AI into business processes and tracking key performance indicators (KPIs) for AI solutions are among the management practices that most distinguish high performers (McKinsey & Company, 2025a). These practices require ongoing measurement, feedback loops, and the authority to change direction when the data indicates the current approach is not generating value. Project governance structures provide none of those things.
The product model runs on experimentation, not planning cycles
Eric Ries’s build-measure-learn cycle, introduced in The Lean Startup (Ries, 2011), formalises the discipline. Each new AI capability is treated as a hypothesis to be tested rather than a plan to be executed. The team builds the minimum viable version, measures what happens in the system, and learns whether the hypothesis was correct before committing to scale.
Applied to enterprise AI, workflow redesign becomes continuous rather than episodic. A task-centric approach enables organisations to pilot AI solutions on a task-by-task basis, scaling what works and adjusting or abandoning what does not (Jadad-Garcia & Jadad, 2024). Where traditional teams optimise on periodic reviews and lagging metrics, AI-first product organisations enable continuous optimisation. Real-time data guides dynamic backlog adjustments, surfaces emerging opportunities, and converts reactive planning cycles into adaptive operations (Davis & Lopes, 2025).
Enterprise AI governance and funding are the hardest shifts to make
The product model creates real organisational friction. It challenges budget cycles, reporting structures, enterprise AI governance frameworks, and performance management systems that have been optimised for project delivery over decades.
Traditional IT governance manages risk through scrutiny of plans before they are executed. In a product model, the risk management mechanism is different. Small, reversible experiments with measurable outcomes carry the risk, and the authority to change direction is built into the operating model rather than requiring a separate approval cycle. AI moved from side projects into core workflows faster than enterprise controls evolved. When AI is acting inside HR, procurement, finance, and compliance workflows, governance can no longer sit only in a model review committee (Sabu, 2026).
Moving to product funding requires finance functions to reclassify technology investment from capital expenditure, which implies a known end state and is depreciated over a fixed asset life, to an ongoing operating investment in a value-generating capability. That change touches how business cases are written, how investment committees review AI spend, and how CFOs measure return on technology investment. The organisations that have made the shift connect investment explicitly to outcomes and adjust allocation based on what the product team learns, rather than what it originally proposed.
None of this is straightforward. The alternative is equally well-evidenced. If pilots are not moving EBIT, the problem is likely operating model and measurement, not the AI model itself (McKinsey & Company, 2025b).
What this means for senior leaders
- AI program governance designed for approval rather than adaptation is a project structure. It will produce project outcomes. Check whether your current governance can change direction without a new business case — if it cannot, the structure is the constraint.
- The funding model determines the delivery model. A capital project with fixed scope and a completion date will generate project outcomes regardless of how the team is structured. Long-lived funding allocation tied to a value stream is the structural precondition.
- Measure AI program performance against delivery outcomes: cost of delivery against capex and opex forecasts, service delivery improvement, workflow throughput, and decision quality. Adoption rates, licences deployed, and training completions are output metrics that will not get you there.
- Retain persistent, cross-functional product teams beyond go-live. The team that builds the capability is the team that continuously improves it.
- The CIO who removes the structural condition — project governance applied to a product problem — stops funding the appearance of progress and starts funding the accumulation of value. That is the only governance decision that changes what the AI spend produces.
The cost compounds across budget cycles. Each project cycle leaves the organisation one position further behind the cohort running persistent product teams. The capability gap between the 7% who have scaled and the 93% who have not is not a technology gap — it is a governance and funding gap that widens with each cycle that reproduces the project model. The organisations closing that gap now are not doing so with better models. They are doing so with a different funding structure.
References
- Boston Consulting Group. (2024, October 24). Where’s the value in AI?
- Boston Consulting Group. (2025, June 26). AI at work 2025: Momentum builds, but gaps remain [Press release].
- Davis, C., & Lopes, A. (2025, September 11). Product management in the era of AI. CIO.
- Gartner. (2024, July 29). Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025 [Press release].
- Jadad-Garcia, T., & Jadad, A. R. (2024). The foundations of computational management: A systematic approach to task automation for the integration of artificial intelligence into existing workflows. arXiv.
- Kersten, M. (2018). Project to product: How to survive and thrive in the age of digital disruption with the Flow Framework. IT Revolution Press.
- Lisowski, E. (2025, June 24). Why AI projects fail — and what successful companies do differently. Addepto.
- McKinsey & Company. (2025a, November 5). The state of AI in 2025: Agents, innovation, and transformation. QuantumBlack.
- McKinsey & Company. (2025b). AI at work but not at scale.
- Planview. (2025, January 9). The case for adopting a product operating model.
- Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Crown Business.
- Sabu, M. (2026, March 18). Enterprise AI governance: Complete framework for 2025. Neuwark.
- Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 85(11), 68–76.
