The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted here.
I worked with a team last week that had three business people who each established the team's priorities. This caused a number of problems for the team because they had no clear guidance on who to listen to. The three business people each reported to the same vice president who had given them the vague guidance to not overload the team with their own priorities and to work out any conflicts among themselves.
This worked well enough--except when it didn't.
When there were conflicts the team was left in the unenviable position of having to resolve prioritization conflicts among the three business people. This was impossible. Resolving business conflicts like this required a deep business knowledge the developers didn't possess. Apparently the three business people didn't possess an adequate shared knowledge or they could have gotten beyond their differences of opinion and presented a shared set of priorities to the team.
In situations like this, I find a common approach is to push the problem down to the team. Sometimes that's right--Scrum teams are meant to be empowered and self-organizing, after all. But in cases of conflict I find it more appropriate to push the problems up the organization. In this case, rather than pushing the problems down to the team, the problem should have been pushed up the organization to the vice president to whom the three business people reported.
Because this was a Scrum project on which I was consulting, the business people were each called "product owner." And this made things very hard for the team. Team members knew they were to work on things prioritized by the product owner. But they didn't know what to do when they had three product owners who occasionally differed on priorities.
Conceptually, there is a very simple solution: Each Scrum team should have one person they recognize as their product owner. Practically, though, this can be hard to put in practice because companies often want a team to listen to multiple "product owners." To solve the problem, the organization needs to make the hard decision of classifying one of the individuals as the product owner. This makes the others (the former product owners) stakeholders.
The newly singled out product owner does not get enforce his or her will across the product. There are, of course, other stakeholders who must be satisfied. However, satisfying those stakeholders by prioritizing the proper mix of features will no longer be the responsibility of the team. The problem is pushed up the organization to the one rightful product owner.