Technology investment has never been higher, and technology confidence has never been lower. Most organisations are spending more on their IT function than at any prior point in their history — and most cannot tell you with any precision what it’s returning. BCG’s research puts a number on the gap: despite more than 80% of executives having accelerated their digital investment plans, most are not capturing the value they expected — not because the funding is wrong, but because the organisational design through which it flows is (BCG, as cited in Workpath, 2025). That’s not an execution problem. It’s a structural one.
The technical operating model — IT organised around capability towers, delivery functions, and project-based investment — was built for a world where technology was a support function, change was periodic, and the boundary between business and IT was both real and useful. None of those conditions hold now. The model persists anyway, and the gap between what it was designed to do and what organisations actually need from it is widening.
The structural constraint beneath the surface
The technical operating model is optimised for one thing: resource utilisation. Projects are scoped, funded, resourced, delivered, and closed. The underlying assumption is that value can be specified in advance — that if you define the right scope, resource it adequately, and execute with discipline, the outcome will follow. On that assumption, the whole model rests.
The Standish Group has been measuring the effectiveness of operating models for thirty years. In large organisations, 9% of projects are delivered successfully — on time, within budget, with the originally specified features (Standish Group, 2021). More than half are challenged; the rest are cancelled. Average cost overruns sit at 189% of the original estimate, with time overruns averaging 222% (Standish Group, 1994). The figures have not materially improved. Three decades of refinement to the model have not moved the needle, because the model itself is the constraint.
MIT’s Center for Information Systems Research found that organisations with a defined operating model outperformed peers on efficiency, customer satisfaction, and new product development — but only when that model was built around integration and customer outcomes rather than functional structure (Ross, Weill, & Robertson, 2006). That distinction is the whole game. The technical operating model is a function-first structure. It separates the people who understand the problem from the people who build the solution, and then manages the gap between them through documentation. Something is always lost in that conversion — usually the most important thing: whether the solution being built will actually deliver what the customer needs.
The shift in executive intent is already visible in the data. Gartner’s CIO research found that organisations expect 70% of their work to use a product-based delivery model within five years (Struckman & Germer, 2024). Gartner also found that the top 20% most effective organisations are 3.2 times more likely to measure product teams on business outcomes than their peers (Gartner, 2019). The direction of travel is unambiguous — and the speed is accelerating.
Having a separate technology or IT operating model suggests you're in project mode, where 'the business' provides requirements to be delivered by 'delivery teams' — the boundary between business and technology is precisely the constraint.
The constraint is not in the people. It is in the organisational design. A technical operating model structurally separates the people who understand the problem from the people who build the solution. The handoff between business and IT — the requirements document, the brief, the scope statement — is the mechanism through which organisational knowledge is converted into a format that can be executed. Something is always lost in that conversion. Usually, it is the most important thing: what the customer actually needs, and whether the solution being built will actually deliver it.
The plan-build-run trap
Most large organisations don’t think of their operating model as “technical” — they think of it as plan-build-run. IT is divided into a planning function (strategy and demand management), a build function (development and engineering), and a run function (operations and support). The logic has surface appeal: specialisation produces efficiency, dedicated functions develop depth, and handoffs create clear accountability.
What they actually produce is a system optimised for a world that no longer exists. KPMG’s analysis of the model is direct: plan-build-run is not capable of meeting modern demands for innovation, flexibility, and speed of delivery (KPMG, 2016). CEB and Gartner research identified why — plan functions were designed to receive stable, predictable demand, but demand for digital investment is neither stable nor predictable, and the model has no mechanism to respond when it isn’t (CEB, as cited in ChannelE2E, 2016). Business strategy shifts faster than plan cycles can absorb. Development begins before the problem is adequately understood, because the specification must precede the funding. The run function becomes a brake on change rather than a platform for it.
Ardoq’s analysis of plan-build-run in enterprise architecture contexts names the deeper problem: the model “perpetuates the mindset that business is separate from IT, where the business creates ideas, and IT is the factory delivering them,” converting technology into “a delivery cost centre and a bottleneck in deploying change” (Ardoq, 2024). That factory mindset is not an accident of culture — it’s the logical product of the model’s structure. The people closest to execution are disconnected from the strategic context that would enable better decisions. The people shaping direction are disconnected from the operational reality that would constrain and sharpen their plans. The result is an organisation that produces technically correct outputs in response to strategically approximate inputs, and then wonders why the results don’t hold.
BCG’s Build for the Future research — three years of data across more than 725 executives and over 100 digital transformations — found that every one of the most successful organisations had replaced functional separation with decentralised, multidisciplinary teams that own and run what they build (BCG, 2023). The integration that plan-build-run separates is precisely what distinguishes organisations that capture value from those that don’t.
The resource constraint fallacy: optimising for management, not for value
When delivery falls short in a technical operating model, the diagnosis is almost always the same: not enough people, too much work, a backlog that exceeds capacity. The prescribed remedy follows the same logic — more resources, tighter prioritisation, better queue management. The model stays intact. The problem gets reclassified as a staffing issue.
This misdiagnosis is expensive, and it’s not accidental. Resource constraint framing serves a management structure that needs visible task allocation, clear accountability reporting, and deliverable-based progress measurement. What it doesn’t do is interrogate whether the organisational design generating the constraint is itself the source of the problem. Assigning failure to headcount is convenient precisely because headcount can be managed without touching the structure. The structure stays. The problem stays with it.
Deloitte’s analysis found that organisations lose 20–30% of revenue annually to inefficiencies caused by poor cross-team alignment and siloed structures (as cited in Insightful, 2024) — a figure rarely discussed in conversations about backlog capacity. A PwC survey of executives found that 86% cite ineffective collaboration, not resourcing, as the primary reason for project failure (as cited in various sources, 2023). McKinsey’s data shows that organisations with strong cross-functional collaboration reduce project completion times by 30% and improve productivity by 20% — outcomes that are not available to a structurally constrained model, regardless of how well it is resourced (McKinsey & Company, 2016). More people working in a broken structure produce more output from a broken structure. It doesn’t fix the structure.
Resource constraint is a description of a symptom, not a diagnosis of a cause. In most cases, the constraint is generated by the organisational design, not by the headcount.
What this means for scalability and strategic extensibility
The scalability problem in a technical operating model is not about capacity — it’s about how coordination costs change as the portfolio grows. More projects require more integration. More integration requires more governance. More governance requires more process. The system gets heavier precisely when it needs to move faster, and the additional weight compounds with every new initiative added to the portfolio.
McKinsey’s research across more than 400 publicly traded companies found that mature product operating models produced 60% higher shareholder returns, 16% higher operating margins, 38% higher customer engagement, and 37% higher brand awareness compared to the bottom half of the sample (McKinsey & Company, 2023). The study controlled for industry and geography. Time-to-market improved by up to 3x; product defect rates fell by 50-70%. Alvarez & Marsal’s enterprise research found that outcome delivery velocity increased by 40 to 50% through persistent product teams and the elimination of handoffs (Alvarez & Marsal, 2025). These are not incremental gains from process improvement. They’re the result of a different organisational logic.
BCG’s research on platform operating models provides one concrete illustration. A North American regional bank adopted a platform model — cross-functional teams combining developers, security specialists, and operations personnel — and achieved up to a 40% reduction in delivery times within nine months, alongside an expected 10 to 15% reduction in running costs (BCG, 2023). The technology didn’t change. The organisational design did.
For enterprises facing fragmented portfolios, rising run costs, and slow execution, product and platform models are no longer optional. They are becoming the default operating model for scalable technology value.
The extensibility case is equally clear. A technical operating model is designed to execute a defined scope. When strategy shifts, the model must be re-scoped, re-funded, and re-resourced before it can respond — which means strategy and execution are always slightly out of phase. A product operating model is oriented around continuous value delivery to a defined customer outcome, so strategic change requires a change in direction rather than a structural reset. The model can absorb change because it was built to respond to it, not merely to execute against it.
Cross-functional teams: the structural alternative the evidence supports
The structural alternative to functional separation is not complexity — it’s cross-functional teams with genuine end-to-end accountability. Business, technology, design, and data capability in the same team, aligned to a shared outcome, with the decision rights and funding continuity to actually deliver it. That’s the mechanism through which product operating models translate intent into performance.
The performance evidence is consistent across sources. McKinsey found that companies with strong cross-functional collaboration are 2.1 times more likely to outperform peers on revenue growth, with productivity improvements of up to 25% (McKinsey & Company, 2016, 2023). Harvard Business Review’s research found that teams combining diverse functional expertise outperform siloed counterparts by up to 30% on key metrics (Tabrizi, 2015). Gartner identified a 30% reduction in project cycle times in high-collaboration organisations (as cited in Insightful, 2024).
The caveat in the data is important. Harvard Business Review’s same body of research found that 75% of cross-functional teams fail to meet their objectives — primarily because they’re stood up without the governance structures, decision rights, and shared accountability frameworks the model requires to function (Tabrizi, 2015). A cross-functional team without genuine accountability for outcomes is not a product operating model. It’s a technical operating model with a different org chart. The question isn’t whether you have cross-functional teams. It’s whether they own the outcome or just the delivery; whether they’re funded as persistent entities or assembled per project; whether success is measured in value realised or tasks completed.
Understanding what you need from your operating model
The difference between a technical operating model and a product operating model is not primarily a question of naming or structure — it’s a question of what the organisation is actually optimised for. Technical operating models optimise for resource utilisation and delivery predictability. Product operating models optimise for value realisation and outcome reliability. The two require different governance, different funding mechanisms, different performance metrics, and different definitions of success. Most organisations attempting the transition find they’ve inherited the governance of the old model with the language of the new one.
Thoughtworks’ analysis identified this failure mode precisely: organisations adopt product thinking by name, replace the project model in name, and in doing so “ultimately reduce the value and increase the internal complexity of the organisation” (Thoughtworks, 2025). The result is the worst of both — outcome accountability without decision rights, cross-functional teams without integrated funding, product roadmaps governed by approval processes designed for projects. The presence of product teams is not evidence of a product operating model.
The diagnostic question is not “do we have product teams?” It’s “what is the organisational logic that determines how investment flows, how teams are structured, how success is defined, and who owns the outcome?” That answer is rarely in the documentation. It’s in the governance decisions, the funding flows, the escalation paths, and the performance conversations. Read those, and the real model becomes visible. Once it’s visible, the distance between the current state and a genuinely product-oriented model becomes precise — and the intervention points become clear.
The limitation of a technical operating model is not in resource constraints. It is a structural one. And structural constraints do not yield to effort, to headcount, or to better management of the queue.
References
Alvarez & Marsal. (2025). Product and platform models: The operating model enterprises need to scale technology and generate recurring business value. Alvarez & Marsal Thought Leadership. https://www.alvarezandmarsal.com/thought-leadership/product-and-platform-models-the-operating-model-enterprises-need-to-scale-technology-and-generate-recurring-business-value
Ardoq. (2024). Enterprise architecture for continuous business change. Ardoq. https://www.ardoq.com/blog/ea-for-continuous-business-change
BCG. (2023, September 25). How a platform operating model can drive agility and resilience. Boston Consulting Group. https://www.bcg.com/publications/2023/how-platform-operating-model-drives-agility-and-resilience
CEB (now Gartner). (2016, September 24). 4 reasons the plan-build-run model won’t work anymore. ChannelE2E. https://www.channele2e.com/post/4-reasons-the-plan-build-run-model-wont-work-anymore
Gartner. (2019, February 19). Gartner survey finds 85% of organizations favor a product-centric application delivery model. Gartner Newsroom. https://www.gartner.com/en/newsroom/press-releases/2019-02-19-gartner-survey-finds-85-percent-of-organizations-favor-a-product
Insightful. (2024). Why silos fail and collaboration drives real productivity. Insightful. https://www.insightful.io/blog/cross-departmental-collaboration-multiplies-results
KPMG. (2016). Next-gen IT operating model. KPMG CIO Advisory. https://assets.kpmg.com/content/dam/kpmg/xx/pdf/2016/10/Next-Generation-IT-Delivery-Models.pdf
McKinsey & Company. (2016). Making collaboration across functions a reality. McKinsey Quarterly. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/making-collaboration-across-functions-a-reality
McKinsey & Company. (2023, December 19). The bottom-line benefit of the product operating model. McKinsey Digital. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-bottom-line-benefit-of-the-product-operating-model
McKinsey & Company. (2023, June 9). The big product and platform shift: Five actions to get the transformation right. McKinsey Tech and AI. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-big-product-and-platform-shift-five-actions-to-get-the-transformation-right
Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press. [Cited in Wikipedia, Operating model, MIT CISR research.
Standish Group. (1994). The CHAOS report. The Standish Group International. https://cs.franklin.edu/~smithw/ITEC495_Resources/chaos%20report.pdf
Standish Group. (2021). CHAOS report 2021: Beyond infinity. The Standish Group International. [Summary data cited in The Escrow Company, 2021, https://www.escrowlondon.com/news/software-developement-failures-and-how-to-overcome-them/%5D
Struckman, C., & Germer, B. (2024, September 18). Leadership actions for a successful project-to-product transition. Gartner. [Cited in Planview, 2024, https://blog.planview.com/the-case-for-adopting-a-product-operating-model/%5D
Tabrizi, B. (2015, June 23). 75% of cross-functional teams are dysfunctional. Harvard Business Review. https://hbr.org/2015/06/75-of-cross-functional-teams-are-dysfunctional
Thoughtworks. (2025). How to create a product operating model to support product organisation transformation. Thoughtworks Insights. https://www.thoughtworks.com/en-us/insights/articles/how-to-create-a-product-operating-model-to-support-product-organization-transformation
Workpath. (2025, March 5). Three organisational capabilities for future-proof operating models that pay off. Workpath Magazine. https://www.workpath.com/en/magazine/three-organizational-capabilities-for-future-proof-operating-models-that-pay-off
