Business agility is similar to the agility we observe at the team level, but it extends across the entire company. It is a Holy Grail many companies try to obtain. Companies want business agility to outperform their competitors. It will allow them to fluently and effortlessly absorb new market trends and opportunities at no additional cost.
This blog describes how Business Agility can be achieved with Product Management by moving up on the Org Topologies™ map.
If you are unfamiliar with the Org Topologies™, the tool for strategic organizational development, you can get started here.
The Product Gap
Let’s address the elephant in the room: We have too many Product Owners!
How many Product Owners do you see in your organization? You’ll likely find them in the IT department, as that’s their natural habitat. I bet you will find more than one!
Now think about this: How many products does your company sell? One? Three? I bet your company sells not as many products as you have Product Owners. Right?
If the above is true, what exactly are these “Product Owners” owning?
The best way to find out is to ask the PO two simple questions:
- What is the “product” that you own?
- And how do you know you “own” it?
What is the Product?
It turns out that what is generally called a “product” is not a “Product” at all. (Note that I write Product with a capital P when I refer to the real product the company sells to its customers). What the POs and their teams define as “product”, is one of many applications, services, steps in the value chain, components, features, etc. These are not things the company sells as separate items to their customers. The company may sell phones, insurance, or bicycles. These are real Products. A PO who is responsible for connectivity, search, or the billing engine is not building a Product, they are building a feature or a component. In Org Topologies™, “the Product gap” is the space between the team-level product definition and the customer-level perception or whole business-level of the Product.
What is ownership?
“Ownership” at the team level boils down to preparing work for the team and aligning with other teams they have interdependencies with. This is achieved through team-level product backlog management: the POs receive requirements and write the specifications to share them with their team. They align their work with other POs and if possible, adjust the order in their backlog to accommodate the needs of the other teams.
Classifying the Product Owner
In our Professional Product Owner classes, we show the picture below. Most Product Owners plot themselves on the left side of this image: scribes and proxies. Often they use other names to describe their roles such as Requirements engineer, Team output owner, or Team lead.
Typically, the left-side PO works on tasks or features and is responsible for a single team. In Org Topologies™, we map this level of Product Ownership in the Y and A-level archetypes.
Why is having many low-level Product Owners a problem?
In our Scrum classes, we teach that Product Owners are value maximizers. But what value can the low-level PO maximize? Due to their limited scope of ownership (tasks or features) and span of control (single team), all they can maximize is the utilization of their team’s capacity. For example: Billy, the Product Owner of the Billing Engine Team can never deliver the whole customer journey to improve customer retention. Billy can only optimize her teams’ contribution to the requests coming from projects like customer retention. Whatever Billy decides will be limited to her span of control: her team. She can make her team faster and maybe achieve a nearly hundred percent resource utilization. But whatever experiment Billy undertakes, she will never achieve Business Agility, i.e. enable the whole company to change direction cheaply and effortlessly.
Billy and her colleague POs all need to contribute to larger business initiatives, programs, projects, epics, or whatever they are called in your organization. These projects are initiated and prioritized by business stakeholders. The projects need to be decomposed into work units at the team (specialization) level. For instance, the billing team needs to get the specs for the changes needed in the billing engine for the customer retention project. Same for the search team, and so on. Each fragment of work needs to be managed across the teams because each team will independently prioritize and deliver their work. Only after all teams finish their part (rework included), and separately delivered team increments are integrated in the final product, our customer can enjoy the retention functionality.
The ecosystem described above must look familiar to you. You will agree this is an expensive way of creating product changes, with a low ability to deal with unforeseen changes and an inability to swiftly change the whole company focus.
The Product Manager can close the Product Gap
In case you missed it, the latest hype in the agile space is about “Product”. Many people are talking about Product Management, Product Operating Model, Product Thinking, Empowered Product Teams, etcetera. “The Product approach” is the latest promise to solve all current digital product development problems.
Regardless of the Product focus being the latest hype, I think taking the Product approach does stand a reasonable chance of reducing the problems of expensive, inflexible, and slow value delivery. We should focus on closing the product gap by elevating both the PM role and the teams. (We use the word elevating to indicate the upward movement on the Org Topologies™ Map).
Elevating the PM role
The Product Manager (PM) has a holistic view and speaks the customer language. They typically live on the Business side of the company. They are visionary and responsible for delivering a product that addresses a real need and represents a viable business opportunity. They implement the company’s strategy through the product and work on product-related tasks such as pricing, packaging, releasing, innovating, branding, advertising, etc. As per the Org Topologies™ map, the Product Manager is located in the upper left part of (C0/C1) the map.
To close the product gap, we need to connect the PM directly to the teams. In other words, the Product Manager becomes an entrepreneurial Product Owner or Agile PM. They act like mini-CEOs and manage a company-level Product backlog. In many companies, such a backlog already exists but has different names, the Product Portfolio for instance. Having such a backlog allows the PM to prioritize the work for the whole organization. The Agile PM works directly with many teams instead of passing information via business analysts. They will spend most of their time managing stakeholders and prioritizing the work, not clarifying it. To empower the Agile PM, we will need to remove all low-level team-bound “product” backlogs and aggregate them in the company-level Product backlog, creating a single source of truth.
Elevating the teams
To move the teams within reach of the Agile PM, we must elevate them by creating teams of teams with a business problem scope. Creating a team of teams is similar to creating cross-functional teams with individuals, but at a higher level of abstraction: Instead of combining individuals to solve problems at the feature level, we combine teams to solve problems at the business level. Each team of teams has all the capabilities to solve any problem in their domain as a group.
Combining a single business-level backlog with teams of teams creates the opportunity for teams to abandon the isolation of their team-level Sprints. The business-level backlog contains major items that are best addressed through the collaboration of multiple teams. They study and do the work in a shared cadence (Sprint). This eliminates the need for external coordinators to manage the work across teams.
We all know that a common goal makes the difference between a group of people and a team. By working in sync, dependencies between isolated teams turn from interruptions into opportunities for collaboration in the team of teams. In addition, the value delivered in each iteration will be a business-level outcome. Stakeholders will benefit from attending a single Sprint Review to inspect the return on their investment (which is substantial: the cost of the team of teams).
An important prerequisite to getting the best out of this approach is shared code ownership. This implies we need to break the team-feature coupling and broaden the team’s scope of work from tasks or features to the whole company domain. (If a company is too big, we define parts of the business domain that are independent from each other). The goal is that all developers can work on many components, ideally, they can change all code. Most people say this is impossible and undesirable because this will create chaos. On the other hand, the results of private code ownership aren’t great either: complex code and standardization problems. So why not give it a try?
Shared code ownership can be achieved gradually and thoughtfully. How about: “Opening those repositories that need to be changed most of the time to most of the devs.“? Many approaches are available to make this prerequisite less scary (shared standards, stack simplification, automation, to name but a few).
And what about the Team POs?
A team of teams will need to understand the customer’s language. The goals defined in the company backlog are course-grained goals. They need to be understood and turned into solutions by the teams. The clarification work done by the team POs is still necessary even after elevating the teams. Intuitively, the low-level POs join the teams providing them the capability of clarification. The coordination work they were doing is no longer needed. A team of teams works in a single cadence (sprint), meaning they refine, plan, and deliver the work synchronously.
Summary
Business Agility means that a company can work on what is most important at any given moment at no additional cost.
Product Management enables Business Agility by:
1. Placing Product ownership at the whole company level.
2. Creating teams of teams that collaborate synchronously on business problems.
Learn more about the Elevating Structures™ and Business-Oriented R&D to discover the ways to elevate your ecosystem and gain the true benefits of agility.
Learn more about the three types of ecosystems.
Roland Flemm for Org Topologies™