Upgrading the Technology Operating Model: Six Essential Themes for Turning Technology Spending into Faster Innovation, Better Customer Outcomes, Stronger Resilience, Lower Waste, and Measurable Business Value

1. Adopt the product model

2. Invest for outcomes

3. Put talent first

4. Combine global scale with local traction

5. Build delivery excellence

6. Elevate technology within enterprise leadership

These themes are interconnected. A product model cannot function effectively if teams are funded as temporary projects. Outcome-based funding will fail if leaders cannot measure product value. Delivery excellence will remain limited if developers spend most of their time navigating manual approvals and fragmented platforms. Technology leaders cannot become strategic partners if business executives continue to delegate all technology understanding to the IT department.

A modern operating model should produce five broad outcomes:

Business outcomes

• Revenue growth
• Customer acquisition
• Customer retention
• Better products
• Faster market entry
• Improved employee productivity

Delivery outcomes

• Shorter lead times
• More frequent releases
• Lower failure rates
• Faster recovery
• Better product adoption

Financial outcomes

• Clearer technology costs
• Reduced duplication
• Better investment allocation
• Improved unit economics
• Lower infrastructure waste

Risk outcomes

• Stronger cybersecurity
• More resilient systems
• Better regulatory compliance
• Clear AI accountability
• Improved operational continuity

Talent outcomes

• Greater ownership
• Stronger technical careers
• Better developer experience
• More effective use of scarce specialists
• Less coordination overhead

The organization should not attempt to transform every element at once. Bain recommends selecting one or two priority themes, demonstrating results, and expanding the transformation in a deliberate sequence.

The central lesson is:

Technology value does not come from technology alone. It comes from the operating system surrounding technology.

1. What Is a Technology Operating Model?

A technology operating model is the system through which an organization decides, funds, builds, runs, governs, and improves technology.

It connects several elements:

• Business strategy
• Product strategy
• Organization structure
• Decision rights
• Funding
• Talent
• Architecture
• Engineering practices
• Platforms
• Vendors
• Governance
• Performance management

The operating model answers practical questions such as:

• Who owns a digital product?
• Who decides which features receive investment?
• Is the team temporary or persistent?
• Does funding follow projects, departments, products, or outcomes?
• Which technology capabilities are centralized?
• Which decisions belong to individual business units?
• Who owns security and reliability?
• How are cloud and AI costs managed?
• How does the organization determine whether a technology investment succeeded?

A technology strategy may describe what the organization wants to accomplish. The operating model determines whether the organization can actually accomplish it.

2. Technology Modernization Without Operating-Model Modernization

Many organizations modernize technology in fragments.

They may:

• Migrate applications to the cloud
• Purchase an enterprise data platform
• Introduce agile delivery
• Adopt generative AI tools
• Create a digital innovation team
• Establish a cybersecurity program

These initiatives may produce local benefits. However, the wider system may remain unchanged. The cloud team still waits for annual budget approval. Product teams still disband when projects end. Business executives still send requirements to IT rather than sharing product ownership. Security reviews still occur only near launch. Data remains divided among departments. AI teams produce demonstrations that cannot access production data or pass governance reviews. This creates a modern technology stack trapped inside an old organizational system. Bain’s core argument is that companies often increase technology spending without redesigning the operating model through which technology is envisioned, delivered, and managed. As a result, returns remain lower and operating costs remain higher than they should be.

3. Common Signs That the Operating Model Is Failing

Technology spending rises while business impact remains unclear The company can explain how much it spent but not what business results the spending produced. Projects are completed, but adoption is weak The delivery team meets its deadline while employees or customers avoid the product. Business and technology blame one another Business leaders complain that technology is slow. Technology leaders complain that requirements change constantly. Teams spend excessive time coordinating Large numbers of project managers, analysts, committees, and approval groups are required to move work through the organization. Platforms are duplicated Different units purchase similar tools, build parallel data systems, or create separate customer capabilities. Centralization creates bottlenecks

A central team controls architecture, security, data, infrastructure, and purchasing, but cannot respond quickly enough to every product team. Decentralization creates fragmentation Business units move quickly but produce inconsistent systems, duplicated spending, security gaps, and incompatible data. AI remains experimental Employees use isolated AI tools, but the organization has not redesigned workflows, governance, data access, accountability, or investment priorities. These are not simply technical problems. They are operating-model problems. Theme One: Adopt the Product Model

4. What Is a Product Operating Model?

A product operating model organizes people, funding, technology, and accountability around persistent products, platforms, services, or business outcomes.

A product may be customer-facing, such as:

• Mobile banking
• E-commerce checkout
• Digital insurance claims
• Customer onboarding

It may also be an internal product, such as:

• Employee identity
• Data platform
• Developer platform
• Finance automation
• Supply-chain visibility

The defining feature is continuing ownership. The product does not end when an implementation project is completed.

A persistent team remains responsible for:

• Customer or user needs
• Product strategy
• Delivery
• Reliability
• Security
• Adoption
• Cost
• Continuous improvement

Bain identifies adoption of the product model as the central theme in many operating-model upgrades. Persistent cross-functional teams remain focused on improving the product and its business outcomes, while also balancing new features with maintenance and operational responsibility.

5. Why the Project Model Often Underperforms

A project is temporary.

It usually has:

• A defined scope
• A budget
• A start date
• An end date
• A delivery team

This model works well for genuinely temporary work, such as constructing a facility or performing a one-time migration. It is less effective for digital products that continue changing after launch. Project-based technology delivery can create several problems. Success is defined too narrowly A project may be declared successful because it was completed on time and within budget. That does not mean customers used it or the business received value. Teams disband after launch Knowledge is transferred to another group, often called operations or maintenance. The people who designed the system no longer experience the consequences of their decisions. Maintenance competes poorly with visible projects Funding often favors new initiatives while reliability, security, usability, and technical debt receive less attention. Scope becomes the center of negotiation

Business and technology teams argue about requirements instead of collaborating on outcomes.

6. Product Teams Need Cross-Functional Ownership

A product team may include:

• Product manager
• Engineering leader
• Software engineers
• Designer
• Data analyst
• Security specialist
• Operations or reliability expertise
• Relevant business experts

The precise composition depends on the product. The team should have enough capability to make meaningful progress without repeatedly waiting for external departments. This does not mean every specialist must be permanently embedded. Shared experts may support several teams. The key requirement is that responsibility is clear and important decisions can be made quickly.

7. Product Teams Need Real Decision Rights

Calling a group a product team does not create a product model.

The team needs authority over defined areas, potentially including:

• Product roadmap
• Backlog priorities
• Technical implementation
• Experiment design
• Release timing
• Use of allocated funding

The team must still operate within enterprise guardrails for:

• Security
• Privacy
• Architecture
• Regulation
• Financial control
• Brand standards

The objective is autonomy within boundaries, not uncontrolled independence.

8. Measure Product Outcomes, Not Feature Volume

Weak product organizations measure:

• Features delivered
• Story points
• Projects completed
• Hours worked

Stronger product organizations measure:

• Customer conversion
• User retention
• Task completion
• Revenue
• Cost to serve
• Employee productivity
• Reliability
• Adoption
• Customer satisfaction

Feature output may contribute to an outcome, but it is not the outcome itself.

9. Internal Platforms Should Also Be Products

Infrastructure, data, cybersecurity, and developer platforms are often managed as technical utilities.

They should increasingly be treated as internal products with:

• Defined users
• Product owners
• Roadmaps
• Service expectations
• Feedback channels
• Adoption metrics
• Cost transparency

Microsoft’s current Cloud Adoption Framework describes shared-management models in which platform teams provide reusable, self-service capabilities to workload teams. It explicitly connects this model with platform engineering and a product mindset for internal platforms.

An internal developer platform might provide:

• Approved cloud environments
• Deployment pipelines
• Identity integration
• Monitoring
• Security controls
• Managed databases
• Cost visibility

Its success should be measured by how effectively it helps other teams deliver.

10. AI Products Need Persistent Ownership

Many AI initiatives begin as experiments. A small team produces a proof of concept. The demonstration appears promising.

Then problems emerge:

• Data access is incomplete.
• Accuracy is inconsistent.
• Operating costs are unclear.
• Human review is undefined.
• Security approval is delayed.
• Ownership after launch is unclear.

AI capabilities should be organized as products when they support continuing business processes.

A persistent AI product team should own:

• Business objective
• Model selection
• Data quality
• Evaluation
• Human oversight
• Security
• Cost
• Monitoring
• User adoption
• Incident response

Theme Two: Invest for Outcomes

11. Why Project-by-Project Funding Creates Friction

Traditional funding often requires each technology initiative to produce:

• Business case
• Project scope
• Cost estimate
• Approval
• Annual budget request

The process may be repeated every year.

This creates several problems:

• Product teams cannot plan confidently.
• Funding becomes tied to a promised feature list.
• Teams struggle to respond to new evidence.
• Projects continue because budgets were approved, even when value is weak.
• Small changes require disproportionate approval effort.

Bain recommends funding product areas rather than individual projects. Persistent budgets allow product owners to adjust spending as products, customer needs, and markets evolve. Funding can then move away from products that fail to deliver and toward higher-value opportunities.

12. Outcome-Based Funding

Outcome-based funding begins with the result to be achieved.

Examples include:

• Increase digital sales conversion
• Reduce customer-service demand
• Improve supply-chain visibility
• Lower software deployment time
• Reduce fraud losses
• Improve employee onboarding

The product team receives a budget and remains accountable for progress against the result. The team may change its roadmap as evidence develops. This creates flexibility while preserving accountability.

13. Persistent Funding Does Not Mean Permanent Funding

A product should not receive money forever merely because it exists. Persistent funding means the product has continuity across planning cycles.

It should still be reviewed according to:

• Strategic relevance
• Customer value
• Financial contribution
• Adoption
• Reliability
• Risk
• Future opportunity

Products that no longer justify investment may be:

• Reduced
• Consolidated
• Replaced
• Retired

14. Use Portfolio Governance Instead of Project Approval

The executive team should manage technology as an investment portfolio.

The portfolio may include:

• Growth products
• Core operations
• Regulatory requirements
• Cybersecurity
• Infrastructure modernization
• Data platforms
• AI capabilities
• Technical debt reduction

Portfolio governance asks:

• Are investments balanced?
• Which products are producing value?
• Where is risk concentrated?
• Which products should receive more funding?
• Which initiatives should stop?
• Are shared platforms adequately funded?
• Are local investments duplicating enterprise capabilities?

15. Connect Funding With FinOps

Cloud and AI services create variable operating costs.

Teams can increase spending rapidly through:

• Computing
• Storage
• Data transfer
• AI inference
• Model training
• SaaS usage
• Observability
• Security tools

FinOps connects engineering, finance, and business teams to maximize the business value of technology spending and create financial accountability. The current FinOps Framework has expanded beyond public cloud toward wider technology-value management and includes stronger alignment with executive strategy and product prioritization.

Product teams should understand:

• Total product cost
• Cost per customer
• Cost per transaction
• Cost per AI task
• Cost growth
• Cost drivers
• Margin contribution

This allows teams to make informed tradeoffs.

16. Evaluate Total Value, Not Only Cost Reduction

Technology leaders are often instructed to reduce spending. Cost discipline matters.

However, indiscriminate reduction can damage:

• Product delivery
• Security
• Resilience
• Talent retention
• Customer experience
• Long-term architecture

A more useful question is:

Which technology spending produces the greatest value relative to its cost and risk? A product that costs more may still be justified if it creates greater revenue, improves customer retention, or protects critical operations.

17. Fund Technical Health Explicitly

Technical debt, maintenance, security, and resilience are easily neglected when budgets focus only on visible business features.

Product funding should include capacity for:

• Architecture improvement
• Dependency upgrades
• Vulnerability remediation
• Reliability
• Testing
• Observability
• Documentation
• Data quality

The product team owns both change and stability. That is one of the advantages Bain identifies in the product model. Theme Three: Put Talent First

18. Operating Models Are Ultimately Human Systems

An organization can adopt agile terminology, create product teams, and purchase modern tools while retaining the same behaviors and incentives.

The operating model succeeds only when people understand:

• Their responsibilities
• Their decision authority
• The outcomes they own
• How they collaborate
• How performance is evaluated
• How careers progress

Talent cannot be treated as a final implementation detail.

19. Rebalance Thinkers, Doers, and Watchers

Bain describes technology work through three broad groups:

• Thinkers: People shaping strategy, architecture, product direction, and technical design
• Doers: People building, testing, operating, securing, and improving technology
• Watchers: People coordinating, reporting, monitoring, and administering work

Every organization needs some coordination and governance. The problem arises when watchers multiply because the underlying model is fragmented.

For example:

• A project manager coordinates teams that do not share ownership.
• A business analyst translates between groups that rarely work together directly.
• A governance group reviews decisions that could have been covered through automated guardrails.
• Several management layers report status upward.

Bain argues that many organizations have overinvested in watcher roles relative to thinker and doer roles. The goal is not to eliminate project managers or analysts indiscriminately. It is to eliminate coordination work created by poor structure.

20. Bring Strategic Roles In-House

External providers can supply valuable expertise and capacity.

However, the organization should retain internal ownership of capabilities central to:

• Product differentiation
• Enterprise architecture
• Cybersecurity
• Data strategy
• AI governance
• Vendor management
• Customer trust

A company that outsources every important technology decision may become unable to:

• Evaluate provider recommendations
• Control costs
• Change direction
• Protect its architecture
• Develop internal leaders

21. Build Strong Technical Career Paths

Many companies still offer greater status and compensation only through people management. This pushes strong specialists into managerial roles they may not want or perform well.

A modern operating model should provide parallel advancement for:

• Engineers
• Architects
• Security specialists
• Data professionals
• Product experts
• Designers

Technical advancement should be based on:

• Expertise
• Scope
• Business impact
• Influence
• Mentorship
• Judgment

22. Improve Developer Experience

Scarce technical talent is wasted when employees spend excessive time on:

• Waiting for environments
• Manual approvals
• Repetitive configuration
• Weak documentation
• Unstable tools
• Unnecessary meetings

Platform engineering, automation, reusable components, and clear standards can increase productive capacity without adding headcount. The internal technology environment is part of the company’s talent proposition.

23. Redesign Talent for AI

AI changes the balance of technology work. Routine activities may be accelerated or automated.

The relative importance of other capabilities may rise:

• Architecture
• System design
• Product judgment
• Verification
• Security
• Data governance
• AI evaluation
• Agent supervision
• Business understanding

The organization should analyze roles at the task level. A software engineer may spend less time generating routine code and more time reviewing, integrating, testing, securing, and designing systems.

24. Build Human-Agent Teams Deliberately

AI agents can potentially:

• Generate code
• Test software
• Investigate incidents
• Update documentation
• Monitor infrastructure
• Resolve support requests

The operating model must define:

• Which agents are approved
• What they can access
• Which actions they can execute
• Which actions require human approval
• Who is accountable
• How outputs are evaluated
• How activity is logged

NIST’s AI Risk Management Framework is intended to help organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems. NIST has also released a generative AI profile and is continuing to update the framework. AI governance should be integrated into product and platform delivery rather than added only after systems are built.

25. Use External Talent Intentionally

A technology workforce may combine:

• Employees
• Contractors
• Freelancers
• Consulting firms
• Managed-service providers
• AI systems

The sourcing decision should depend on:

• Strategic importance
• Duration
• Scarcity
• Required control
• Knowledge sensitivity
• Operational continuity

Permanent employees generally make sense for enduring strategic ownership. External specialists can accelerate temporary or highly specialized work. Managed services can operate standardized continuing capabilities. Theme Four: Achieve Global Scale With Local Traction

26. The Centralization Versus Decentralization Problem

Technology organizations often move between two extremes. Excessive centralization

A central department controls:

• Platforms
• Architecture
• Security
• Data
• Procurement
• Delivery

This can create consistency and scale. It can also produce slow decisions and solutions disconnected from local users. Excessive decentralization Business units build and purchase independently. This can improve responsiveness.

It can also create:

• Duplicate systems
• Incompatible data
• Security gaps
• Higher costs
• Fragmented customer experiences

Bain argues that cloud platforms, modular architecture, and APIs make it increasingly possible to combine global scale with local relevance. Shared capabilities can be built centrally while allowing local brands, markets, and units to adapt them.

27. Centralize Platforms and Guardrails

Enterprise-level capabilities are often suitable for centralized or federated management.

Examples include:

• Identity
• Cybersecurity standards
• Cloud landing zones
• Core data platforms
• API standards
• Developer platforms
• Shared AI infrastructure
• Observability
• FinOps

These capabilities can provide:

• Economies of scale
• Stronger security
• Reuse
• Interoperability
• Reduced duplication

28. Decentralize Product Decisions Near Customers

Product decisions may need to remain closer to:

• Business units
• Markets
• Customer segments
• Regulatory environments
• Operational teams

Local teams may decide:

• Product priorities
• Customer experience
• Language
• Regional features
• Workflow variations
• Market-specific integrations

The objective is to create a federated model. Shared platforms establish common capabilities and guardrails. Product teams use those platforms to solve local problems.

29. Use APIs and Modular Architecture

Global scale with local flexibility depends on modular systems.

A modular architecture separates capabilities so they can be:

• Reused
• Replaced
• Combined
• Localized
• Exposed through APIs

A central customer-identity service, for example, may support many regional products without forcing those products to use identical customer journeys.

30. Clarify Decision Rights

A federated model fails when responsibilities remain vague.

For every major technology decision, define whether authority belongs to:

• Enterprise leadership
• Platform team
• Product team
• Regional unit
• Risk or security function

Common enterprise decisions may include:

• Identity standards
• Cybersecurity requirements
• Data classification
• Approved cloud providers
• AI governance
• Core architecture principles

Local decisions may include:

• Feature priorities
• Market experiments
• User experience
• Regional processes

31. Design Exceptions, Not Informal Workarounds

Global standards will not fit every situation. Organizations need a formal process for exceptions.

An effective exception process should explain:

• Business justification
• Risk
• Duration
• Compensating controls
• Responsible owner
• Review date

This preserves flexibility without allowing uncontrolled fragmentation. Theme Five: Build Delivery Excellence

32. Delivery Excellence Is More Than Agile Ceremonies

Many organizations say they use agile methods because they hold:

• Daily stand-ups
• Sprint planning
• Retrospectives
• Backlog reviews

These practices can help. They do not automatically create fast or reliable delivery.

Delivery excellence also requires:

• Small batches
• Automated testing
• Continuous integration
• Deployment automation
• Observability
• Secure engineering
• Fast feedback
• Clear ownership
• Effective architecture

Bain connects delivery excellence with agile ways of working, DevOps, automated testing and release, and strong coding and review practices.

33. Measure the Software Delivery System

DORA currently recommends five software-delivery performance metrics:

• Change lead time
• Deployment frequency
• Failed deployment recovery time
• Change fail rate
• Deployment rework rate

DORA states that these metrics provide an effective way to measure software-delivery outcomes and are associated with organizational performance and team well-being. These metrics should be used for improvement, not punishment. Comparing individual developers or teams without context can create manipulation and defensive behavior.

34. Integrate Development and Operations

Traditional organizations separate people who build systems from people who operate them.

This can create:

• Slow handoffs
• Weak accountability
• Repeated incidents
• Conflict over priorities

DevOps combines development and operational responsibility.

Product teams should understand:

• Reliability
• Performance
• Security
• Cost
• Maintainability

The people building the product should remain connected to how it behaves in production.

35. Shift Security Earlier

Security should be integrated throughout delivery.

Practices may include:

• Secure design reviews
• Automated dependency scanning
• Static analysis
• Infrastructure-policy checks
• Secrets management
• Threat modeling
• Continuous monitoring

A late security review often discovers structural issues when they are expensive to correct.

36. Automate the Delivery Path

A strong delivery system reduces manual steps from code change to production.

Automation may cover:

• Build
• Testing
• Security checks
• Deployment
• Rollback
• Infrastructure provisioning
• Compliance evidence

Automation improves:

• Speed
• Consistency
• Auditability
• Recovery
• Quality

37. Improve Observability and Recovery

Every important digital product should provide visibility into:

• Availability
• Errors
• Performance
• User experience
• Dependencies
• Cost

Teams should be able to detect and understand problems quickly. Fast recovery is often more realistic than attempting to prevent every failure.

38. Apply AI Carefully to Software Delivery

AI can assist with:

• Code generation
• Test creation
• Documentation
• Code review
• Incident analysis
• Legacy-system understanding

However, faster code generation can increase risk if the organization does not also strengthen:

• Architecture
• Review
• Testing
• Security
• Observability

More code is not automatically more value.

39. Reduce Work in Progress

Many organizations begin too many initiatives simultaneously.

This creates:

• Context switching
• Delayed completion
• Dependency conflicts
• Weak focus
• Poor quality

Portfolio governance should limit work in progress and concentrate resources on the most valuable outcomes. Theme Six: Elevate Technology

40. From Service Provider to Strategic Partner

In a traditional relationship:

• Business leaders define needs.
• Technology receives requirements.
• IT estimates cost and time.
• The business waits for delivery.

In a stronger model:

• Business and technology leaders define outcomes together.
• Technology influences product and business strategy.
• Tradeoffs are discussed jointly.
• Accountability is shared.

Bain identifies elevation of technology as a defining characteristic of companies receiving stronger returns from technology investment. In those companies, technology leadership evolves from internal service provider to strategic thought partner.

41. Business Leaders Need Technology Literacy

Technology strategy cannot belong exclusively to the CIO.

Business executives should understand enough to participate meaningfully in decisions about:

• Platforms
• Data
• Cybersecurity
• AI
• Architecture
• Technical debt
• Cloud economics

They do not need to become engineers. They need to understand how technology choices affect strategy, speed, cost, and risk.

42. Technology Leaders Need Business Literacy

Technology leaders should understand:

• Customers
• Revenue
• Margin
• Operations
• Regulation
• Competitive strategy
• Capital allocation

A CIO who discusses only systems and uptime will struggle to influence enterprise strategy.

Technology leaders should explain investments in terms of:

• Growth
• Customer value
• Productivity
• Resilience
• Risk
• Strategic flexibility

43. Clarify Executive Accountability

The CIO or CTO cannot be solely accountable for digital value.

A customer product usually requires shared accountability among:

• Business owner
• Product leader
• Technology leader
• Data leader
• Risk or security leadership

The executive team should agree on:

• Who owns the outcome
• Who owns the product
• Who controls funding
• Who accepts risk
• Who evaluates value

44. Put Technology on the Executive Agenda

Technology should be discussed as a regular element of enterprise strategy, not only during:

• Budget approval
• Major outages
• Cyber incidents
• Transformation programs

Executive reviews should examine:

• Product outcomes
• Platform health
• Technology economics
• Cyber risk
• AI portfolio
• Talent
• Architecture
• Technical debt

45. Elevation Requires Transparency

Technology leaders gain credibility when they can explain:

• Where money is spent
• Which products produce value
• Why costs are changing
• Which risks are increasing
• Which capabilities are constrained
• Which investments should stop

Transparency turns technology from a perceived black box into an understandable investment portfolio. Building the Complete Operating Model

46. The Six Themes Reinforce One Another

The six themes should not be treated as separate programs. Product model and outcome funding Persistent teams need persistent budgets and measurable objectives. Talent and delivery excellence Strong engineers cannot perform well inside a slow and fragmented delivery system. Global platforms and local products Central capabilities must help local teams move faster rather than merely enforce standards. Technology elevation and shared accountability Technology cannot become strategic while business leaders remain passive customers. AI and governance AI value depends on products, data, architecture, funding, talent, and risk management working together.

47. Supporting Capability: Architecture

Architecture translates operating-model principles into technical structure.

A good architecture should support:

• Modularity
• Reuse
• Interoperability
• Security
• Scalability
• Local adaptation
• Vendor flexibility

Architecture governance should establish principles and guardrails without reviewing every implementation detail centrally.

48. Supporting Capability: Data Governance

Product teams need access to trusted data.

Data governance should define:

• Ownership
• Quality
• Access
• Privacy
• Retention
• Lineage
• Acceptable AI use

Data should not be centralized only as a technical asset. It should be managed as a product that serves identifiable users and business purposes.

49. Supporting Capability: Risk and Compliance

Governance should move from manual gates toward embedded controls where possible.

Examples include:

• Automated security policies
• Approved infrastructure templates
• Continuous compliance monitoring
• Standard AI assessments
• Reusable legal patterns

This allows teams to move quickly without abandoning control.

50. Supporting Capability: Vendor Strategy

Vendors should be managed according to the capability they provide.

The organization should decide:

• Which products are strategic
• Which services are commodities
• Which vendors create concentration risk
• Which skills must remain internal
• How data can be exported
• How switching would occur

Vendor relationships should support the operating model rather than determine it. Measuring the Technology Operating Model

51. Business-Value Metrics

Possible measures include:

• Revenue influenced
• Conversion improvement
• Customer retention
• Cost reduction
• Employee productivity
• Market-entry speed
• Product adoption

52. Product Metrics

• Active users
• Task completion
• Customer satisfaction
• Feature adoption
• Product reliability
• Cost per user
• Product profitability

53. Delivery Metrics

• Lead time
• Deployment frequency
• Change failure rate
• Recovery time
• Rework
• Work in progress

54. Platform Metrics

• Platform adoption
• Time to provision
• Reuse
• Developer satisfaction
• Reliability
• Unit cost

55. Talent Metrics

• Critical-skill coverage
• Developer experience
• Technical attrition
• Internal mobility
• Learning
• Ratio of builders to coordinators

56. Financial Metrics

• Product cost
• Cost per transaction
• Cloud utilization
• AI cost per task
• Portfolio return
• Duplicate spending removed

57. Risk Metrics

• Critical vulnerabilities
• Incident frequency
• Recovery readiness
• Policy exceptions
• AI-control failures
• Vendor concentration

No single score can represent the health of the operating model. Executives need a balanced view of value, speed, quality, cost, talent, and risk. Implementation Roadmap Phase 1: Diagnose the Current Model

Assess:

• Business-technology relationship
• Funding
• Organization structure
• Decision rights
• Product ownership
• Talent
• Architecture
• Delivery practices
• Metrics
• Vendor dependence

Identify the largest constraints. Do not assume every area must change immediately. Phase 2: Select One or Two Priority Themes Bain recommends beginning with a limited number of themes, creating success, and expanding from there.

Possible starting points include:

• Product model for one customer journey
• Outcome funding for one portfolio
• Platform engineering for developers
• Delivery improvement for one product group
• Executive technology governance

Phase 3: Establish Baseline Measures

Measure current:

• Delivery time
• Product adoption
• Reliability
• Cost
• Team composition
• Employee experience
• Decision delays

Without a baseline, improvement becomes difficult to prove. Phase 4: Redesign Decision Rights

Clarify:

• Product ownership
• Funding authority
• Architecture decisions
• Security responsibility
• Platform responsibility
• Executive escalation

Phase 5: Launch a Model Product Team Choose a meaningful but manageable area.

Give the team:

• Persistent ownership
• Cross-functional capability
• Clear outcomes
• Defined budget
• Access to platforms
• Decision authority

Phase 6: Improve the Delivery System

Introduce:

• Automated testing
• Continuous integration
• Deployment automation
• Observability
• Secure-development practices
• Platform self-service

Phase 7: Redesign Funding and Portfolio Reviews

Move from detailed project approval toward:

• Product budgets
• Outcome targets
• Quarterly allocation reviews
• Stop, scale, or adjust decisions

Phase 8: Adjust Talent and Sourcing

Identify:

• Strategic roles to internalize
• Skills to develop
• Coordination layers to simplify
• External capabilities to retain
• AI-supported work to redesign

Phase 9: Scale Through Platforms Build shared capabilities that allow additional product teams to adopt the model without reproducing infrastructure and governance independently. Phase 10: Institutionalize Continuous Improvement

The operating model should be reviewed as:

• Strategy changes
• Technology changes
• AI capabilities evolve
• Regulations develop
• Product portfolios change

A Practical 12-Month Plan Months 1 to 2: Diagnose

• Map technology spending.
• Identify major products and platforms.
• Review team structures.
• Measure delivery performance.
• Identify decision bottlenecks.
• Assess talent and vendor dependency.

Months 3 to 4: Design

• Select pilot products.
• Define outcomes.
• Establish product ownership.
• Clarify decision rights.
• Design funding and governance.

Months 5 to 7: Pilot

• Create persistent cross-functional teams.
• Introduce platform support.
• Improve engineering automation.
• Begin outcome-based portfolio reviews.
• Measure business and delivery results.

Months 8 to 9: Learn

• Identify structural obstacles.
• Review security and architecture guardrails.
• Gather employee and customer feedback.
• Adjust roles, metrics, and governance.

Months 10 to 12: Scale

• Expand product funding.
• Build internal platforms.
• Simplify coordination layers.
• Develop technical career paths.
• Introduce enterprise portfolio governance.
• Establish quarterly operating-model reviews.

Common Failure Patterns Renaming projects as products The team remains temporary, funding remains annual, and ownership ends after launch. Only the vocabulary changes. Creating product managers without authority The product manager owns a backlog but cannot control funding, staffing, architecture, or priorities. Funding outcomes without reliable measures Teams need credible indicators of customer, business, operational, and financial value. Centralizing every decision Enterprise standards become bottlenecks. Decentralizing without guardrails Local speed creates duplication, risk, and incompatible platforms.

Using agile ceremonies without engineering improvement Sprints cannot compensate for manual deployment, unstable environments, weak testing, and poor architecture. Treating AI as a separate innovation program AI needs product ownership, data, funding, governance, engineering, and operational accountability. Cutting coordination roles without simplifying the work Removing people while retaining fragmented responsibilities creates confusion. Outsourcing strategic judgment The company becomes dependent on vendors for architecture, security, product direction, or AI expertise. Measuring cost without value Leaders optimize the technology budget while damaging customer outcomes, resilience, and long-term adaptability.

Key Takeaways

1. Technology investment cannot produce its full value inside an outdated operating model.

2. The technology operating model connects strategy, funding, teams, talent, architecture, governance, and performance.

3. Bain identifies six core themes: product model, outcome funding, talent, global scale with local traction, delivery excellence, and technology elevation.

4. Persistent product teams create stronger accountability than temporary project structures for continuing digital capabilities.

5. Product teams should own delivery, adoption, reliability, security, cost, and improvement.

6. Funding should increasingly follow products and outcomes rather than detailed annual project scopes.

7. Technology spending should be managed as an investment portfolio.

8. Cloud and AI costs require collaboration among engineering, finance, and business leadership.

9. Talent strategy should increase the proportion of people designing and building value while reducing unnecessary coordination overhead.

10. Strategic technology, architecture, security, data, and AI responsibilities require strong internal ownership.

11. Shared platforms should be managed as internal products.

12. A federated model can combine enterprise scale and guardrails with local product autonomy.

13. Delivery excellence requires engineering automation, DevOps, security integration, observability, and fast feedback.

14. Agile ceremonies alone do not create high-performing delivery.

15. Technology leaders must become enterprise strategists, and business leaders need stronger technology literacy.

16. AI should be integrated into the operating model rather than managed as an isolated experimental program.

17. Human-agent work requires explicit decision rights, controls, and accountability.

18. The transformation should begin with one or two high-priority themes and scale through demonstrated results.

Frequently Asked Questions

What is a technology operating model?

It is the system through which an organization makes technology decisions, allocates funding, organizes teams, governs platforms, manages talent, delivers products, and measures value.

How is a technology operating model different from a technology strategy?

Technology strategy defines what the organization intends to accomplish. The operating model defines how people, funding, processes, platforms, and decision rights will execute that strategy.

What are Bain’s six themes?

The six themes are:

1. Adopt the product model

2. Invest for outcomes

3. Put talent first

4. Combine global scale with local traction

5. Build delivery excellence

6. Elevate technology

What is a product operating model?

It organizes persistent cross-functional teams around products, platforms, services, or measurable business outcomes.

How is a product different from a project?

A project is temporary and ends after a defined deliverable. A product continues to evolve and requires ongoing ownership, funding, maintenance, security, and improvement.

Does every technology activity need a product team?

No. Temporary migrations, compliance initiatives, and one-time implementations may still use project structures. Continuing digital capabilities usually benefit from product ownership.

What is outcome-based funding?

It provides a persistent budget for a product or outcome while allowing the team to adapt its roadmap based on evidence and changing priorities.

Does persistent funding eliminate financial control?

No. Products should still undergo regular reviews, and funding should move when value is weak or priorities change.

What does talent first mean?

It means designing the operating model around the skills, career paths, ownership, tools, and working conditions required for people to perform effectively.

What are thinkers, doers, and watchers?

They are broad categories used to describe people who shape decisions, build or operate technology, and coordinate or monitor work. The organization should avoid excessive coordination roles created by fragmented structures.

What does global scale with local traction mean?

It means using shared platforms, standards, and capabilities across the enterprise while allowing local product teams to adapt to market, customer, and regulatory needs.

What is a federated technology model?

It combines centralized enterprise capabilities and guardrails with decentralized product or business-unit decision-making.

What is delivery excellence?

It is the capability to deliver valuable technology rapidly, reliably, securely, and repeatedly.

What are the DORA metrics?

DORA currently identifies five software-delivery metrics:

• Change lead time
• Deployment frequency
• Failed deployment recovery time
• Change fail rate
• Deployment rework rate

What is platform engineering?

Platform engineering creates reusable self-service capabilities that help product and development teams build, deploy, and operate software more efficiently.

What is FinOps?

FinOps is an operating and cultural framework that connects engineering, finance, and business teams to maximize the value of technology spending.

How does AI affect the operating model?

AI changes product design, software delivery, workforce tasks, cost structures, governance, risk, and the division of responsibility between humans and agents.

Should AI have a separate operating model?

AI may require specialized governance and expertise, but it should ultimately integrate with product, platform, data, security, financial, and talent systems.

What should remain centralized?

Common centralized or federated capabilities include:

• Identity
• Security standards
• Cloud foundations
• Data governance
• Developer platforms
• AI governance
• Financial management

The exact model depends on the organization.

What should remain decentralized?

Product priorities, user experience, market experiments, and local workflow decisions often belong closer to the relevant customers and business units.

How should technology value be measured?

Measures may include:

• Revenue
• Customer outcomes
• Productivity
• Adoption
• Reliability
• Cost
• Delivery speed
• Risk reduction
• Strategic flexibility

Who owns technology outcomes?

Ownership is often shared among business, product, technology, data, finance, and risk leaders. The decision rights should be explicit.

How should a company begin upgrading its model?

It should diagnose the current system, identify its largest constraints, select one or two priority themes, create a focused pilot, establish baseline measures, and scale what works.

Conclusion

Companies do not suffer from a shortage of technology initiatives. They suffer from a shortage of coherent systems for turning those initiatives into value. They purchase cloud platforms, launch AI pilots, create transformation programs, hire engineers, and introduce agile practices.

Yet they often preserve a structure built around:

• Temporary projects
• Departmental budgets
• Functional silos
• Manual approvals
• Fragmented accountability
• Technology treated as a cost center

The technology operating model determines whether investment becomes value or complexity. A stronger model organizes continuing digital capabilities as products. It funds teams according to outcomes. It places more decision-making and accountability close to the work. It combines shared enterprise platforms with local flexibility. It invests in engineering quality, automation, security, and observability. It develops technical talent and removes unnecessary coordination. It gives technology leaders an active role in business strategy while requiring business leaders to engage seriously with technology choices. The six themes are not a collection of independent best practices. They are parts of one system. Product teams cannot succeed without appropriate funding. Funding cannot be allocated intelligently without measurable outcomes.

Delivery excellence cannot emerge without capable talent and strong platforms. Global scale cannot coexist with local traction without modular architecture and clear decision rights. Technology cannot become strategic while executives treat it as an internal supplier. Artificial intelligence increases the urgency of every theme. AI allows organizations to move faster, but it can also increase cost, risk, fragmentation, and technical output without corresponding value. The companies that benefit most will not simply deploy more AI. They will integrate AI into disciplined products, governed platforms, accountable teams, transparent portfolios, and effective human decision-making.

The defining question is no longer:

How can the technology department deliver more projects for less money?

It is:

How should the entire enterprise organize its products, platforms, funding, talent, technology, and decisions so that every meaningful investment produces faster learning, stronger performance, and measurable value?

Relevant Articles and Resources

1. Upgrading Your Technology Operating Model: Six Themes for Success

Bain & Company

https://www.bain.com/insights/upgrading-your-technology-operating-model-six-themes-for-success/

The original framework describing product models, outcome funding, technology talent, global and local balance, delivery excellence, and elevation of technology.

2. DORA Software Delivery Performance Metrics

DORA

https://dora.dev/guides/dora-metrics/

Official guidance on the five current software-delivery performance metrics and their use in improving delivery systems.

3. DORA Research

DORA

https://dora.dev/research/

Long-running research into technical and organizational capabilities associated with software-delivery and operational performance.

4. FinOps Framework

FinOps Foundation

https://www.finops.org/framework/

The official framework for maximizing the business value of technology spending through collaboration among engineering, finance, and business teams.

5. FinOps Framework 2026 Updates

FinOps Foundation

https://www.finops.org/insights/2026-finops-framework/

Current updates expanding FinOps toward executive strategy alignment, product prioritization, and wider technology-value management.

6. Microsoft Cloud Adoption Framework

Microsoft

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/

Guidance connecting business strategy, planning, governance, security, cloud adoption, and technology operations.

7. Shared Management Cloud Operations

Microsoft

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/shared-management-operating-model

Guidance on shared operating models, platform engineering, reusable capabilities, and self-service support for workload teams.

8. Prepare Your Organization for Cloud Adoption

Microsoft

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/prepare-organization-for-cloud

A comparison of centralized, shared, and decentralized responsibility models for cloud governance, security, platforms, and operations.

9. AI Risk Management Framework

National Institute of Standards and Technology

https://www.nist.gov/itl/ai-risk-management-framework

The US government’s voluntary framework for managing trustworthiness and risk throughout the design, development, deployment, and evaluation of AI systems.

10. NIST AI RMF Resources and Generative AI Profile

National Institute of Standards and Technology

https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-resources

Official supporting resources, including the Generative Artificial Intelligence Profile and implementation materials.

11. Develop a Cloud Adoption Strategy

Microsoft

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/

Current guidance on connecting executive intent, measurable business outcomes, guardrails, and technology investment decisions.