Scaling Product Owner Role in Scrum : Potential Issues and Workarounds
In the previous post on “Multiple Product Owners or Not“, I analyzed if there is a case for multiple product owners. As per me, there can be grounds and case where this is a necessity. Now let’s see if we did indeed have 02 product owners, what will happen. The potential problems [I have seen these] could be:
- Product owners have power – they influence the product direction. As long as 02 or more product owners agree on the direction, it is fine. However, product owners also influence product execution [user interface, test cases, priority]. These are soft areas and different people can interpret these differently.
- Each product owner is likely to have more appreciation for their own features and their importance, than of the other product owner. If both of them feed a common development team, there would be issues of working together at some stage or the other.
- If you have product owner depending on expertise [horizontal slices than vertical slices], there will be even more potential for disaster striking soon. Let’s take an example. Something which is good from SEO perspective, might not be so great from user interface perspective. If we have 02 product owners, one for SEO and one for user interface, major conflicts will arise.
- Having a whole lot of people influence product direction can mean paralysis in decision making, where almost the bare minimum everyone can agree on, only gets done and anything exciting and challenging, will never even be attempted.
There are some things one can try, to make multiple product owners work together. Let’s look at some possible solutions:
- One way to work around this is to have all the members of the team as stakeholders, but have a Chief Product Owner to have the final responsibility of prioritization. Hence, depending on the size and nature of your product, one might have group of people responsible for grooming the product backlog [design, SEO, user acquisition, interface, development, marketing] but only one person should be responsible for overall prioritization as well as decision making in case of conflict. The problem in this case is to identify such a person. Typically, such a person would be someone with great knowledge about the product, marketing and strategic objectives. This is the typical approach and this takes along specialists in various domains together. Although, this is against the idea of generalists not specialists, it is needed. I personally believe specialists have their place and very important one too. I have benefited as a Product Manager from people advising me on aspects I will overlook or most likely not even know. Specialists give me insight from marketing perspective – Internet Marketing (paid), Internet Marketing (organic), Offline Marketing Channels, User Behavior … one which [A] I won’t ever get time to analyze in detail or [B] would need enormous training to even get started.
- Another approach is to divide the product in multiple sub-products. The Chief Product Owner can divide work to other Product Owners depending on their expertise, experience and importance of the features. This is commonly called feature teams. Organizations and products which spend time on this, reap benefits. We are getting started on this and this is streamlining our processes. There will always be areas where the Chief Product Owner would step in, but mostly delegation and scalability of product owner roles is supported through this model.
Agile Diary, Agile Introduction, Agile Implementation 
June 26, 2009 at 8:24 pm
Nice post (and nice previous post as well). In large organizations I think we should expect that there will be more than one product owner and disecting roles into feature driven development teams/POs is a great place to start.
The PO role is a huge role in Scrum, but as you mentioned, there is nothing related to how to scale it for large projects.
In this scenario it’s even more important to communicate frequently and possibly even run ‘product management’ with Scrum so the multiple PO’s can be more effective with their planning.
July 23, 2009 at 1:57 pm
Thanks for the comment Jason.
What we are trying is to get one central product owner to prioritize features and give dedicated teams to each product owner depending on their features. Some issues occur in this – who takes care of central architecture. But I guess that is scaling team and not scaling PO role.
January 21, 2010 at 12:18 am
great post, I also enjoyed reading the previous one. The recommendations have really help get my brain juices flowing for on an issue that has been crippling one of my SCRUM teams.
We have a new BA on board and I’d like to split the product owner role of this SCRUM so that the team are getting the support they need. The current product owner has been unable to fulfill the PO responsibilities in an efficient manner and as a result the team receive poor stories resulting in many defects coming back from stakeholders.
If you did the split by feature set – would you have both POs doing the sprint review but each will then demo the stories of features they were responsible for during the sprint?
January 21, 2010 at 6:19 am
How big is the development team? One possibility is to split the development team into 2 – each working with one PO. However, once you have 2 teams – you have 2 teams 🙂 So dependencies and overlapping interfaces need to be understood and a mechanism for team interaction needs to be worked out.
Another possibility is for the PO to continue being one with the BA assisting the PO on PO activities – however, the team only discusses the functionality with one PO. This is an ideal situation.
Yet another possibility, the two PO’s agree on the backlog before hand. The team knows who to ask in case of questions/ comments during sprint planning or the sprint. The respective PO approves of the functionality in Sprint Review. This seems to be a path of least conflict right now. However, getting two PO’s to work together can be sometimes a pain. That is why I always, always advocate having just 1 PO [whose job is to prioritize and let the team know whom to coordinate with for each story] as much as possible and expanding her team if she is unable to explain stuff clearly.
January 21, 2010 at 9:55 pm
The team size is seven developers. They work off the same code base, so it would be difficult to split the team. The concept of the PO expanding his/her team could work for us – In the last two sprints, to assist the current PO, I had to get in two other Analysts from our department to help get the sprint to a healthy state. Each Analyst was allocated with specific stories to own and the team had clear understanding of which person they needed to go to. This got the sprint back to a healthy state for two sprints, but these Analysts were assisting during their quiet period and would not be available to do normally.
January 21, 2010 at 3:07 pm
@Rae I would be wary of thinking the BA will fix what is currently broken. If the problem the PO is having relates to getting stakeholder/customer face time, the BA won’t likely help.
We have a PO (30 – 50% of her time) and a BA (100% dedicated to the team) so the PO uses pretty much all her time to collaborate with customers/stakeholders and our BA acts as a proxy. Our PO is able to attend the planning and demos but isn’t around every day. The BA sits with the team and they work together to make sure stories are ready.
I would assume this would be the same scenario you’re mentioning, I think it’s just the phrasing of your reply that worried me.
Even if the stories are poor, that shouldn’t be a barrier to the collaboration that is supposed to happen for those stories.
January 21, 2010 at 9:36 pm
Thanks Jason. My concern with the current PO is that he is reluctant to collaborate with the stakeholders. The other day he told me he thought it was a waste of time…He is a BA fulfilling the PO role. I’ve asked the stakeholders directly how SCRUM is working out for them and generally the like it but are not reaping the benefits of visibility yet because the PO is not involving them much. We are in Sprint 10.
As a BA myself I feel troubled by a BA expressing that they see talking to stakeholders as a waste of time.
I was thinking that perhaps if I shared the PO activities amongst the two BAs – they’d each be a PO for the one team (Team of seven developers), but the split would be by feature set (as opposed to a split). The two POs could work closely together to get stories ready and perhaps the current BA will see the benefits of involving stakeholders by learning from the new BA. The team would get improved quality of stories and support.
However perhaps a better model would be as you have: one becomes PO who collaborates with stakeholders and the other other is the proxy working closer with the team day to day. The PO and proxy work closely together to ensure goal alignment and agreement of prioritization.
January 21, 2010 at 5:10 pm
Wow Rae – thanks for bringing Jason back 🙂 I think Jason also emphasizes the third solution I suggested.
However, please take all of this as starting points for discussion. If you are the one facilitating processes, talk to as many people as you can, gain more understanding and information and try the smallest increments every sprint.