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.
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.
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.