I’ve long seen two big problems with Product Owners.
First, Product Owners don’t talk to customers as often as they should.
Second, the Product Owner role is frequently set up to be little more than a Backlog Administrator.
Now these two problems aren’t completely unrelated. If you are simply a Backlog Administrator what is the point of talking to customers?
For a while now I’ve taken a broad interpretation of the Product Owner role. Yes, it was introduced by Scrum, and Scrum defines a very powerful Product Owner (which I agree with). But, the Product Owner role has become a general term for “the one who should decides what needs doing next.” Simultaneously the role has become undermined and very few Product Owners seem to have the power to decide much more than the next couple of items.
The Product Owner role seems to make Product Managers and Business Analysts nervous. It shouldn’t, both Product Managers and Business Analysts are types of Product Owner. After all, while the Scrum definition calls for a powerful PO it says little about how the Product Owner knows what they need to know to make decisions. In my book – and yes, I cover this in Art of Agile Product Ownership – that knowledge usually comes from being a Product Manager or Business Analyst.
Recently I’ve been taking talking to my subscriber base and the issue of Product Owner comes up again and again. While nobody thinks Product Owners should be Backlog Administrators most Product Owners in the wild are just that, Backlog Administrators.
In some cases people think it is because of their situation. “In the public sector Product Owners are not honoured…”, “In Germany, Product Owners are not valued”, “In the outsourced development market the contract ties the PO’s hands.”
Actually, its everywhere. Product Ownership are failing everywhere.
In many cases I’ve seen Product Owners who are “battlefield promotions”. A coder is picked to be Product Owner on the grounds that Scrum demands a product owner and they are “The best coder” (or perhaps the worst), “they understand the system”, “its a technology project” or some other weak criteria. Real power continues to be vested elsewhere.
In other cases the Product Owner comes from “the business side” and has little understanding of the technology, how technology teams work or what is expected of them. Consequently the technology group run circles round the Product Owner.
There is a reoccurring tendency for Product Owners to become the Product Dogsbody and pick up the things that nobody else wants to do. Other times the Product Owner is seen as the team leader by those outside the team, however they hold little real sway inside the team (because they are a Dogsbody, Backlog Administrator, coder who is acting up or new to technology).
But the thing is: we can’t blame the Product Owner for any of this. They have been set up to fail by people who don’t understand or respect the Product Owner role, real power is withheld from the PO. Possibly because giving the PO power can seem like reducing ones own power.
As a result the role as an operational necessity (because Scrum or SAFe say there should be one) rather than the Strategic Role which is should be.
Perhaps one mistake I’m making here is: using the term Product Owner. Perhaps it is too connected with Scrum, and in the same way that Scrum has been devalued maybe Product Owner has too.
So, how do we fix this?
I’m not sure. Perhaps we should dump the title Product Owner, maybe everyone should use Product Manager – although that title too is misunderstood. Product Leader could be an option but I’ve also heard complains about that. Product Expert? Product Analyst? Product Person? – would any other name help?
In the past I’ve run a Strategic Product Owner workshop which aims to give POs the skills to operate more strategically. But for this to happen someone at a more senior level has to ask for the workshop and ask POs to be more strategic.
One option, is for Product Owners to meet customers. This will both inform their decision making and give them the legitimacy that comes from customer contact.
A brave PO can simply start thinking and acting more strategically, they can put themselves in the driving seat and start making decisions. While I think this would often work it requires a brave person who is willing to risk their job. (And please, meet some customers before you grab the controls!)
Ultimately the good, knowledgable, powerful, product people are key to achieving agility, failure to give such leaders power puts limits on success.
Subscribe to be the first to hear of new posts
Plus download Continuous Digital for free get occasional discounts and gifts