The eighth blog, in a blog series about the upcoming book: Creating Agile Organizations – A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.
In this blog, a short description of one workshop from Chapter 11: Guiding The Product Ownership.
Avoid Product-Part Owners
Misconceptions about the Product Owner (PO) role often lead to reduced agility, development bottlenecks, and teams that do not understand the customer domain well enough to make autonomous decisions during a Sprint.
A common mistake in large product development is having POs who work on a product part instead of the complete product. Although people call such a person the PO, they often work solely on requirements gathering and play the PO role for one single team. Such a team PO manages a team product backlog, and acts as a liaison between the developers and the users, customers and other teams
The more the team PO acts as a go-between documenting and handing off the “requirements”, the less time the team collaborates directly with the users. Instead, the developers must read the requirements to understand the users’ problems. So it is hard for them to deeply understand the user. Poor understanding of the users’ needs makes it hard to make decisions about solutions, and over time the teams become over-dependent on the team PO. As a result, the teams may make many incorrect decisions or become highly dependent on the PO, which then bottlenecks the team’s performance.
Replace Product-Part Owners with a Product Owner
Teams can develop a good customer understanding when they work closely with customers; they can learn about the customer domain, needs, and problems. Better customer understanding will not only result in better solutions but also increase the autonomy of the teams because they can make more correct and fine-grained decisions on their own; this also increases your organization’s flow and adaptability. A good way to promote team-customer understanding is to eliminate the team Product-Part Owner role, and replace it with 1 Product Owner for the whole product. The team POs are promoted to developers and the teams refine Product Backlog items directly with the users ( as e.g. described in LeSS). The team PO is then no longer responsible for “the requirements” but rather is responsible (just like all other developers) for helping the other developers deliver a valuable product increment.
After eliminating the team PO roles, all the teams work with one PO that is responsible for the whole product’s success.
The Product Owner in a Senior Position
To be successful in large-scale development, the PO needs:
An understanding of the organization and its market, customers, and users to make informed decisions about investment, priority, and release dates.
The mandate to make decisions that will have a substantial impact on product success
The PO’s decisions significantly impact the organization’s financial results. So, consider placing the PO role at a senior management level, for example at the board-1 or maybe at board-2 level. Why? at this senior level, the PO can take responsibility for product success and the financial results for the product.
Figure 0. Example Product Group
Remove Managerial Activities from the Product Owner Role
Many senior roles comprise general managerial activities. In organizational role descriptions, you can find responsibilities including:
Vacations planning 🙂
And many more.
Although these activities are all important, not all are directly related to product ownership. Try removing most of the managerial activities from the PO role so that the PO can focus on the product. The PO or the teams perform all product-related activities, and the remaining general managerial activities are done by—yes, you guessed it—managers. Ensure that the PO is outward-focused on customer and user understanding and not so much spending time in internal ‘run the business’ management meetings.
Typical PO activities are:
Customer research to understand customer segments, motivations, and purchase behaviors of the targeted customers
Stakeholder management and alignment
Financial management such as budgeting to obtain resources needed to develop the product
Driving the direction of development through the visioning and ordering of the Product Backlog
Ensuring the right teams and people are hired to develop the product.
A workshop to start Product Owner role design
The PO role is often a new, full-time role in an organization owing to its accountabilities, responsibilities, and reporting, rather than the addition of activities to an existing role. We often use the following simple workshop format to separate inward-focused management activities from outward-focused PO activities.
Ensure all participants understand the role of the Product Owner and Manager before the start of the workshop.
Invite managers from that work as, for example, product managers, program managers, project managers, line managers, senior managers, and team product owners.
The steps we usually take in this workshop are as follows:
Step 1. Explain that the workshop’s purpose is to separate managerial activities from PO activities. Ask the participants to form into small groups and write down the tasks (one per sticky note) that they do? You might, for example, use the liberating structure 1-2-4-All for gathering input from the participants.
Step 2. Ask the participants to place the tasks from the previous step along the scale Managerial Focus ↔ Product Focus as in figure 1. Use affinity mapping to identify clusters of similar tasks. When complete, the result should look something similar to Figure 1.
Figure 1: Product versus management task focus.
Step 3. Using a Q&A format, facilitate task division the PO, developers, and general management as illustrated in Figure 2. Actively facilitate this step and take the opportunity to clarify any questions or details about the PO activities.
Figure 2: Task separation per role.
Step 4. Closing. Facilitate a group discussion to distill the potential changes required in management and Product Owner roles descriptions. Consider the following questions:
How are the current management’s and PO’s activities impacted?
What changes, if any, are required for the PO and management role?
What first actions can we take to implement this new setup?
You can use the workshop’s outcome to start defining the Product Owner’s role in large-scale development.
In our last blog, we give an overview of:
Emergent Framework—coaching approach