How to create a product operating model to support product organization transformation

To keep pace with digital natives and rapidly changing customer expectations, many enterprises are transforming into product organizations, where the business is organized around products (and meaningful outcomes) rather than projects (and arbitrary outputs).

The shift from project mode to product mode requires an entirely new mindset, culture and organizational structure. Great product organizations use product thinking and product-oriented ways of working to achieve their objectives — and everything is underpinned by a product operating model (POM).

The POM defines how the organization operates in product mode to help it become more resilient and responsive and accelerate business growth. A well-designed POM allows you to achieve three of the biggest benefits of becoming a great product organization:

• Prioritize the right products by making decisions based on data, not just intuition

• Speed up time to value by getting great ideas to market faster and improving adoption, growth and retention

• Boost ROI from your investments by empowering customer-centric, outcome-led teams to generate greater business value

What is a product operating model?

A POM defines how you design, develop, deliver and manage products throughout their lifecycle. It describes how the various components of your organization work together to execute the strategy and deliver value to customers, users and the business.

The POM should explain how your organization manages product development, including technology and software development. Having a separate technology or IT operating model suggests you’re in project mode, where ‘the business’ provides requirements to be delivered by ‘delivery teams’ or ‘squads.’ 

Instead, the POM must cover technology considerations. Software development is an extremely important part of modern product development. However, product development must also consider wider impacts such as process, pricing and policy changes and go-to-market strategies.

Having a defined, published and shared POM means everyone speaks the same language, accelerating understanding, alignment and the subsequent delivery of value. The POM explains the standards that give people the space to innovate. Having common approaches and language improves operational efficiency, reduces friction and increases cohesion across the organization. However, you should remember that standardization is the friend of speed, but the enemy of innovation. Being too prescriptive or having too much governance can stifle innovation. 

What should a product operating model include?

The POM should provide a blueprint for how work is performed, people and resources are allocated, decisions are made, and information flows through the organization. It ensures a systematic and consistent approach to product development and management, aligning the efforts of various teams and functions. The more aligned your organization, team structure, technical architecture and objectives, the faster you can deliver customer, user and business value.

The specific contents of the POM will depend on your organization’s unique context, but in general, all POMs cover three key areas:

The POM covers three key areas

1: How people should behave 

Your POM should define the product development philosophy and culture that drives behavioral expectations.

• Product manifesto and principles — Descriptions of the shared beliefs, values, and behaviors that influence how to approach work, make decisions and interact with colleagues and customers. You should use these principles as design tenets for the POM.

• Product organization metrics and performance management — A clear definition of how to measure success and the key metrics you’ll use to understand how the product organization is performing.

2: How work is planned, executed, monitored and governed 

The POM should include descriptions of the high-level processes that drive the efficient and effective flow of information and the delivery of value. 

• High-level processes and workflows — These may involve specific methodologies like Agile and waterfall, but it’s best to take a tailored approach based on your organization’s needs and context. You should also have a product framework that provides an overview of how the main components of the POM processes connect.

• Strategy deployment framework — This describes how you’ll put the business product strategy into action on the ground, including goals alignment and OKRs. 

• Portfolio management — Descriptions of how you classify, manage and prioritize products throughout the lifecycle of introduction, growth, maturity and decline, for example using the three horizons: sustain, explore and exploit. 

• Product management and development lifecycle and methodologies —  A definition of how work flows from idea to value, including idea generation, requirements elicitation and gathering, roadmapping, prototyping, testing, iteration and path to production. 

• Artifacts, tooling and toolchain — A description of the software, applications and technologies that support product development and enhance productivity, including their integration (the toolchain).

• Investment and funding — A definition of how you fund work and teams, including the approach and frequency, and the process for allocating additional funding if required.

• Governance mechanisms — This defines the system, process and structure that guide and assure decisions, including guidelines for identifying, eliminating and minimizing risks and issues.

• Communication channels — This describes the pathways for the flow of information, messages, and ideas. For example, face-to-face for idea generation, instant messaging for informal team communication, or video conferencing for product reviews.

• Decision-making processes — A definition of the level of risk that individuals or teams can take, how to escalate critical issues and complex problems, and how decisions should be captured and communicated.

3: How people are organized to deliver value 

The POM must document how your cross-disciplinary, multi-functional, self-managing product and platform teams are aligned to customer and business value streams and your technical architecture. 

• Organizational structure — A description of the hierarchy of roles, responsibilities and relationships, including a clear representation of how different parts of the organization interact and work together. 

• Conceptual model — A representation of how the product organization operates, helping people understand and communicate its essential elements and relationships. This is a high-level, simplified depiction of the POM, without any specific implementation details. 

• Product organization design — This describes the structure of the product management function, the product teams and their associated functional and line management relationships.

• Product topology — A definition of the products within the organization and their relationships to each other, including sub-products, supporting or enabling products and systems, and technical platform products that drive developer experience.

• Team topologies — A description of how product and platform teams are organized, for example, by user journey stage, business goal, customer problem, or market segment. Ideally, you should closely align your product topology and team topology.

• Capabilities — A list of the organizational capabilities required to deliver the products. This may include your default sourcing approach, such as in-house, co-sourced, partially outsourced or outsourced.

• Team composition — This describes typical patterns of the roles on product and platform teams.

• Roles and responsibilities — Clearly defined job titles or positions required to develop products, including the specific tasks, duties or obligations associated with a particular role.

• Career pathways and ladders — A definition of how individuals can progress within a discipline or move to an adjacent discipline, including a structured and progressive series of roles or seniority.

A visualization of example POM contents

An example organization conceptual model

What should a product operating model not include?

To make your POM an effective artifact, it mustn’t repeat information from elsewhere. For example, the POM shouldn’t detail your organization operating model and policies or your business and product strategies.

Similarly, the POM shouldn’t contain templates and tools or detailed step-by-step processes and workflows. You should share these through toolkits (containing tools, templates, best-practice guidelines and resources to support product development) and playbooks (structured documents that outline processes and procedures for specific activities).

The relationship between the POM, other operating models, playbooks, business vision and strategy, product visions and strategies, and the enterprise architecture and technology vision.

The relationship between the POM, other operating models, playbooks, business vision and strategy, product visions and strategies, and the enterprise architecture and technology vision.

When should you use a product operating model?

Using a POM doesn’t mean all projects stop; many organizations use a hybrid of projects and products to deliver change. But modern organizations that use software to provide experiences, products and services should default to product mode and adopt a POM.

Project mode can be more suitable when the scope and requirements are well understood, for example, in a pure tech migration or something physical like setting up a new store or building a factory. However, with the speed of change in the digital world, initiatives with well-understood scope and requirements are now few and far between.

A project operating model may also be suitable if your organization is trying to catch up with competitors and simply copying their features. But remember that you can’t stay in project-mode if you want to win. 

Copying competitors’ features provides no competitive advantage and is more of a survival tactic to retain your existing market position. Also, consider that continually adding features to your product increases its complexity and total cost of ownership. To innovate and surpass your competitors, you’ll need to adopt a POM and operate in product mode.

Creating your product operating model

Operating models should evolve as you learn what works for your organization, adjust to align with strategic imperatives and respond to challenges in the business landscape.

It’s not simply a case of just ‘installing’ a POM. You can certainly use ‘best-practice’ templates as accelerators to get started, but you’ll need to incrementally develop your POM to make it fit your unique context and make the change sustainable.

The best place to start is with the biggest pain point in how you operate. For example, if you have alignment issues or gaps between strategy and execution, begin by implementing a strategy deployment framework, such as OKRs (Objectives and Key Results).

It’s also worth noting that different types of products suit different operating models. Managing an internal product is quite different from managing a market-facing product.

Developing the right operating model for your organization

In some cases, variations of the operating model might co-exist, depending on the context and needs of your organization. For example, ‘big bet’ innovations may be treated differently from initiatives with heavy third-party dependencies.

Your operating model should stem from the business and customer outcomes you want to achieve. Don’t jump to solutions too soon or expect success by copying others. It might seem like a fast and easy solution to copy what’s worked elsewhere, but it might not work for your unique culture and context.

And finally, remember that operating model changes, especially those that involve structural changes and new roles and responsibilities, are difficult to reverse, and it can take several years to realize the expected performance improvements. Starting with a simple operating model can be useful to ensure you focus on the most important things, avoid dysfunctions and start changing employee behaviors.

To find out more information about product organization transformation, don't forget to read our ebook How to build an organization that creates great products.