A product operating model, commonly shortened to POM, defines how an organization designs, develops, delivers, operates, improves, funds, and governs products throughout their life cycles.
Thoughtworks describes it as the blueprint explaining:
How work is performed How people and resources are allocated How decisions are made How information flows How strategy becomes execution How customer, user, and business value is delivered It is intended to replace the fragmented model in which “the business” defines requirements and hands them to separate technology or delivery teams. A modern product operating model incorporates product management, technology, software development, process changes, pricing, policy, operations, and go-to-market considerations inside one connected system.
The shift is fundamentally from:
Projects to products Outputs to outcomes Temporary teams to persistent teams Requirements delivery to problem solving Annual planning to continuous prioritization Cost-center thinking to value creation Functional handoffs to cross-functional ownership Technology separation to integrated business and technology capability Milestone reporting to evidence and learning Thoughtworks groups the content of a product operating model into three broad areas.
1. How people should behave
This includes:
Product principles Cultural expectations Decision behaviors Performance measures Customer orientation Accountability
2. How work is planned, executed, monitored, and governed
This includes:
Strategy deployment Portfolio management Product life cycles Discovery and delivery Funding Tooling Governance Objectives and key results
3. How the organization is structured
This includes:
Product boundaries Team structures Roles Responsibilities Decision rights Interaction models Leadership Shared services and platforms Thoughtworks emphasizes that a POM should align organizational structure, team design, technical architecture, and objectives because greater alignment reduces friction and accelerates value delivery. It also warns against excessive prescription: standardization can support speed and cohesion, but too much governance can suppress innovation.
A mature product operating model normally contains twelve connected components:
Product vision and principles Customer and value-stream orientation Product portfolio structure Persistent cross-functional teams Strategy deployment and outcome setting Continuous discovery and delivery Product funding and investment governance Technology and platform architecture Shared services and enabling functions Product metrics and performance management Talent, leadership, and career systems Continuous improvement of the operating model itself
Thoughtworks advises organizations not to “install” a generic POM. The model should evolve incrementally, begin with the organization’s most consequential operating problem, and reflect differences among internal products, customer-facing products, major innovations, regulated environments, and initiatives dependent on external parties. A broader Thoughtworks product-transformation guide explains that great product organizations are customer-centered, value-driven, and capable of adapting continuously. Product thinking should influence strategy, organizational structure, funding cycles, decisions, communication, practices, and culture - not only the work of product managers. Deloitte’s current product-operating-model framework reinforces the need to connect value streams, fit-for-purpose governance, objectives and key results, shared services, delivery measures, transformation leadership, integrated tools, and AI-enabled engineering. It argues that scaling product orientation requires a unified system for defining, funding, measuring, and delivering value - not merely reorganizing teams.
The central lesson is:
A product operating model is successful only when strategy, money, teams, technology, authority, and measurement all point toward the same customer and business outcomes.
1. Why Organizations Move From Projects to Products
Projects are useful for work with:
A defined beginning A defined end A stable scope A predetermined output A temporary delivery structure
Examples may include:
Constructing a building Moving an office Completing a regulatory filing Implementing a finite infrastructure change Digital products are different.
They continue evolving because:
Customer expectations change Competitors respond technology advances regulations change security threats emerge usage reveals new needs operating conditions shift A mobile banking application is never permanently complete.
Neither is:
An e-commerce platform A customer portal An internal data platform A logistics system A digital insurance product An AI-enabled employee service
Treating these as temporary projects creates a predictable cycle:
Funding is approved. A temporary team is formed. Requirements are delivered. The project is declared complete. The team disperses. Operational responsibility moves elsewhere. Customer learning arrives after the delivery structure has disappeared. A new project is created to change the product again. The project may end. The customer need does not.
2. Project Success Is Often Disconnected From Product Success
A project can succeed against its internal measures while the product fails.
It may be:
On time Within budget Complete against scope
Yet customers may:
Avoid it abandon it require support continue using old channels receive little additional value This happens because project measures focus on delivery promises. Product measures focus on real-world outcomes.
A product operating model asks:
Did customer behavior improve? Did revenue increase? Did cost decline? Did risk decrease? Did adoption grow? Did the organization learn something useful?
3. Product Mode Does Not Mean Projects Disappear
Some work remains genuinely project shaped. Thoughtworks explicitly notes that many organizations use hybrid arrangements. A product-oriented enterprise may still run projects for finite initiatives, major transformations, infrastructure events, or work involving extensive external dependencies. However, organizations using software to provide ongoing products, services, and experiences should generally default to product mode. The aim is not ideological purity. It is selecting the operating model that fits the nature of the work.
4. What a Product Operating Model Actually Does
A POM translates abstract product ambition into operational rules.
It explains:
Which products exist Who owns them Which customers they serve Which outcomes they pursue How teams are formed How investment is allocated How priorities change How technology is governed How success is measured How poor-performing products are changed or retired Without these decisions, “becoming product-led” remains a slogan.
5. The POM Is Not the Business Strategy
Thoughtworks warns against making the POM repeat information already contained in business strategy, product strategy, enterprise policy, or the broader organizational operating model.
The distinction is:
Business strategy Defines where and how the organization intends to compete. Product strategy Defines how particular products or portfolios create value. Product operating model Defines how people, money, technology, processes, authority, and information work together to execute those strategies. The POM should connect strategy to execution without duplicating the strategy itself.
6. Product Thinking Must Extend Beyond Product Management
A company does not become product oriented by hiring product managers.
Product thinking must influence:
Executives Finance Technology Operations Risk Marketing Sales Human resources Procurement Thoughtworks’ broader product guide describes product mindset as an enterprise-wide focus on continuously exploring and solving customer problems while creating business value. It should shape strategy deployment, structures, teams, funding, communication, decisions, practices, and culture. A product team cannot operate effectively when every surrounding function still behaves through project-based control. Part I: Define the Product Philosophy
7. Create a Product Manifesto
The POM should begin with a small set of principles.
Examples include:
Start with customer and business problems. Measure outcomes rather than output volume. Treat technology as part of the product. Fund persistent capabilities, not only temporary scope. Give teams problems and boundaries, not predetermined solutions. Prefer small experiments and reversible decisions. Make product decisions using evidence. Build quality, security, and operability into the product. Retire products and features that no longer justify investment. Thoughtworks recommends using a product manifesto and product principles as design tenets for the operating model. These principles should influence actual decisions. A manifesto that contradicts funding, governance, and incentives becomes decoration.
8. Clarify the Meaning of Product
Organizations often label every application, initiative, and department a product. This creates confusion.
A useful product normally has:
A defined customer or user A problem or need A value proposition A life cycle An accountable owner Measurable outcomes A persistent capability for improvement Products may be external or internal.
Examples include:
Customer-facing product A digital mortgage service. Internal product An employee identity platform. Platform product A developer platform serving engineering teams. Data product A governed customer-risk data service. Not every software asset should become an independent product.
9. Define Product Boundaries Carefully
Poor product boundaries create:
Too many dependencies weak ownership duplicated capability customer fragmentation architecture misalignment A good boundary should contain enough scope for a team to create measurable value with reasonable autonomy.
Boundary decisions may consider:
Customer journey Business capability Value stream Data ownership Technology architecture Regulatory accountability Deloitte emphasizes that defining value streams around customer journeys forces organizational and architectural alignment, helping teams move away from fragmented systems toward end-to-end ownership and reusable platforms.
10. Products Are Not Systems
One product may rely on multiple systems. One system may support multiple products. Confusing the two can produce technology-centered teams without clear customer outcomes. The product boundary should be based primarily on value. Technology architecture should support that boundary. Part II: Organize Around Customers and Value Streams
11. Define the Customer
Every product team should know:
Who uses the product who buys or funds it who benefits who may be harmed which needs matter most Internal products also have customers. A developer platform serves developers. A finance data product may serve analysts, controllers, and executives. Calling something “internal” does not remove the obligation to understand users.
12. Map the Value Stream
A value stream describes the sequence through which a need becomes value.
Examples include:
Applying for insurance receiving a medical appointment opening a bank account releasing software onboarding an employee
Value-stream mapping helps reveal:
Handoffs queues delays rework ownership gaps duplicated systems Deloitte identifies value-stream definition as a foundational step because it aligns teams and architecture with end-to-end customer journeys.
13. Organize Teams Around Meaningful Outcomes
Functional organizations often divide work into:
Business analysis Design Development Testing Operations The customer experiences one result. The organization experiences many handoffs.
Product teams should contain enough cross-functional capability to:
Understand the customer design solutions build release operate learn Research on software team structures has found recurring movement from siloed arrangements toward cross-functional product teams supported by horizontal platform or enabling teams.
14. Persistent Teams Preserve Knowledge
Temporary project teams repeatedly lose:
Customer understanding Technical context operational experience team trust decision history Persistent teams improve continuously because they remain responsible after launch.
They experience:
Customer feedback operational consequences maintenance technical debt long-term performance This creates stronger incentives for sustainable decisions. Part III: Deploy Strategy Through Outcomes
15. Connect Enterprise Strategy to Product Decisions
A product operating model should create a visible chain from:
Enterprise ambition Portfolio priorities Product outcomes Team objectives Experiments and delivery Thoughtworks recommends a strategy-deployment framework that converts product and business strategy into aligned goals, including the use of objectives and key results where suitable. Deloitte similarly argues that cascading objectives can create a line of sight from enterprise strategy through product areas to team-level outcomes.
16. Use Outcomes, Not Activity Targets
Weak objectives include:
Launch the new portal. Deliver 50 features. Complete the migration. Implement AI.
Stronger objectives include:
Increase successful digital onboarding. Reduce abandonment. Reduce service cost. Improve developer deployment speed. Reduce fraud without increasing false positives. An output may support an outcome. It is not the outcome itself.
17. Avoid Mechanical OKR Cascades
Objectives and key results can create alignment. They can also create bureaucracy when every objective is mechanically decomposed into dozens of team metrics.
Good objectives should:
Clarify direction define measurable change preserve team problem-solving space encourage collaboration Teams should not become delivery units optimizing isolated numbers at the expense of the overall product.
18. Give Teams Problems, Not Feature Lists
An empowered team receives:
A customer problem A business outcome Constraints Resources Decision authority It is then expected to discover the most effective solution. A delivery team receives a list of predetermined features. Renaming the second group a product team does not empower it. Part IV: Build the Product Portfolio
19. Treat Products as an Investment Portfolio
The organization cannot fund every product equally.
Portfolio management should decide where to:
Invest maintain experiment reduce retire Thoughtworks recommends classifying products across their life cycles and using horizons such as sustain, explore, and exploit.
A balanced portfolio may include:
Explore Testing uncertain opportunities. Exploit or grow Scaling products with evidence of value. Sustain Maintaining essential mature products. Retire Removing products whose value no longer justifies cost and complexity.
20. Apply Different Governance to Different Horizons
An exploratory product should not require the same planning certainty as a mature regulated platform.
Explore work may need:
Small funding rapid experiments flexible scope learning metrics
Mature products may need:
reliability cost efficiency compliance predictable capacity The POM should allow contextual variation. Thoughtworks notes that internal products, market-facing products, major innovations, and initiatives with heavy external dependencies may require different versions of the model.
21. Make Product Retirement a Normal Decision
Organizations are usually better at creating products than removing them.
Every product should be reviewed for:
Customer value strategic relevance operating cost risk duplication technical health
Retirement frees:
Talent funding infrastructure cognitive capacity A product portfolio that only grows eventually becomes unmanageable. Part V: Change the Funding Model
22. Why Project Funding Undermines Product Teams
Project funding normally requires:
Fixed scope estimated cost target completion date temporary resources Product work contains uncertainty.
The team learns what to build through:
Research experiments customer behavior market response Requiring complete scope before learning begins creates false certainty.
23. Fund Teams and Product Capacity
A product funding model may allocate investment to:
A product A value stream A persistent team A portfolio outcome The organization then adjusts priorities within that capacity as evidence changes. This does not mean unlimited funding. It means separating the investment decision from a rigid feature contract.
24. Use Rolling Investment Reviews
Funding should be reviewed periodically based on:
Strategic fit customer evidence product performance financial return risk learning opportunity cost Thoughtworks includes funding approach, frequency, and additional-investment processes as explicit components of the POM.
25. Finance Must Become a Product-Model Partner
Finance should help teams understand:
Product economics total cost return investment options uncertainty The aim is not to remove financial discipline. It is to replace false precision with evidence-based investment management.
26. Capacity Allocation Is a Strategic Decision
A product team’s capacity may be divided among:
New customer value Reliability Technical debt Security Regulatory work Discovery If every planning cycle allocates all capacity to visible features, product health deteriorates. The operating model should protect investment in sustainability. Part VI: Create Persistent Cross-Functional Teams
27. Core Product-Team Capabilities
A product team usually needs access to:
Product management Design and research Engineering Data or analytics Operations Domain expertise Not every capability must be permanently embedded. The team must have reliable access without repeated organizational negotiation.
28. Product Management
Product managers should be accountable for:
Product direction Customer problems Outcomes Prioritization Evidence Investment recommendations They should not function merely as backlog administrators.
29. Design and Research
Designers and researchers help teams understand:
Needs behavior accessibility journeys usability service context Continuous customer learning is central to product mode.
30. Engineering
Engineers contribute beyond implementation.
They help shape:
Feasibility architecture experiments technology strategy product possibilities Separating discovery from engineering can produce unrealistic ideas and late technical surprises.
31. Data and Analytics
Product teams need reliable evidence.
Data specialists may support:
Behavioral measures experiments forecasting decision quality product economics Metrics should be designed as part of the product, not added after launch.
32. Domain and Operational Expertise
Complex products require understanding of:
Regulation operations customer service policy physical workflows Cross-functional teams need collective domain knowledge. Research into product requirements suggests that fragmented specialization can prevent teams from developing the shared understanding needed for genuine product ownership.
33. Shared Accountability
A cross-functional team is not a collection of specialists completing separate tickets. It shares responsibility for the outcome.
That requires:
Common objectives joint discovery transparent decisions collective learning Part VII: Establish Decision Rights and Governance
34. Autonomy Requires Boundaries
Teams cannot be empowered when every meaningful decision requires executive approval. They also cannot operate without enterprise constraints.
The POM should define which decisions belong to:
The enterprise Portfolio leadership Product leadership Individual teams Platforms and enabling functions
35. Enterprise Decisions
These may include:
Strategic priorities Capital allocation Major risk appetite Regulatory policy Common architecture standards Security requirements
36. Product Decisions
These may include:
Product direction Roadmap discovery priorities customer segments feature choices capacity allocation
37. Team Decisions
These may include:
Experiment design implementation approach local technical choices delivery practices Clear decision rights reduce escalation and conflict.
38. Governance Should Enable, Not Merely Control
Traditional governance often asks:
Was the plan followed? Was the scope delivered? Was the budget consumed as forecast?
Product governance should ask:
Are outcomes improving? What evidence has been learned? Should investment change? Is the product healthy? Are risks controlled? Should the product continue?
39. Standardize the Minimum Necessary
Thoughtworks warns that excessive governance and prescription can suppress innovation even though shared standards can improve speed, understanding, and cohesion.
Standardize areas such as:
Security financial controls data protection basic product metrics architecture principles
Allow variation in:
Discovery methods team practices experimentation local workflows Part VIII: Integrate Technology Into the Product Model
40. Do Not Maintain a Separate IT Operating Model
Thoughtworks argues that a separate technology operating model often reflects project thinking in which business groups provide requirements to technical delivery groups.
Modern products combine:
Business models software data operations service policy Technology must therefore sit inside product ownership.
41. Align Product and Technical Architecture
Misaligned architecture creates dependency-heavy teams. A product team may own an outcome but depend on five other groups for every meaningful change.
Technical architecture should support:
Clear ownership deployability data responsibility team autonomy manageable dependencies
42. Platform Teams as Internal Product Teams
Platforms provide reusable capabilities such as:
Cloud infrastructure Identity Payments Data Developer tooling Security controls
They should operate as products with:
Internal customers Product managers User research Service measures Adoption goals Deloitte emphasizes integrating shared services and platform enablers so product teams can deliver value without repeatedly rebuilding common capabilities.
43. Shared Services Must Be Responsive
Centralized functions can become bottlenecks.
The POM should define how teams interact with:
Security Legal Procurement Architecture Data Infrastructure
Possible models include:
Self-service platforms Embedded specialists Consultation service-level commitments enabling teams
44. AI Changes the Product Operating Model
AI affects product work through:
Faster prototyping Automated research support AI-assisted engineering Agentic workflows New product possibilities
It also increases the need for:
Data governance model oversight human accountability experimentation discipline product-risk management Deloitte describes AI-enabled engineering as an economic rearchitecture requiring changes to teams, platforms, funding, and the software-development life cycle - not merely a tooling upgrade. Part IX: Continuous Discovery and Delivery
45. Discovery and Delivery Must Operate Together
Discovery asks:
Which problem should we solve? For whom? Which solution might work? What evidence do we need?
Delivery asks:
How will we build, release, operate, and improve it?
Separating them creates:
Unvalidated requirements delayed feedback rework technical infeasibility Product teams should continuously balance both.
46. Use Small Experiments
Before making a large commitment, teams can test:
Demand usability technical feasibility commercial viability operational risk
Experiments may include:
Prototypes concierge services limited releases simulations A/B tests The aim is to purchase information cheaply.
47. Use Thin Slices
A thin slice delivers a small but complete portion of value. It is better than building isolated layers for months.
Thin slices support:
Earlier feedback lower risk faster learning easier correction Thoughtworks’ product-maturity model includes rolling planning, thin slices, live experiments, frequent releases, and continuous prioritization among its product practices.
48. Maintain Continuous Customer Contact
Product teams should use:
Interviews Observation Analytics Support data Experiments Usability testing Customer learning is not a one-time research phase. It should continue throughout the product life cycle. Part X: Measurement and Performance Management
49. Measure the Product at Several Levels
A balanced product scorecard may include:
Customer outcomes Adoption retention satisfaction task success time saved Business outcomes Revenue cost risk market share margin
Product health Reliability usability quality accessibility security Delivery health Lead time release frequency failure rates recovery team flow
Learning Experiments hypotheses validated decision speed evidence quality
50. Avoid Vanity Metrics
Weak metrics include:
Number of features Number of releases Story points Utilization Backlog size These may describe activity without demonstrating value.
51. Connect Product Metrics to Investment Decisions
Metrics should help leaders decide:
Increase investment continue change direction merge retire Deloitte emphasizes standardized delivery and product metrics to improve capital allocation, forecasting, transparency, and course correction.
52. Do Not Use Team Metrics Punitively
When metrics become individual or team-ranking tools, people learn to game them.
Measures should support:
Learning improvement investment diagnosis They should not become simplistic productivity scores. Part XI: Talent and Leadership
53. Product Leaders Need Commercial and Technical Fluency
Effective product leaders should understand:
Customers Business economics Technology Data Operations Risk They do not need to be the deepest expert in every area. They need enough fluency to integrate them.
54. Executives Must Change Their Behavior
Leadership in project mode often involves:
Approving scope reviewing status resolving escalations demanding certainty
Product leadership involves:
Setting outcomes allocating investment creating constraints reviewing evidence stopping weak bets protecting team autonomy Executives cannot demand empowerment while continuing to make every product decision.
55. Middle Managers Need New Roles
Functional managers may fear losing authority when people move into cross-functional teams.
Their future responsibilities may include:
Developing professional capability coaching managing communities of practice workforce planning standards talent mobility The operating model should define these roles explicitly.
56. Career Paths Must Support Product Work
Organizations need advancement paths for:
Product managers Designers Engineers Researchers Data specialists Platform leaders Career progression should not require abandoning expertise for general management.
57. Incentives Must Support Enterprise Outcomes
Teams will behave according to:
Budgets Targets Promotions recognition A sales function rewarded only for volume may conflict with a product team optimizing customer lifetime value. The operating model should identify and resolve incentive conflicts. Part XII: Tools and Information Flow
58. Create a Shared System of Record
A coherent toolchain should connect:
Strategy Objectives Portfolios Roadmaps Dependencies Product metrics Delivery information Deloitte argues that fragmented tools create siloed data and operational inconsistency, while an integrated system helps connect priorities, capacity, roadmaps, and outcomes.
59. Do Not Let Tools Define the Model
A portfolio platform, ticketing system, or OKR application cannot create product thinking.
The operating model should define:
Decisions workflows accountability Tools should support them.
60. Information Should Flow Both Ways
Strategy should move from leadership toward teams. Evidence should move from teams toward leadership.
The POM should support rapid communication of:
Customer learning Product performance Delivery risks Investment needs strategic changes Without upward evidence flow, leadership continues governing through assumptions. Part XIII: Designing the Transformation
61. Start With the Biggest Operating Pain
Thoughtworks advises organizations to begin with their most consequential operating problem rather than attempting to implement an entire generic framework at once. For a company with a strategy-execution gap, the first step might be a strategy-deployment mechanism such as OKRs.
Other starting points may include:
Unclear product ownership Excessive dependencies Project-based funding Weak customer discovery Poor portfolio decisions Technology bottlenecks
62. Diagnose Before Reorganizing
Structural changes are visible and politically attractive. They are also difficult to reverse. Thoughtworks notes that operating-model changes involving structures, roles, and responsibilities may take years to produce their full performance effects.
Before changing reporting lines, identify:
Which decisions are slow Where work waits Which incentives conflict Which dependencies dominate Which products lack ownership
63. Use Pilots Carefully
A pilot can test:
Persistent team structure Product funding Outcome metrics Discovery Platform support
Choose a meaningful product with:
Executive support measurable outcomes manageable dependencies real customers Avoid selecting a trivial pilot that cannot demonstrate enterprise relevance.
64. Change the Surrounding System
A product-team pilot may appear successful because executives temporarily remove barriers. The challenge is making those conditions normal.
Scale requires changes to:
Finance Governance Talent Architecture Procurement Risk Leadership
65. Publish the POM
A shared POM creates:
Common language Transparency Faster onboarding Consistent expectations
It should be:
Short enough to use Detailed enough to guide Accessible Versioned Updated Thoughtworks recommends making the POM defined, published, and shared across the organization.
66. Treat the POM as a Product
The operating model itself should have:
Owners Users Feedback Measures Iterations Thoughtworks emphasizes that operating models should evolve through experience, changing strategic needs, and the business environment rather than being installed once. Common Failure Patterns
67. Renaming Projects as Products
The team still receives fixed scope, temporary funding, and deadline-based success measures.
68. Creating Product Owners Without Authority
The product owner manages tickets but cannot control strategy, funding, or priorities.
69. Keeping Business and Technology Separate
Business teams define solutions and technology teams execute them.
70. Organizing Around Systems Rather Than Value
Teams own applications but cannot deliver complete customer outcomes.
71. Funding Products Like Projects
Every material change requires a new business case and temporary approval.
72. Measuring Output
Success is defined through features, story points, milestones, or utilization.
73. Excessive Governance
Teams wait for multiple approvals and lose the ability to experiment.
74. Unlimited Autonomy
Teams create inconsistent architectures, tools, and customer experiences.
75. Ignoring Platforms
Product teams repeatedly build common infrastructure.
76. Treating Shared Services as Ticket Queues
Security, data, legal, and infrastructure become slow dependencies.
77. Copying Another Company’s Model
The organization adopts structures that do not fit its products, risks, or culture.
78. Reorganizing Before Clarifying Products
Reporting lines change without solving ownership or strategy problems.
79. Using OKRs as a Performance Cascade
Teams receive more targets but not more authority.
80. Never Retiring Products
The portfolio accumulates cost, complexity, and fragmented customer experiences. A Practical Product Operating Model Framework Step 1: Define the purpose State why product mode is required and which strategic problems it must solve. Step 2: Establish principles Create the product manifesto and behavioral expectations. Step 3: Define products and value streams Identify customers, outcomes, ownership, and product boundaries. Step 4: Design the portfolio Classify products across exploration, growth, sustainment, and retirement. Step 5: Create persistent teams Align cross-functional teams with products and value streams.
Step 6: Define decision rights Clarify enterprise, portfolio, product, platform, and team authority. Step 7: Redesign funding Move toward persistent team and product investment with rolling reviews. Step 8: Integrate discovery and delivery Create continuous customer learning, experimentation, delivery, and operations. Step 9: Align architecture and platforms Reduce dependencies and provide reusable self-service capabilities. Step 10: Establish governance and metrics Measure outcomes, health, learning, delivery, risk, and investment performance. Step 11: Update talent systems Redesign roles, leadership expectations, career paths, incentives, and learning.
Step 12: Evolve the POM Use evidence to improve the operating model continuously. A 90-Day Starting Plan Days 1 - 30: Diagnose Identify the largest strategy-to-execution barriers. Map current products, projects, teams, and funding. Interview customers, teams, finance, technology, and risk leaders. Identify unclear ownership and major dependencies. Define transformation outcomes. Days 31 - 60: Design Draft product principles. Select a value stream or portfolio.
Define product boundaries. Design the persistent team. Establish decision rights. Define initial outcome measures. Days 61 - 90: Pilot Launch one meaningful product-model pilot. Provide persistent funding. integrate discovery and delivery. reduce approval barriers. establish customer and business measures. document operating-model lessons. A 12-Month Roadmap
Quarter One: Foundation Define product philosophy. map portfolios and value streams. identify target products. establish transformation governance. Quarter Two: Pilot Create persistent cross-functional teams. introduce outcome-based objectives. change selected funding mechanisms. establish discovery practices. Quarter Three: Enable Build platform and shared-service support.
update architecture. improve portfolio measures. redesign leadership and talent roles. Quarter Four: Scale Expand successful product patterns. retire conflicting project controls. integrate finance and strategic planning. publish the POM. establish continuous maturity reviews. Product Operating Model Maturity Levels Level One: Project Delivery Temporary teams
Fixed scope Output measures Business-technology separation Level Two: Product-Labeled Delivery Product titles and agile practices Limited decision authority Project funding continues Feature roadmaps dominate Level Three: Emerging Product Mode Persistent teams Clearer outcomes Continuous discovery begins
Some product funding Dependencies remain high Level Four: Scaled Product Organization Portfolio investment Cross-functional ownership Integrated platforms Outcome governance Strong customer learning Level Five: Adaptive Product Enterprise Strategy, money, teams, architecture, and metrics aligned Rapid portfolio reallocation Continuous discovery and delivery
Products retired based on evidence Operating model evolves continuously Thoughtworks’ product-maturity framework recommends assessing teams across user-centered behavior, value orientation, rapid response, continuous growth, communication and collaboration, and steering and governance. It treats maturity as an iterative team reflection rather than a one-time certification.
Key Takeaways
A product operating model is the system through which strategy becomes continuous customer and business value. It defines how work, people, funding, technology, decisions, information, and governance operate together. Project mode optimizes temporary delivery; product mode optimizes continuous outcomes and learning. Renaming project teams does not create a product organization. Product thinking must extend across business, technology, finance, operations, risk, and talent. The POM should define behaviors, operating processes, governance, structures, roles, and decision rights. Products should have clear customers, value propositions, ownership, outcomes, and life cycles. Teams should be persistent and aligned with products or value streams. Product and technology ownership should be integrated. Strategy should cascade into outcomes while evidence flows upward into investment decisions. Teams should receive problems and constraints rather than predetermined feature lists. Portfolio management should balance exploration, growth, sustainment, and retirement.
Product funding should support persistent capacity and rolling investment reviews. Platforms and shared services should enable product teams rather than become ticket-based bottlenecks. Architecture should support end-to-end ownership and manageable dependencies. Continuous discovery and delivery should operate together. Product success should be measured through customer, business, product-health, delivery, and learning outcomes. Governance should establish boundaries without suppressing experimentation. The operating model must reflect organizational context rather than copy another company. The POM itself should be treated as an evolving product.
Frequently Asked Questions
What is a product operating model?
It is a blueprint describing how an organization designs, develops, delivers, funds, operates, improves, and governs products throughout their life cycles.
How is it different from product strategy?
Product strategy defines where and how a product will create value. The operating model defines how the organization will execute that strategy.
How is product mode different from project mode?
Projects are temporary and focused on predefined outputs. Products persist and are managed around customer and business outcomes.
Does product mode eliminate projects?
No. Finite and highly predefined work may still use projects. Product mode should generally be the default for evolving software-enabled products and services.
What should a POM include?
It should normally include:
Product principles Strategy deployment Portfolio management Product life cycle Funding Team structures Roles Decision rights Technology Platforms Metrics Governance
Should there be a separate IT operating model?
For modern digital products, technology should be integrated into the product operating model rather than treated as a separate delivery function.
What is a persistent product team?
It is a cross-functional team that remains responsible for a product and its outcomes beyond a temporary release or project.
What is a value stream?
It is the end-to-end flow through which a customer or user need is converted into value.
How should products be funded?
Organizations can fund product or team capacity and reassess investment periodically using evidence rather than fixing complete scope in advance.
Do product teams have unlimited autonomy?
No. They should operate within clear strategic, architectural, financial, security, regulatory, and ethical boundaries.
What are empowered product teams?
They are teams given an outcome, customer problem, resources, constraints, and enough decision authority to discover and deliver solutions.
What is continuous discovery?
It is the recurring process of learning about customers, problems, opportunities, and possible solutions through research and experimentation.
What is continuous delivery?
It is the ability to release small, reliable product changes frequently and safely.
What is the role of platforms?
Platform teams provide reusable internal products that reduce cognitive and operational burdens for customer-facing teams.
What is the role of shared services?
Shared services provide specialist capability such as security, legal, data, finance, or infrastructure. They should be integrated so they enable rather than delay product teams.
How should product success be measured?
Use combinations of:
Customer outcomes Business results Product health Delivery performance Learning
Are OKRs required?
No. They are one possible strategy-deployment mechanism. The organization should choose an approach that fits its context.
Why do product transformations fail?
Common causes include:
Project-based funding weak product ownership functional silos excessive governance unclear product boundaries output metrics leadership resistance
Should a company copy another organization’s POM?
No. External examples can accelerate learning, but the final model must reflect the organization’s strategy, products, risks, architecture, and culture.
How long does product transformation take?
Structural and behavioral change may require several years, although meaningful improvements can begin through focused pilots and incremental changes.
Where should an organization start?
Begin with the most consequential operating pain, such as weak strategy alignment, project funding, dependency-heavy teams, or poor customer discovery.
Conclusion
A product operating model is not an agile framework. It is not a new set of job titles. It is not a diagram of squads, tribes, or value streams. It is the operating system through which an enterprise repeatedly converts strategy, technology, talent, capital, and customer understanding into value. This distinction matters because many transformations stop at the visible layer.
Organizations introduce:
Product managers agile ceremonies roadmaps OKRs cross-functional teams Yet the deeper system remains unchanged. Finance still funds temporary projects. Executives still approve solutions rather than outcomes. Technology remains a downstream delivery function. Teams still dissolve after launch. Performance is still measured through scope and utilization. Under those conditions, product language cannot overcome project economics and project governance.
Thoughtworks’ framework is valuable because it places the POM at the intersection of behavior, work, governance, organizational design, and technology. It describes how information flows, decisions are made, resources are allocated, and value moves through the organization.
The model should create alignment among:
Business strategy Product portfolios Team boundaries Technical architecture Investment Metrics That alignment is what creates speed. Not speed as constant activity. Speed as the ability to learn, decide, deliver, and adapt without repeatedly negotiating across a fragmented organization. The move from projects to products also changes accountability. A project team can deliver scope and leave.
A product team remains responsible for:
Adoption reliability customer outcomes operating cost technical health continued relevance That persistent responsibility encourages better decisions. It also requires a different relationship with leadership. Executives must shift from specifying output toward setting direction, allocating capital, defining constraints, and reviewing evidence. Finance must move from approving false certainty toward managing investments under uncertainty. Technology must become part of product strategy rather than an implementation service. Risk and shared services must provide integrated guardrails rather than late-stage gates.
The transformation should not be treated as a one-time redesign. Thoughtworks rightly argues that operating models must evolve as organizations learn what works, respond to strategic priorities, and adapt to changing business conditions. A simple starting model is often better than an elaborate theoretical one.
Begin with:
One important value stream Clear product ownership A persistent cross-functional team Measurable outcomes Protected funding Direct customer learning Reduced dependencies Then observe where the surrounding enterprise prevents the team from succeeding. Those barriers reveal what must change next.
The defining question is not:
How do we make our projects look more like products?
It is:
How should strategy, money, teams, technology, authority, information, and measurement operate together so the organization can continuously discover, deliver, and improve products that create meaningful customer and business value?
Relevant Articles and Resources
How to Create a Product Operating Model to Support Product Organization Transformation - Thoughtworks The core framework defining a POM, its three major areas, product principles, strategy deployment, portfolio management, funding, life-cycle processes, structures, and contextual implementation. How to Build an Organization That Creates Great Products - Thoughtworks A detailed guide to product mindset, customer-centered organization, product transformation, and the shift from project mode to product mode. A Practical Framework for Embracing Product Maturity - Thoughtworks A team-level maturity framework covering user-centered behavior, value orientation, rapid response, continuous growth, communication, collaboration, steering, and governance. From Project to Product: The Next Frontier of Value Creation - Deloitte A complementary product-operating-model framework covering value streams, governance, objectives, shared services, performance measures, transformation leadership, integrated tooling, and AI-enabled engineering. Operating Models for Business Success - Thoughtworks A broader examination of customer learning, technology, organizational design, governance, leadership, and continuous adaptation in modern operating models. The Organization of Software Teams in the Quest for Continuous Delivery Research examining siloed departments, DevOps structures, cross-functional product teams, and platform-team models.
DevOps Team Structures: Characterization and Implications Research on product-team autonomy, shared product ownership, horizontal platform and enabling teams, and the relationship between organizational structures and software-delivery performance. Blurring Boundaries: Toward Collective Empathic Understanding of Product Requirements Research showing how organizational structures and specialization affect a cross-functional product team’s ability to develop shared domain and customer understanding. Enabling Autonomous Teams and Continuous Deployment at Scale A case study examining the transition from project-oriented delivery toward autonomous teams and continuous deployment in a large public-sector environment.