Listen to the audio version of this article:
Back in 2009, a group of handpicked individuals had gathered in a conference room, looking at me expectantly, as I kicked off the very first product management workshop for the IT department of a large insurance company. But when I asked the attendees what products they managed, they looked confused and said, “What do you mean? We don’t manage products. We run projects.”
At the time, there was no common awareness that the software assets created in-house could be viewed and managed as products. A product was exclusively thought of as a commercial offering, like an insurance policy. What’s more, teams often worked on multiple software assets within a single project, and the projects were comparatively short. This made it hard to determine the business impact. Clear ownership and accountability were lacking. But there were plenty of hand-offs, loss of knowledge, and misalignment.
Luckily, things changed for the better, as the company started to employ a product-led way of working, which is also known as the product operating model or product model, for short. Instead of running temporary projects, work is organised around products. These are owned by enduring product teams who are responsible for achieving the desired customer/user and business benefits.[1]
Over the past fifteen years, I’ve helped a range of organisations in different sectors, including media, financial services, retail, education, transportation, and government, establish a product-centric way of working by enabling product people and teams, coaching Heads of Product, and advising executive leaders. I’ve found that implementing the model can offer several tangible benefits, including improved customer centricity, better financial performance, increased innovation, and higher team motivation and job satisfaction.[2]
However, I’ve also learnt that successfully implementing it is not easy. It requires significant organisational changes and executive leadership in addition to new roles and skills. To help you succeed with your product operating model implementation, I’ve described my learnings in the remainder of this article.
| Projects vs. Products Moving from a project-focused environment to a product-centric way of working is a major change for most companies. Traditionally, software is built through a series of separate, comparatively short projects, which are led by a project manager. Success is often defined by delivering the project on time, on scope, and on budget.[3] Contrast this with products, which are (digital) assets that create value for users and/or customers and the business. They often exist for many years and have a different life cycle compared to projects. Products are only successful if they create the desired value. Additionally, they are managed by product managers with the help of cross-functional product teams. This does not mean, however, that projects are no longer needed when you embrace a product-led way of working. They are still valuable, for instance, to manage a data migration effort, achieve regulatory compliance, and implement organisational changes, like establishing the product operating model. What changes, though, is the default way to manage work: instead of running projects, you focus on products. |
Let me start by giving you an overview of the four aspects that must be addressed to succeed with the implementation of the model. These are: organisation, people, processes, and tools, as shown in Figure 1.
Out of the four aspects, organisation is the most important one, followed by people. You can, for example, implement an awesome product discovery process and build amazing Opportunity Solution Trees. But if the necessary organisational changes aren’t taking place and product teams aren’t effectively set up and adequately empowered, you won’t be able to fully establish the product model and reap all its benefits.[4] Instead, you are likely to end up with a halfway house between the old and the new world, where product managers struggle to do a good job and create the desired value, as they lack the necessary skills and organisational support.
I have seen no major change initiative succeed that didn’t have executive leadership and a clear vision for change. Introducing the product model is no exception. It has a profound impact that goes beyond the IT/technology department, affecting other parts of the organisation, including marketing, sales, finance, support, and HR. Let me give you four examples:
It’s virtually impossible to make these changes without the support of the executive leadership team. In fact, I recommend that the CEO champions the product model implementation. This maximises the chances that the necessary changes will actually take place and that the transformation effort is aligned with other initiatives that might happen, like an AI transformation.[5]
While executive leadership is great, it’s not enough. To mobilise people, you need a clear and compelling vision for change.[6] Otherwise, why should people be bothered and support the transformation? Make sure that the vision is easy to understand and that it resonates with the employees. My advice on creating an effective product vision can help you with this.
With executive leadership and an inspiring vision in place, it can be tempting to quickly implement the product operating model across the entire company. But this would be a mistake. Instead of opting for a big-bang implementation, adopt an incremental approach. Start small and go slow to scale up and move fast. View the initial implementation steps as experiments that offer the following two benefits:
Once you’ve experienced some initial success, spread the new way of working in a controlled manner so each newly formed product team has the right people with the right skills on board and receives the support it needs. For larger companies, this is likely to take years rather than weeks or months. It therefore requires continued executive leadership combined with a fair amount of patience and perseverance.
Finally, be aware that you may have to evolve the corporate culture to fully establish the product operating model. This includes encouraging informed risk-taking, creating psychological safety, fostering a growth mindset, valuing diversity and inclusion, and empowering people to do a great job. This may involve giving product managers and product teams direct access to users and customers, allowing people to attend hackathons or work on “pet” projects, as well as applying a sustainable pace. As with the other organisational changes, the executive leadership team should role model the new values and behaviours to help them take root.
The fact that people are a company’s greatest asset is a well-known truth. It becomes especially relevant when implementing the product operating model. Without paying close attention to the people aspect, the model is unlikely to take hold. It’s like planting a flower whose roots are missing. It may look amazing for a short while—before it withers and dies. In practice, this means introducing new roles and building successful product teams. Let’s take a look at the two measures in more detail.
New Roles
If we want to focus on products rather than projects, we need individuals who can manage them professionally and ensure that they create the desired benefits for the users, customers, and business. In other words, we need product managers.[7] It’s essential to clearly describe the role, stating its authority and responsibility, along with common tasks and deliverables.[8] Here is a sample, high-level description:
Once you’ve described the role, state the desired skills and experiences a product manager should have. This allows you to find the right individuals and determine the learning and development measures that are required to succeed in the role.[9] These should not only include workshops and training courses, but also ongoing coaching to help the individuals apply the tools and techniques effectively to their products.
Be aware that attitudes and interpersonal skills, like an entrepreneurial mindset, empathy, active listening, and conflict resolution, are as important as hard skills, such as creating an effective product strategy and roadmap, selecting the right KPIs, and prioritising a product backlog. Additionally, ensure that the product managers are equipped with the right knowledge before they start their new roles. This sets them up for success and helps establish the product model.[10] Don’t make the mistake of rebranding project managers and business analysts as product managers. Instead, do your best to implement the role properly.
The second role I want to draw your attention to is the Head of Product, also referred to as Chief Product Officer, Director or VP of Product Management. It’s a senior management role that is responsible for helping the individual product managers succeed in their jobs and developing the product management group, as I discuss in more detail in the article What Should the Head of Product Do? The individual often also acts as the product portfolio manager, setting the portfolio strategy and roadmap. [11] To succeed, the Head of Product will benefit from hands-on product management and leadership experience. What’s more, they will have a significant impact on the success of the product model, and they should work closely with the CEO to establish and evolve it.[12]
Effective Product Teams
Product management is not a solo but a team sport. It is very difficult for a product manager to get all decisions right on their own, even if they are very experienced. A product is therefore best looked after by a cross-functional group of people called the product team. Its members have ownership of the product and are responsible for achieving product success. Figure 2 shows how a product team can be designed.
The team in Figure 2 consists of a product manager, a UX designer (for end-user-facing products), a tech lead, and a tester, as well as key stakeholders and a team coach. The first four roles form the core product team. Adding the stakeholders and team coach creates an extended product team. This is helpful to foster close stakeholder collaboration and alignment, and it is necessary when the team is tasked with making strategic product decisions in addition to discovery and delivery ones, as I explain in more detail in the article Should Stakeholders be on the Product Team? Including a coach helps the team be effective, and it frees the product manager from having to facilitate meetings and workshops and ensure that everyone is heard, and nobody dominates.
To fully leverage product teams, you need to do two things: You must be clear on what a product is, and you must get the team design right. Let’s look at these two measures in more detail.
Measure #1: Correctly Identifying Products
As a product team looks after a product by definition, you can’t form effective teams without first correctly identifying products. This might sound trivial. But it is common in my experience that there is no clear common understanding of what a digital product is in larger organisations.
I view a digital product as software that solves a problem or creates a benefit for a group of people and the business. It might be a revenue-generating offering, like a loan, an enabling, end-user-facing product, for example, a mobile banking app, or a technical one, such as an internal software platform.
While determining which software assets are products—and which ones are not—can take some time and effort, do not skip or rush this step. If your product teams aren’t aligned with the actual products, your product operating model implementation is off to a bad start.[13] Additionally, don’t assume that something is a product because there is a group of people working on it. The entity might be a product part, like a feature, component, or even a product bundle.
Measure #2: Choosing the Right Product Team Design
Second, make sure that you choose the right design for your product teams, as this significantly impacts the team’s performance. To help you get the team design right, I’ve put together the following questions:
While you have to determine which team design is right for you, I advocate for product teams that are fully empowered, self-managing, and extended. They are authorised to make strategic product decisions in addition to product discovery and delivery ones. They are collectively responsible for progressing the product and meeting agreed outcomes.[14] Finally, they include key stakeholders and a team coach in addition to the core members. For more advice on designing effective product teams, take a look at my article Setting-up Product Teams for Success.
As important as it is to secure the right support from the organisation and have the right people on board, it’s not enough. To successfully implement the product model and achieve continued product success, you also have to apply the right processes. Now, a process, in my mind, is not a rigorous, detailed definition of how work must be carried out that discourages critical thinking and squashes creativity. Instead, I use the term to refer to shared ways of achieving desired outcomes.[15]
Four processes are especially important in the context of the product operating model: product portfolio management, product strategy, product discovery, and product delivery.[16] Let’s take a closer look at them.
Product strategizing in Figure 3 refers to how strategic product decisions are made to create real value for users, customers, and the business. This includes researching the market, discovering a brand-new strategy, and continuously evolving an existing one. Product discovery, in contrast, is the process of determining the right solution. This includes selecting the right product goals/OKRs, as well as determining the right features and UX design. Product delivery refers to the process of implementing the desired solution in the right way. Sample activities are choosing the right architecture and tech stack, writing clean code, developing a test suite, and creating the necessary documentation.
The three processes discussed so far focus on a single product. But most products don’t exist in isolation. They are part of a product portfolio. Examples include not only commercial products like Microsoft 365 and Adobe Creative Cloud, but also in-house developed finance and HR tools. To maximise the overall value the portfolio creates, it must be proactively managed. Part of this is creating and evolving a portfolio strategy and setting portfolio-wide outcomes/OKRs.[17] For more advice on portfolio management, see my articles The Product Portfolio Matrix, Everything You Need to Know About Product Portfolio Strategy, and Succeeding with Portfolio Roadmaps.
Before we move on to the final aspect of the product operating model, let’s connect the processes in Figure 3 to the roles discussed earlier. The product strategy, discovery, and delivery work should be carried out by the product managers and product teams. This gives them full-stack ownership and ensures that strategy, discovery, and delivery decisions are closely aligned. The portfolio management work, however, is usually performed by the Head of Product, as I mentioned earlier. I find it helpful, though, to involve the product managers in portfolio decisions. A great way to do this is to form a product portfolio team and ask them to join it.
“You cannot mandate productivity; you must provide the tools to let people become their best,” Steve Jobs once said. This insight applies to product management as much as it does to other professions. Consequently, product managers and teams must have the right tools to do a great job.
But with an abundance of frameworks, templates, and software tools to choose from, it can be hard to pick the right ones. To help you get started, I’ll discuss two frameworks that my clients find especially valuable when implementing the product model, as they address two key points: focusing on outcomes instead of features, and clearly distinguishing between different strategies and areas of ownership.
Using Outcomes to Direct the Work and Determine Success
A key change that has to happen when you move from projects to products is how you determine success. A product team has done a good job if their product creates the desired value and meets the agreed user, customer, and business outcomes—rather than delivering a list of features. Consequently, outcomes become a key instrument to plan, direct, and measure work. To help product teams use the right outcomes, I’ve created the framework shown in Figure 4.
The framework suggests that a product team benefits from working with four different types of outcomes: a product vision, user and business goals, product goals, and sprint goals. Let’s take a look at them.
Note that the outcomes above are connected. The vision guides the selection of the user and business goals, which help you choose the right product goals; and a product goal is broken down into several sprint goals over time. This ensures that the development teams work towards the vision, user, and business goals, as I explain in more detail in the article Leading through Shared Goals.
As you might have noticed, Figure 4 also shows the artefacts in which the outcomes should be captured. Vision, user, and business goals are stated in a strategy artefact like my Product Vision Board, and product goals are listed on an outcome-based roadmap such as my GO Product Roadmap. This combination of outcomes and common product management creates clear guidance and avoids inconsistencies and misalignment.[18]
| What about OKRs? If you use OKRs, objectives and key results, you might be wondering if and how the outcomes in Figure 4 relate to them. I find that product goals and sprint goals can be happily stated as OKRs. However, I wouldn’t use them for capturing the vision and user/business goals, as these are neither measurable nor time-bound. The vision’s purpose is to inspire and unite people. The user and business goals help to define the product strategy and establish guardrails that assist product teams in making the right discovery and delivery decisions. |
Connecting Individual Products to Company Objectives
As helpful as it is to work with product-specific outcomes, it would be wrong to limit the focus of the product model to individual offerings. Instead, you should look at the bigger picture and consider how different products and product teams can be aligned. My Strategy Stack helps you with this.
The framework in Figure 5 contains selected strategies that I have found to be particularly important when implementing the product operating model. These are the business strategy, which is also referred to as corporate strategy, the product portfolio strategy, the technology strategy, and the product strategy. Additionally, the stack contains the product roadmap, technology roadmap, and product backlog. While the backlog is not a strategic plan, I’ve added it to show how strategic decisions are translated into tactical, delivery-focused ones.[19]
Note that the different layers and artefacts of the Strategy Stack are systematically connected, similarly to the outcomes in Figure 4. The business strategy guides the portfolio strategy, which directs the product strategy. The latter, in turn, drives the product roadmap, which focuses the product backlog. This way, the decisions captured in the backlog are ultimately aligned with the business strategy.
Once you are clear on the different strategies you need, you can determine who should own them. I recommend in Figure 4 that the business strategy is owned by the CEO and the C-suite, the company’s executive leadership team.[20] Moving down a level, the product portfolio strategy is created and managed by the Chief Product Officer (CPO) together with the portfolio team.[21] Stepping down another level, the product strategy, together with the product roadmap and product backlog, is owned by a product manager and product team. Last but not least, the technology strategy and roadmap are owned by the CTO together with senior architects. As higher-level strategies direct lower-level ones, the CPO’s portfolio decisions guide the strategic decisions of the product teams. This balances the autonomy of the product teams with cross-product alignment.
I’ve intentionally not stated the tools and templates you should use to capture your decisions and create the different strategies and roadmaps in Figure 5. Having said this, you may want to use Roger Martin’s Playing to Win approach to describe the business strategy. To state the portfolio and product strategy, try my Portfolio Vision Board and Product Vision Board, and to formulate an outcome-based product roadmap, use my GO Product Roadmap.
Finally, don’t forget that “a fool with a tool is still a fool,” as Grady Booch once said. Make sure that the product managers get the training and coaching they need, so they are able to set the right outcomes and create product strategies and roadmaps that truly maximise the value their products create.
| What about AI? AI has certainly impacted how product management is practised: Many product management tools are now AI-enabled, and many products are built with AI technologies. But I don’t see AI playing a central role in establishing the product operating model. At its heart, the model is not about technology but people. It’s about finding new ways to help them work together more effectively and create more value for the users, customers, and business. |
Establishing the product operating model introduces major organisational change—its impact goes way beyond the IT or technology group. It is therefore important to ensure executive sponsorship and manage the change as a transformation program. Otherwise, you are likely to end up with a compromised implementation that fails to deliver the desired benefits.
As important as it is to effectively manage the product model transformation, don’t make the mistake of creating a detailed plan upfront. Instead, start small and take the time to learn what works best in your organisation. Then roll out the model step by step. Be aware that you will hit roadblocks and setbacks along the way. Organisational change is never easy, and implementing the product operating model takes patience and perseverance.
Finally, view a product model transformation as an ongoing effort to become better at product management, foster innovation, and maximise value creation. It’s a process that never truly ends.
[1] As with most product management terms, different people have offered different definitions of what the product operating model is. For example, Cagan et al. write in their book Transformed that “the product operating model is about consistently creating technology-powered solutions that your customers love, yet work for your business.”
[2] These benefits are not only based on my own experience. For example, the article “The bottom-line benefit of the product operating model” by Chawla et al. shows a strong correlation between successful product model implementations and business performance.
[3] Note the Project Management Institute (PMI) suggested a revised definition of project success in 2024. A project should now be seen as successful if it has “delivered value that was worth the effort and expense.”
[4] This does not mean, however, that organisational changes have to take place before you can start experimenting with a product-led way of working. The opposite is true. Applying selected product strategy and discovery practices can help secure senior management buy-in and win over sceptics. (This approach is, in fact, a well-known change technique. It’s described by the pattern “Hometown Story” in the book Fearless Change by Mary Lynn and Linda Rising.)
[5] I am not alone in making this recommendation. For example, Cagan et al. write in Transformed, “The CEO needs to be viewed as the chief evangelist for the product model.”
[6] Creating a clear vision is a key step in Kotter’s model for successful large-scale changes, see the book The Heart of Change.
[7] I use the term product manager in this article to refer to the role of the person who is in charge of a product. In an agile, Scrum-based context, the role may be referred to as product owner. See my article Product Manager vs. Product Owner for a discussion of the similarities and differences of the two roles.
[8] For larger products and in larger organisations, you may require several product manager roles, such as associate, junior, and senior product manager. To get started, use a single product manager role along the lines suggested and gradually introduce additional ones as needed.
[9] Note that the specific skills will depend, to a certain extent, on the type of product an individual looks after. A technical product like an internal software platform will require different capabilities compared to an end-user-facing one, see my article Do Product Owners Need Technical Skills?.
[10] This requires you to design an initial learning and development program, which you should review and adapt as the product transformation progresses.
[11] In larger companies, the product management organisation can be too big to be managed by a single individual and therefore requires an additional management role, which might be called lead product manager. The role manages a group of product managers and reports to the Head of Product. In line with my recommendation footnote 8, I advise starting with a single people management role and introducing additional ones as and when they are required.
[12] I find that the right product management and leadership experience and the right personality are more relevant to succeed as a Head of Product than domain knowledge. You might therefore want to consider hiring someone external with the right profile.
[13] To start implementing the model, it’s usually sufficient to clearly identify the products the first product teams will be working on. This buys you more time to review all assets.
[14] The product manager acts as primus inter pares and has the final say on product decisions if no agreement can be reached within the team, as I explain in the article Should Product Teams Be Self-Managing?
[15] While I’ve seen organisations use detailed, bureaucratic process descriptions, I have found that in practice, they are rarely followed in detail.
[16] Cagan et al. refer to the last three processes as “concepts” in their book Transformed.
[17] Note that there are two different types of portfolio management, which are not to be confused: product and project portfolio management. While companies are often familiar with the latter, the former usually has to be built up during a product model implementation.
[18] If you are looking for an effective way to capture the outcome of the next iteration, try my sprint goal template.
[19] Note that you will have to use additional tools to fully establish a product-led way of working, including a business modelling tool, a KPI selection framework, a business case template, and a UX design strategy. The Strategy Stack in Figure 5 is therefore not intended to be complete. As mentioned in the text, it focuses on those that are critical for a successful product model implementation.
[20] This does not imply, however, that only the leadership team determines this strategy. The opposite is true: I find that a collaborative approach like Strategy Deployment (Hoshin Kanri) can not only help create a better business strategy but also increase its acceptance amongst the employees.
[21] I use the term Chief Product Officer (CPO) instead of Head of Product in Figure 5 to be consistent with the other senior management roles shown. You can find more information on portfolio teams in the article Everything You Need to Know about Product Portfolio Strategy.
Every product has a strategy. But not all product strategies are clearly articulated, let alone…
Product teams play a key role in solving user problems and achieving product success. But…
AI has significantly impacted product management. But so far, most product teams have used it…
Stakeholder management is as important as it is challenging: Without the support of the stakeholders,…
Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be…
How product leadership is practised has a big impact on the success of individual products…
