Division of labor - scaling up the product owner role

There can be only one. That is, there can only be one product owner for a product backlog and a team. You can split teams and have people part time on different teams (even if this is hard) but you must have one person responsible for the product backlog. Mike Cohn says 'one, wringable neck'.

How cute isn't that. But how do you combine a constant presence with developers to be able to make those immediate decisions with being out with the users to know what should be put on the product backlog?

One solution is the division of labor. The product owner takes responsible for stuff that is placed on the product backlog and can be up for developing. Let's say that the product owner is responsible for having stuff on the product backlog which covers about three sprints of development. The work consists of taking responsible for that the stuff describes what the users wants and is enough so that the developers can start building the stuff. Stakeholders should be able to change their mind and change the priority between this stuff without it having a huge effect. The product owner is responsible for the priority in that sense that the most business value can be built for the least cost.

But what qualifies for making it to the product backlog? In my organization, we call that role the product manager. You could say that he pushes in stuff from below. Of all those big chunks of stuff that are "in the future", which do we want to build in the coming quarter. The stories are bigger (sometimes called epics) and they are not exactly the stuff we want to build right now, but they are getting close. You can also say that the product manager is responsible for the road map for the product or the project.

What is important is that the product owner still owns the product backlog - if the epics and stories presented by the product manager isn't of sufficient quality (you don't know what he wants or the business value is unclear), the product owner must say no to taking up the stuff on the product backlog. If you have a role like our product manager, this must be seen as guidance for the product owner. For me to be able to do a good job, I need to know if that big chunk is worth more than that other big chunk. I don't have to think too much about the future, but there is someone who does.

Of course, to make this work, you need clear rules and suitable people. For our organization, the title product manager gave many an idea that this was a role "over" the product owner. That should not be the case, but the opposite is not true either. It's the perspective that differs: a product owner should reside in the present, the product manager should aim for the future.