The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?
The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians.
Many Kings
The development team want to build but are confused about what to build. They are faced by a sea of product owners in the business with competing agendas. What to do?
For a start be clear on the difference between the product owner and a stakeholder. A stakeholder is impacted by the product but doesn’t own it.
In product ownership Roman Pichler is right that the Highlander principle definitely applies. In other words, there can only be one Product Owner. One product means one Product Owner.
Everybody else is a stakeholder. The stakeholders can wheedle, lobby, pressure, and perhaps bully the Product Owner to get their own agenda up the priority list, but they don’t make the decisions directly.
The stakeholders need to be managed but not by the development team. The Product Owner has to manage the stakeholders. Talk through, challenge, evaluate, sometimes integrate their ideas into the evolving product roadmap.
So if the business sends you more than one candidate product owner, then get them to choose one. There is a good chance that some of these candidates might just fade back into the organisational background. The candidates that remain interested in the product become stakeholders.
Pretender to the Throne
Even in the technical domain there are rivals for product ownership. Here are a few alternative roles I’ve seen vying for product ownership:
- User Experience Designer
- Business Analyst
- Technical Architect
I’ve seen user experience (UX) designers attempt to take control of products. Usually new ones. This manifests in a long upfront UX process before anybody, including the business let alone developers, become involved. It is always a disaster. You’ll get pretty pictures that are unbuildable. Guaranteed. I’ve seen this a few times and, sadly for the user experience people, the user experience always had to be completely redone in a feasible mode factoring in the real business requirements.
A good business analyst (BA) can really help the product owner. They can provide a perspective that a business person might lack. The danger comes when the business analyst starts guiding the product owner rather than interpreting and translating. Even worse they start making decisions and communicating these to the development team without reference to the product owner at all. If you see this happening then nudge the BA back to guiding.
The most surprising for me was seeing a Technical Architect (TA) drop requirements into a programme, for example, “the user wants to see creative visualisations of the data”. The TA’s agenda was to get interesting technical products included in the product – in this case data visualisation tools. Unfortunately there was no clear business driver for these tools, the users didn’t want or need creative visualisations. Clearly this kind of thing has to be closed down. A TA is welcome to sponsor a feasibility study or pilot on innovative technology. But not as part of one of my programmes.
People in these technical roles are not the product owner. They might inform requirements, inform the product direction, inform the solution, but that is all they do. The hard business decisions should be made by the business representative. Or, put another way, these rivals are NOT the one – in a Highlander sense.
So if you see other roles encroaching on the Product Owner’s turf then help the Product Owner assert their authority.
Chief and Indians
Large teams need some structure to the product responsibility. A product ownership hierarchy is useful for large product development teams and for programmes. Unlike the scenarios I outlined above this is a good idea.
In a product development organisation products are often grouped into related families. Each product has a Product Manager as Product Owner but the vision for the group as a whole is shaped by the Product Group Manager (a title I borrowed from Marty Cagan of the Silicon Valley Product Group).
Similarly in a programme context one person should have ultimate responsibility for the product as a whole even if there are other product owners for the individual projects or workstreams within the programme. I call this person a Programme Product Owner.
Some Agilists don’t like the idea of a hierarchy on principle (Johanna Rothman discusses this in her Programs Titles and Business Value). Personally I think in this situation the hierarchy eases decision making so is a good thing.
Summary
The last thing you want is a product designed by a committee. So remember there can only be one! Product Owner that is.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
Steve,
Thanks for the great post. For the most part I agree with you but where I worry is the stress of “only one”. To me only one is for a point of reference and consistency for the team which is good, but not from the point of view that they are the sole holder of what is right which is bad.
How do you counteract the lone wolf product owners?
Hi Mike.
“Lone wolf” from whose perspective? We’ve both seen product owners who ignore the needs of other product teams and solely pursues their own agenda. That suggests “lone wolf”. But what if that PO has a mandate from their management to do exactly that? Is that “lone wolf” or good organisational player?
Same person without management mandate, well, they need to be gently encouraged to get a wider perspective.
I work on a team that developers the business services for several products. We have one BA for the mobile application, and another one for Loans.
How can we have a single product owner if we are developing services for multiple products? For now I consider each BA the product owner of his product and I help with the backlog & planning to make sure we can meet the needs of both. Who’s the unique product owner here? 🙂
Multiple independent products don’t need a single product owner. You’d only need a single, chief, product owner if it was the same product servicing different needs. They could, for example, make a call on which product line had priority in the event of a conflict on resources or direction.