Reducing the Load on the Product Owner
Product Owners have it tough. They need to spend time and energy working to understand the needs of customers and users. They need to work with the development team to prioritize and decompose Product Backlog Items into small user stories with acceptance criteria. Finally, they need to work with key stakeholders within the business to get budget, garner support for their efforts, and align on how the work of their scrum team aligns with the larger vision and strategy of the organization. Not only does this create a tremendous amount of stress for the Product Owner, but it leaves no slack time. Slack is a key ingredient for creativity and growth, and without that, innovation, value delivery, and personal well being suffer.
At a recent session, I along with my Agile For All colleagues Peter Saddington and Richard Lawrence helped a group to use Lean Thinking, the Theory of Constraints, and the Product Owner Responsibility Matrix to reduce the load on their product owners. Here is our approach.
Exploit the Constraint
The Theory Of Constraints recommends the use of Five Focusing Steps to optimize any system:
While there are some standard steps to doing number 1: Identify the Constraint, in many teams using Scrum, the Product Owner is clearly the constraint, so we will jump right to step 2: Exploit the Constraint.
While the term exploit usually has a negative connotation when referring to humans, in this case, “Exploiting the Constraint” simply means making it as effective as possible, since it is the limiting factor on the speed of the entire system. In many cases, there are ways to reduce the amount of time required by the Product Owner for certain responsibilities. Any time we can free up from the Product Owner immediately impacts their ability to work on more important things, immediately impacting the speed and effectiveness of the entire system.
Enter the Matrix
No, not that Matrix.
The Product Owner Responsibility Matrix is a thinking tool for helping a Product Owner to focus on only the highest value items on their plate. We can look at every activity that is a current responsibility for a Product Owner and assign it to one of five categories:
- Do Less – an activity that is not adding value in the organization. If so, work on doing it less or not at all.
- Delegate Completely – an activity that can be safely delegated to anyone else in the organization. They are by definition not the constraint.
- Delegate and Mentor – an activity that can be delegated but that would still benefit from some mentoring by the Product Owner. This reduces the amount of time spent by the Product Owner as well as growing expertise in others.
- Collaborate – an activity that would achieve a higher quality outcome by involving the team or stakeholders. While the initial time spent in collaboration might not be the same or higher, the improved result means there will be less rework. It is likely that those collaborating will also be more enrolled in the result, reducing time spent by theProduct Owner in explaining the what and why of a decision.
- Own – an activity that really must be done by the Product Owner.
Using the Product Owner Responsibility Matrix
To use the matrix, we recommend a facilitated activity involving theProduct Owner as well as team members and possibly other key stakeholders in the organization.
Step One: Brainstorm Current Responsibilities
We find it is helpful to use a framework for brainstorming responsibilities. One such framework is to look at the typical three key stakeholders with whom a Product Owner interacts: Users/Customers, The Business, and The Team. Label three flip chart pages with one of the three stakeholders each, and put them on the wall in three corners of the room. Ask people to stand by the flip chart that they know the most about, and have them use sticky notes to brainstorm all of the activities that the Product Owner currently performs with that stakeholder group. Have them write one activity on each sticky note. For example, on the “Team” poster, you may see sticky notes labeled “Write User Stories”, “Define Acceptance Tests”, and “Participate in the Scrum Ceremonies”, among several others.
Once the activities are all on sticky notes, have the team group stickies on their poster that seem related, and then label each group with a category name, creating a list of categories on the left hand side of the poster. At this point, have each group share the categories and the stickies in each category and ask for feedback from the other two groups about anything they may have overlooked.
Step Two: Add the Matrix
On the right hand side of the poster, draw a grid with five columns and label them 1,2,3,4, and 5, which correspond to the matrix options (1:Do Less through 5:Own). Make the columns about the width of one sticky note. Have the groups move the sticky notes from each category over to one of the five columns. Here is a sample of what the Business poster looked like in a recent session, about half way through the activity:
Step 3: Prioritize the Stickies
At this point, you should have a good list of activities that can be offloaded from the Product Owner in some way. Create a backlog of the ones that involve a change, and prioritize them based on the Product Owner’s estimate of how much time it would save them. You may also include how difficult it would be to make the change in the prioritization discussion, as some changes may require some work to put in to place. Stickies in the “Do Less” column may especially require some discussions with others in the organization to get buy in.
Step 4: Work on your Backlog!
Now you’ve got a nice backlog of items that you can start working down to free up time for your Product Owner. Each item you can complete will help you exploit the constraint, ensuring that the Product Owner is focusing their time only on the most critical, value add work that only they can do.
If you are interested in talking with us to learn more about this technique and other ways to help Product Owners be their most awesome selves, please contact us, sign up from an upcoming Certified Scrum Product Owner course.
You mention the Product Owner Responsibility Matrix – is there actually a generic matrix or is it specific to each project?
We use a standard matrix framework, but the specific responsibilities of the Product Owner vary widely between different organizations and projects. Some Product Owners are also Product Managers and have quite a bit of responsibility in sales, marketing, and internal lobbying. Others may be solely team focused and have little interaction with customers. Because of this variation, any generic matrix would be fairly useless to most organizations. When we use the matrix, we start by brainstorming all of the responsibilities of Product Owners within a specific org, sorting them into Team, User/Customer, and Business categories, then apply the matrix from there.
For the reasons above we’ve implemented Scrum but added a Product Manager role to handle the business (i.e. stakeholder management) elements. The Product Owner is accountable for breaking down features into user stories & tasks.
In an ideal world we’d just have a Product Owner. However, that wouldn’t work in our large organisation.