Over the last two years, I have been writing and presenting about the Agile Product Operating Model (APOM), and today we launched a survey as part of that work.
As I reviewed the survey, I realized that for many people, the Agile Product Operating Model (APOM) might be new and require some context.
Lots of materials on APOM can be found here.
History (why Scrum.org is doing it)
It seems odd to be writing a section on the history of APOM when it is so young and still evolving and being discussed, but I want to provide context as to why Scrum.org is investing time and effort in this work.
Like so many ideas, the motivation for APOM came from many intersecting trends and events.
Over three years ago, we realized Professional Scrum Product Owner (PSPO) had gained popularity. Product Owner has always been popular, but due to the significantly lower number of Product Owners compared to Scrum Team members, this training has historically attracted fewer attendees in the prior years. Like any good Product Owner, I wanted to get to the bottom of this trend and chatted with our community and several organizations. I found that there was a serious interest in Product Ownership, but the environment for Product Ownership was challenging. That led Scrum.org to develop some new classes and, more importantly, a workshop assessing an organization's Product Ownership Capability.
Following the advice of Steven Blank and Eric Reis (Lean Startup), I visited numerous organizations struggling with Product Ownership and even led a workshop or two. In every instance, they asked for something much broader than Product Ownership. They needed help moving to a product operating model. In a nutshell, they had a series of digital capabilities (apps, products, services, systems, value streams) that needed to be supported, and they found that a project-based approach did not provide either clarity of focus or reduce the complexity of decision-making. The complexity and overhead of maintaining that approach meant it was too slow to manage modern digital assets effectively.
That pattern of project approaches undermining an organization's ability to deliver digital value was not something new, and there had been many attempts to solve this problem. These attempts were associated with enterprise agile transformations. However, the majority of these transformations retained the concept of projects, even if they renamed the structure and incorporated many agile and lean principles. There was one set of transformations I was aware of that was doing something a bit differently, and they described the move as the move to a product operating model.
At the same time, Marty Cagan was writing and talking a lot about how traditional organizations could adopt modern product management and also move to employing a product operating model.
Product seemed to be an interesting paradigm to invest better, organize, and think about digital capabilities. And in fact, in a Scrum.org survey, we found that 73% of the people answering the survey thought of themselves as working in a product organization. And a whopping 56.5% said that their product provided an end-to-end value proposition, not just a subsystem or part of the process.
But that did not jive with my experience. In fact, during a workshop, I discovered that most people present were operating within a project culture, particularly in the areas of empowerment and alignment.
There was something wrong. The product was following a similar path to agile transformation, where organizations adopted the name but not the underlying operating model. This led to product teams that were not aligned and lacked the empowerment to solve stakeholders' problems. This led to a disconnect between business and technology, resulting in most companies not maximizing their digital capabilities.
This realization took me and a few Professional Scrum Trainers on a two-year research and presentation journey, which ultimately resulted in a set of ideas and some structure that is called the Agile Product Operating Model (APOM). Ultimately, the Scrum.org mission is to help people and teams solve complex problems. To achieve this, you need an environment that supports the principles of agility, utilizing tools like Scrum, Nexus, Kanban, and EBM. Our mission is being undermined by the environment that surrounds the teams trying to deliver value.
Highlights that describe APOM are featured in a series of blogs.
The Future of APOM
Honestly, I don't know what the future holds. APOM provides a unified collection of ideas that bring Scrum, Nexus, EBM, and modern product thinking together in a story that makes sense. It is based on real organizations doing elements of the model. It also does not prescribe a methodology; instead, it focuses on the ideas and describes how approaches like Scrum and Nexus enable those ideas to be implemented. It might sound dogmatic and incomplete, but that is not my intention (of course). Still, those two characteristics highlight my excitement about specific ideas (who doesn't love Scrum) and the stage in APOM's evolution.
We are still learning, and in fact will always be learning. And that is one of the biggest challenges for this approach. Ultimately, APOM asks questions about how your organization aligns, funds, and operates its “products”. It encourages a holistic approach that leans heavily on modern product thinking and the principles of Professional Scrum. This leads to various implementations, and there are no always correct, always wrong answers. You have to build your own approach from these ideas. And some people don’t like that. They want a single blueprint, one strategy that fits every problem they are facing. That is wrong. There is no silver bullet!
However, a growing body of knowledge and ideas would greatly benefit from your participation in this survey, where you can share your insights on your working environment.
Please fill in this survey, it will really help! Based on the survey results, we intend to create follow-up content to continue this discussion and provide more insights into these trends.