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 the 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 creates the appearance of an engaged product owner but in reality the product owner is dis-interested in and disengaged from the majority of the work team is responsible for.
In this variant of the dis-engaged product owner, the supposed PO is responsible for a specific project – or even a set of projects – that the team is works 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 on-going 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 on prioritizing and managing this “dark” or “off balance sheet” work.
i uses the term dark work as a metaphor for matter that is invisible but has significant affect. The problem with this dark work is that it is invisible, and therefore not managed. But like dark matter its effect on the team is significant, even destructive. Or as my other metaphor “off balance sheet” work implies, dangerous liabilities that is not being accounted for. It is critical that all team work is visible because if it is not visible then value cannot be managed. Very simple, 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 that is well managed by the PO and the other that is managed ad hoc by individuals of the team. This blindness lets us live for a while in fool’s paradise. For the product owner they are not forced to make hard choices between their pet project and all the other work the team needs to do to keep the lights on. 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 teams 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 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 this 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 states 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.