Today, we published a whitepaper describing the Agile Product Operating Model (APOM). This paper was developed over the last year, working with companies transitioning to a product approach and Professional Scrum Trainers (PSTs) who are helping them. I am proud of the work that has gone into this set of ideas.
I'm sharing what I have learned over the last year concerning APOM. During this time, we delivered numerous talks, met with organizations, and discussed ideas with many people. The discussions centered on four areas:
- What are the elements of the model? Each organization is different, but what makes APOM unique and interesting?
- What is a product? What are the characteristics of a product, and what are the implications when your product does not conform to those characteristics?
- How do you manage a product portfolio? What happens to the cross product work?
- How should you organize your product group? How do ideas like team topologies affect the product operating model?
In today's blog, I will focus on the key characteristics of APOM and will discuss other topics in future blogs.
What are the characteristics of the Agile Product Operating Model?
As you can imagine, this is an area of particular interest to everyone. The model becomes overly complex and hard to understand if we include everything necessary for every organization. If we miss key areas, it becomes less useful and valuable.
As the ex-Rational Unified Process (RUP) product manager, I know very well what happens when you build a complete framework and how people adopt everything. I remember a meeting when I was the RUP product manager with a large company. We spent 2 hours discussing adding new things to RUP, like real-time development and outsourcing. At the end of the meeting, the person leading the meeting said there was one more thing. Can we make it simpler, too? Everyone wants complete and comprehensive guidance, but they also appreciate how hard that makes it to implement. How many times have people said that about Scrum? That is why Ken and Jeff wrote the words ‘ intentionally incomplete’ :-)
In discussions over the last year, the following characteristics resonated and created much discussion with the audience.
- Unique - Each product has a unique operating model for its own needs. For organizations that have multiple products, this seems odd. They want one way of building, maintaining, and managing products to reduce complexity and allow flexibility of staff and supporting processes and systems. And there is some merit in having one model for an organization; however, that is a constraint, or objective rather than a norm. How can we talk about a product team owning its destiny, being responsible for the product's value, if they have no control over how they work? Things that reduce the effectiveness of the operating model MUST be evaluated and ideally removed. Of course, some things are necessary in the areas of governance and control that might reduce effectiveness, but the team should understand when it is a fundamental constraint instead of one that is just there because it is. Imagine the situation where a car company provides a product for their dealer network around customer loyalty, but their processes for development include car safety processes. Those processes are crucial for onboard products but make no sense in the sales and marketing product areas. Encouraging product groups to control their destiny and supporting that is a fundamental principle of APOM.
- Holistic - Each part of the operating model affects the other parts. When you think about change, you have to think about it holistically. I spoke to many organizations where the introduction of products was not accompanied by changes to incentives, organization structure, or even processes. That resulted in a very ineffective approach to product thinking and ultimately reduced the success of the product approach. They just renamed their existing approach ‘product’ and changed some words, but the undying alignment and operating model were still projects, departments, and individual-based.
- Evidence-based - Evidence-Based Management has been a key part of the Professional Scrum story for several years. Still, it is broader when we talk about evidence in the context of APOM. It starts in portfolio planning for cross-product initiatives with the use of OKRs. From there, evidence becomes crucial in how products are managed using EBM. Flow metrics become tools for managing the flow of work and the structure of product groups. The need for evidence becomes the cornerstone of every decision and action, and the operating model is also required to drive decisions that define products. Evidence informs decisions and encourages behaviour, but it must be balanced with action. In the same way, Scrum encourages experimentation and delivery, balancing learning with doing is a key idea for APOM.
- Empowered teams - The question about decision-making and empowerment is interesting. Most leaders accept that empowered teams are the answer in complex situations where rapid decision-making is necessary. Still, the same leaders are concerned that too much local decision-making can lead to local optimization, which will be suboptimal for the enterprise as a whole. The one challenge of a product model is that it encourages optimization at the product level. It promotes each product to drive its own agenda rather than try to optimize for the whole organization. Broad needs must be addressed by selecting the right products and introducing constraints. Evidence such as cycle time and clarity around bottlenecks can make those constraints obvious.
- Empiricism - Empiricism combines evidence-based ideas with emergent processes to describe the need for product teams to break things down, deliver frequently, inspect and adapt through transparency, and observe the outcomes. Organizations are always a combination of rationalism and empiricism; however, as uncertainty increases, the need for empiricism grows and manifests itself in the need for shorter planning cycles and striving for more and more evidence.
- Complete - Complementing a holistic approach requires the product operating model to be complete regarding discovery, delivery, operation, and limited dependencies on other products. Classical approaches that separate R&D (discovery) delivery and operations are fantastic for optimization and perceived efficiency, but are inflexible and rigid to change. Instead, organizations should strive to build complete product groups that are inclusive of the three major types of work.
- Change management built in—It seems obvious, but the pursuit of a product model is not an end state but ultimately a response to the need for a holistic agile approach to delivering value. Putting in place change management that observes the model in operation and ensures that it is delivering on the organization's business goals is key. This group should be empowered to drive change and have executive support.
As I discussed these principles with leaders in large organizations, it became clear that their change initiatives differed. In particular, the need for a holistic and complete approach to the product operating model was challenging and would require fundamental organizational change. Of course, every organization must, as my Grandmother would say, ‘cut the suit to suit the cloth,’ but be mindful of the impact of your approach to scope and impact. An incremental approach is always better as long as you have the end goal in mind.