Originally published July 2017, this is when we began to argue that many roles are rolled into the product owner. This is also the first time we have distinguished between the backlog ownership role and the solution owner role.
The product owner role is a manifestation of the Agile manifesto’s values, particularly – “Customer interaction over contract negotiations” and “Individuals and Interactions over processes and tools.” The product owner provides delay-busting leadership and clarity for the team. The conversations with the product owner facilitated by user stories align the product owner and the team on a shared vision. Rather than slow the development cycle and suppress learning through comprehensive documentation and change control boards, the product owner directly interacts with the team to learn what is really needed. From that learning, the team and product owner refine and reprioritize the backlog to maximize value. The product owner is a value manager, exploiting fast learning cycles to re-prioritize and revamp the backlog. Without an engaged product owner, there is only, at best, incremental development. There is no agility.
One of the most common bad smells in many agile environments is the disengaged or unavailable product owner. However, there is a more insidious variant of this problem, one that can create the appearance of an engaged product owner, but in reality, the product owner is disinterested in and disengaged from what the majority of the work team is responsible for.
In this variant of the disengaged product owner, the supposed PO is responsible for a specific project – or even a set of projects – that the team is working on. The problem is the team has other work in their backlog besides the PO’s pet projects. This may be more than the usual ongoing maintenance, support, defect fixes, and the inevitable shoulder taps a development team must cope with, but also possibly work on other projects that are not in their PO’s portfolio. The team is effectively left to fend for themselves by prioritizing and managing this “dark” or “off-balance sheet” work.
Dark Matter is theorized as matter in our universe that is invisible but still has a significant gravitational effect. Just like dark matter, “dark work” is the work that is invisible but still consumes significant effort from the team. The problem with this dark work is because it is invisible, it is not managed. But like dark matter, its effect on the team is significant, even destructive. It is critical that all teamwork is visible because if it is not visible, then value cannot be managed. Very simply, if you are the product owner, then you are responsible for all work in the team’s backlog.
Bad smells that are symptoms of this problem include team members talking about their “day jobs” or a team with multiple backlogs. One backlog is well managed by the PO, and the other is managed ad hoc by individuals on the team. This blindness lets us live for a while in a fool’s paradise. The product owner is not forced to make hard choices between their pet project and all the other work the team needs to do. And then we wonder why so many agile teams have lousy SAY/DO metrics.
Personally, I think the term “product owner” is misleading because it implies responsibility for a specific product. In the modern agile context, a product may only be a subset of the team’s overall work. The term product owner is a carryover from the early days of agile methodologies when the exemplar teams in the early textbooks were focused on building a single product, and the product owner represented the beginning and end of the value stream. Today, most agile teams work in complex multi-system environments, and all of that work from multiple sources comes to the team, and all of that work should be in one team backlog. The agile development team is one step in the value stream. So, our model of the agile development team also needs to be updated.
I think we need to start thinking of the product owner as a “backlog owner” who is responsible for everything the team works on. Those who own a specific initiative or product are not “product” owners unless they can also take on the backlog owner role. The Scaled Agile Framework actually explicitly calls out these different roles, distinguishing between an “epic owner” role and a product owner role. While the same person may fulfill both roles, it is clearly stated the interests of the EO may diverge from the PO role.
So be honest with yourself: are you really the product owner? Are you really interested and capable of working with the team to prioritize all the work in the backlog? You don’t have deep technical knowledge of everything in the backlog. The team can advise you and make recommendations. While the buck does stop with you, product ownership is still a negotiation, but it’s a negotiation about all the work, not just the bit you are interested in.