A big thanks to Chris Lukassen for help with this blog.
One of the biggest challenges that Product Owners face may be one of the hardest to overcome. I have talked to many different Product Owners over the last few years. And many of these Product Owners either had different job titles or had very different experiences. I spoke to some Product Owners: executives, business analysts, project managers, and product managers. Many of these Product Owners expressed the challenges of their role, not in how they execute the day-to-day work but in how they fit into the existing organization. These challenges come from:
- Where work comes from? Does work come from the customer, a program, an enterprise backlog, or a project/portfolio organization? How goals come to the Product Owner changes how the Product Owner operates and their relationship with the user of their work.
- To whom they report progress, problems, and success. Reporting affects autonomy and focus. Managers will have different agendas and abilities to resolve issues and impediments.
- The ‘Productness’ of the Organization. Does the organization group its capabilities into products? Do they expect Product Owners and teams to operate with a focus on ownership or execution? Are the incentives connected to the Product? Depending on how the organization partitions the work affects how the Product Owner operates.
In other words, how the organization defines the accountabilities and organizes around their products or work. It is possible to take the primary two dimensions affecting how Product Owners operate and create a diagram. The diagram uses two dimensions.
The X axis describes how product-oriented the organization is. In broad terms, this ranges from project to product oriented. When we say product, this can also mean a service. The critical point is whether the organization seems focused on delivering value in a repeatable way using the same concept in repetition rather than creating one-offs that need customization for each situation.
The Y axis describes how much control the Product Owner has over deciding what the team works on. On one end of the line is a Scrum Team as an order taker; the other describes an empowered team making all the decisions. I have added some examples of types of business these Product Owners typically work within. Of course, they are examples, and there are many exceptions. However, the examples can provide some context for your situation.
An important point is that being in a different location on this diagram is not wrong, Product Owners can excel in each part of the diagram, so let’s explore some solutions to the challenges that Product Owners face. Let’s go back to what a Product Owner is defined as.
The Product Owner accountability is described in the 2020 Scrum Guide as follows.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
But what value ‘is’ depends on the situation and context; however, a Product Owner always strives to maximize it. Sometimes this means prioritizing direct customer value; sometimes, it is all about risk (or anti-value) and meeting those needs. It may be long-term value described by strategy or immediate value defined in defects.
So, as a Product Owner, you can remember that:
It's all about value, not work.
Value is very contextual. However, it is essential that the Product Owner focuses on the idea of value and not work. That can be difficult in a large project or program because the “stuff” presented to the team may be without context. In those situations, the Product Owner should:
- Build an overall picture of how the work being presented to the team fits into a broader picture. Sometimes it is all about reverse engineering, a strategic view from the tactical requirements. Sometimes this involves spending time with other Product Owners and stakeholders. Ultimately this context-setting document does not have to be perfect, but it should provide enough information to the Scrum Team to help them align with the work.
- Reframe and refactor backlog items to present value. If the items presented to the team are very task-oriented or lack outcomes, the Product Owner should spend time re-engineering the backlog so they describe the outcomes being sought. This might feel like wasted work; after all, the program presented the team with what they wanted from the team. However, reviewing and changing those items to be outcome-centric can allow the team to be creative and imaginative in their solution. It is also very motivational to have this context. Imagine being told to walk these next few steps rather than being told your objective is to get to the top of this hill because it provides a great view.
- Look to build success criteria and measures. In the same way that Agile should never be the objective, a collection of Product Backlog Items should never be the focus; it should be the outcomes they provide. Ideally, we can build OKRs, measures or success criteria that speak to the results the PBI strives towards.
Dependencies are my life.
In huge project-oriented environments, dependencies often overwhelm the team. In those situations, the order of the work and the success of the work are influenced by another team or other collection of work. Product Owners in these situations feel a bit like a person at the fairground playing ‘whack a mole.’ In these situations, it is essential to:
- Create transparency across the web of dependencies. They say a picture is worth a thousand words, and visualizing cross-team dependencies is worth 1000 hours of work (;-)). Surprises and unknown dependencies often get in the way of progress. Also, each team often does not know who depends on their work. By making these dependencies visible, it is possible to change how the teams work to minimize impact or improve flow.
- Frequently inspect the sum of parts or integrated products or subsystems The best way to ensure that problems are visible is to integrate everything frequently. In the case of software, that means continuous integration of the whole system for other products, which means simulation and review of the whole and progress in each area. By frequently bringing everything together and all the teams involved seeing the whole thing, it is possible to see problems when they are small rather than later. The intent is not necessarily to release the integrated product but to see if the increments being produced by the teams fit together and what is missing or problematic.
- Strive to reduce dependencies by restructuring the teams or building closer alliances. The organizational structure is defined for many large organizations and can never change. Even cross-functional teams that pull from these structures do not have any flexibility to change based on learning. Challenge the status quo and change teams when many dependencies could be resolved much quicker inside the boundary of one team.
I am a force for change.
Product Owners are uniquely positioned to drive change through an organization by demonstrating the effect of focus on the organization's bottom line. Successful products help the organization grow, become more resilient to market or technological changes, reduce risk or explore new value. Results are a powerful argument to encourage increased investment in the product organization or ‘Productness.’
More ‘Productness’ often comes down to reducing the complexity of the solutions for customers. Customers can be internal or external and directly or indirectly pay for the product's services. For many organizations, complexity is the ultimate problem, as customers and the organization wrestle with understanding and changing their products.
As a Product Owner, you don’t need to drive this change alone. You can partner with the Scrum Master. The Scrum Master helps organizations understand the power of empiricism, increased transparency, and how incremental discovery and value delivery increase the organization's resilience to change; the Product Owner can demonstrate a practical application of this and the effect on ROI.
What does it all mean?
Scrum is a simple idea. You align a team with customers, provide direction and support, and make good things happen. Product Ownership ensures that the Scrum Team focuses on the most valuable things. The Product Backlog provides transparency. But that simple reality is rare as Scrum is used in increasingly complex environments with multiple teams, multiple products, and existing legacy. The simplicity of a single team aligned with a customer is a far cry in many of those situations. But that does not mean that Product Owners should not continue their quest to deliver the most possible value. However, it does mean they will do things differently depending on their situation.