Over the last two years, we have been working on the Agile Product Operating Model (APOM). This work has led me to speak with many people across companies in the automotive, biotech, pharmaceutical, banking, retail, and software industries. The variety of ways they ‘do’ product is broad, spanning how they fund, align, plan, organize, and deliver products. However, the underlying principles across these approaches are the same, or at least their aspirations are. Every company had the same North Star. They all aspired to have fast-moving, outcome-aligned, always-learning teams. But, of course, the challenges of scaling these ideas made for many compromises. Those compromises are often cited as evidence that agile didn't work, but from my observations, they were people trying to do their best in an environment where power, status, authority, and risk were ultimately more important than delivering value to stakeholders. What was remarkable across these conversations was that, even though many people understood the challenges, they still wanted to drive change toward something better. Their aspirations and passion are what agile is: a desire to bring in a way of working that responds to the environment, delivers value whilst supporting and developing the people who do it. Agile will only die if these people stop following their passion, and I do not see that happening.
With the release of the APOM Guiding Principles, we have compiled all key principles from these discussions into one place. This single document should provide an overview of APOM by describing the principles that organizations using APOM apply. It is quite comprehensive as we describe the same principle across different areas. As we developed this document, we have, as you can imagine, had a number of questions. Let’s address the top three questions:
Why isn't this a framework like Scrum, Nexus, or EBM?
Based on my observations, each operating model is unique to the organization that uses it. Yes, your implementation may be inspired by a particular framework, but ultimately it is unique to the organization. The challenge, as you scale with framework-based approaches, is that organizations become fixated on the framework and forget the intent or principles it is meant to drive. I saw countless examples where the underlying principle the framework encouraged was dropped, yet the process was still called by the framework name. Great examples in Scrum implementations include Sprint Planning, where the team is presented not only with a goal but also with the tasks they need to accomplish to meet it; and planning is really just a communication exercise, or where Product Owners are given a vision but have no ownership of it. Yes, it is still called Sprint Planning and the Product Owner is still the Product Owner, but those words are hollow. The mechanics of the framework support an intent; however, it is easy to forget that intent and focus instead on the mechanics. In the Scrum world, this is called mechanical Scrum.
That is why our thinking on APOM has evolved from a framework to a set of guiding principles. The intent is to provide a set of principles that allow you to evaluate any framework, pattern, or approach. Frameworks are very useful, as they often provide a clear strategy for implementing a set of ideas, allowing users to quickly leverage the framework creators' experience. The Guiding Principles of APOM enable you to apply any framework you have and ask how the framework implements that idea, and whether your organization has taken that idea and implemented it correctly. For example, in Strategy, the first principle of always linking product strategy to clear business outcomes in SAFe aligns with the Strategic Themes, which are executed in Lean Portfolio Management (LPM). By looking at your own implementation of LPM and how these flow into the work, you can determine how you implement this principle. Evidence of the % of strategic initiatives explicitly tied to a clear business objective or customer outcomes would then be used to monitor compliance with that principle.
Why are there no explicit roles or job titles?
One of the most successful elements of Scrum is the accountabilities (formerly known as roles). When people adopted Scrum, they assumed the roles of Scrum Master or Product Owner. That enabled a clear break from the existing process. The titles became a catalyst for the change. The reality, however, was far messier. Most organizations did not really embrace the intent of these accountabilities; they either added them as an adjunct to the organizational structure or extended existing job titles with a ‘ / Scrum Master’ or ‘ / Product Owner’ without any real appreciation of the change to the existing title. How many project managers are also Scrum Masters with both sets of accountabilities?
The reality is that people and job titles are complex, and the situation would benefit from an agile, empirical approach supported by experimentation. However, experimenting with job titles and accountabilities is challenging for most organizations. People like stability and clarity. Most large organizations do not entertain the messiness of such an approach. As you scale and look at the whole operating model, it becomes even more difficult. Instead of describing job titles, we have focused on behaviours described in the principles, and how that maps to the organization will depend on your context. I would, however, encourage any organization to view incentives as a key enabler of change and to consider a holistic approach to people.
The Guiding Principles are nice, but now what?
The principles describe an ideal state for a product operating model. The principles cover each element of the operating model from the strategy to the value cycle. There is, however, a significant gap between principle and implementation, which requires applying processes, people, and tools. That will require a plan, and the Guiding Principles and other APOM materials can help.
Building a survey can help to gather useful information about the current situation. I suggest you take the Guiding Principles and the APOM overview whitepaper to your friendly LLM and use them to build a series of surveys. For example, I used the following prompt to quickly develop an assessment for leaders at a packaged-goods company. I have replaced the company name with "Consumer Packaged Goods" for this example, but I recommend using the real name, as it creates more personalized surveys.
I created a scoring guide and used it with the same LLM to analyze the results. Of course, the LLM does not replace your analysis and review, but when combined with the Guiding Principles and Narrative of the overview whitepaper, it provides a comprehensive starting point for future analysis and operating model improvement. Think of it as having Scrum.org help on your operating model review without the need to buy me lunch or beers after work 😀
The Impact of AI and the Future of APOM
In the last few years, I have been talking to many organizations that are adopting or considering a product operating model. During these conversations, AI entered the discussion and gradually reshaped the dialogue. AI will be a significant disruptive force across both the capabilities organizations provide (products and services) and how we develop and maintain them. We have only just started this journey, but I do see the operating models being influenced by AI already, maybe not in terms of what they do, but how many people are doing it and who does it. AI truly enables us to embrace rapid learning loops and cross-functional teams, and it readily improves all the disciplines associated with product delivery.
The question I have been asked many times is: What impact does AI have on organizations? My response to early discussions with leading companies is faster, smaller, and flatter. These three words may seem obvious, but experience shows that large organizations take something that could make them faster, smaller, and flatter and do the exact opposite. Embracing the obvious opportunity by increasing everything instead, which ultimately makes things slower.
Who knows what is next for organizations as AI becomes mainstream, but I do know that the fundamentals still apply.
- Align your teams to clear outcomes.
- Allow them to deliver and learn frequently.
- Empower them to own the way they work and the outcomes they deliver.
- Remove all impediments that stop that, including incentives.
Products provide strong alignment, creating an environment in which an organization's capabilities are clearly executed and strategically supported. AI will accelerate your product capabilities, but only if you have a strong, agile, evidence-based product operating model.