The Role of Product Owner in a Multi-Team Environment

About a week ago, one of my friends asked me for the following advice: she is a ScrumMaster in a multi-team environment and seems to be having problems with some of her Product Owners. The problem is that they seem busy with other work (like talking to clients, focusing on marketing and so on) rather than being available to the teams all the time. And the question was: how should we solve this?

So, I did a little digging around and found out, that this problem is rather common, and not only in a multi-team setup. Here, I firstly need to clarify what I mean by a multi-team setup. I mean that we have one compact product (that by itself we provide to our customers), but because of the size of the product, the complexity and the demand for new features, we need multiple teams to work on the product at any given time.

When we know this, I would like to split the problem into separate smaller problems (that can be a good technique — if faced with a large problem, try splitting it in smaller ones, where you are more likely to find a solution).

Problems with Product Owners themselves (not related to multi-team environment)

The Product Owner role is crucial to any agile development. Yet, many times, we are faced with various problems concerning this role. The most common ones are the following:

• Product Owner without sufficient power. This happens a lot — you have a PO, but the PO has to check with multiple other people before she makes any decision. This may work in a small environment (but why would a PO ask someone to make decisions in such an environment, what would be the added value of having a PO?), but definitely cannot work when you have something a little bigger. The main two problems caused having a PO without the necessary power are a) delays in decision making and b) no real product ownership. Solving this may be quite complicated and will depend on the organization you work in. Sometimes, it may take just educating the PO and persuading her to take the ownership. Other times, this may mean working with various managers, explaining them the principles of agile and the necessity to have a PO who has both the responsibility to decide about the product and the time to do so and cooperate with the rest of the team. This may effectively mean that there will be a change in who the PO actually is (for some organizations it is much more simple to shift roles to different people instead of shifting the power).
• Technical Product Owner. Perhaps your PO has a deep technical knowledge of your product, she knows how it works, how it is integrated and so on. And as a result of that, your PO writes really detailed user stories or (even worse) proposes the technical solution. Problem with this is not in the fact PO is trying to help the team (help should be always welcome!), but with the fact that the role of PO is about something different and the PO should have focus on business vision and roadmap of the product, not on the technical details. By focusing on them, the PO is neglecting important part of her work. Solution to this usually requires talking with the PO, explaining the role to her (and the value in the things PO does). In the end this may lead to the PO realizing he wants to do something different and leave you searching for someone else to become the PO.
• Proxied Product Owner. This is similar to the first one, but with one difference — the PO without power formally is the PO, he just cannot fulfill the role. The proxy is basically a decoy and everybody knows that. When faced with a PO proxy, I always tend to be suspicious, as usually this is a technique put in place by some members of the agile / scrum community (I do not want to offend anyone) to overcome a different problem with the PO instead of solving it directly. Let’s face it — the value added by having a proxy PO is none. This person has no responsibility, no decision making power and he is just translating information with more or less noise added. So, my recommendation when faced with a proxy PO is: get rid of it as quick as you can. Firstly, things will definitely not get any worse by doing so. Second, you may find where the real problem is and then you can solve that.
• Busy Product Owner. Sometimes, your PO has just too much work. So much that he starts to neglect the team in one respect or another. The PO may be busy communicating with clients, conducting market surveys and other things, leaving him little time to work with the team. Here, I must firstly stress that i find working with clients, conducting market surveys and similar extremely important. However, you have to remind your PO that he is not necessarily the one to do all the work. The best and simplest solution would be for the PO to delegate some of the work to teams. This of course has the prerequisite that the teams do have the capability to perform other kinds of work apart from delivering software. If they do not, they can learn that. The other option would be to have someone from outside the team help the product owner. This may be business analysts, market research experts and others. Personally, I would recommend you try to engage the teams as much as possible and leave only the really specialized stuff to outside experts.

Problems with the multi-team aspect of work

Now, let’s concentrate on a Product Owner in a multi-team environment. As I have explained above, by multi-team I mean having one PO on a product with multiple development teams. Now you may wonder why should you have one PO for multiple teams and not a PO for each team and one “chief” PO coordinating them. The answer is simple: you do not want to add that many people and another coordination layer unless you really have to (and trust me, for a couple of teams you really do not need to to that, otherwise your POs will get bored and start doing some weird things).

• Multiple Product Owners. You have one product. This one product has one Product Backlog. And it is imperative that one person is responsible for it. If there are additional stakeholder, that is fine. But the ultimate responsibility must be on one PO. Otherwise, you will get conflicting priorities (or no priorities at all), delays in decision making and communication and synchronization overhead. You may think that one PO cannot “satisfy” multiple teams. And you would be wrong. If you have the PO focus mainly on business aspects of the delivery and let your teams to clarify details directly with customers or their representatives (this might mean overcoming the myth that developers and customers should never talk directly to each other — more about that on my coming post on sabotage), the PO can work with multiple teams.
• Product Owner buried in details. When your PO has multiple teams, he cannot dig into details too much. Surely, there are other intelligent people in the team who are able to develop what the PO writes in user stories and then just confirm that with the PO. When you try this approach, I guarantee you that you will be surprised by how many people would like to help the PO and clarify some of the details themselves. So, try not to bury your PO in details that you can reasonably either decide within the team or that you can ask your customers about directly.

Problems somewhere else in the organization

• Product Owner managed by superiors. In large organizations, you may sometimes have a PO who is just a puppet in the hands of her superiors. Please note that this is very different from having a PO without the power, because in this case, the PO has the power and authority. Only sometimes the decision the PO made is overruled by her superiors. This usually subsequently leads to major rework and wasted money and energy of everyone on the team. Solution to this problem is working with superiors doing this and explaining the principles of agile and the necessity of having a strong and empowered PO. In the end, this may lead to shifting the PO responsibilities to someone higher in the hierarchy. Just be very clear and specify that being a PO is a full-time job, not something a manager with dozens of other responsibilities can do during his lunch breaks.
• Product Owner without control. Or a “formal Product Owner”. This happens when you have a dedicated PO role, but the processes you have simply bypass this role. The PO in this case sometimes even does not know what is happening to her product, because the requirements are coming directly to the teams from various other sources. Fixing this theoretically is quite simple — introduce one project backlog, make the PO responsible for the backlog and do not allow teams to work on anything that is not a part of the backlog. Practically, it may mean changing some of the processes and including the PO as the ultimate decision maker.
• Product Owner without product. This happens when you have a PO role, but no underlying product. You may even have a “project Product Owner” (I would call that a contradiction in terms). Be aware that having a PO, or, in a broader sense, doing a product development, without having a clue what your product is is a really bad idea. So, when you are in this situation, start by defining what your product is. There are several techniques that may help you in doing so, which I will not cover here — just google and you will find. Once you have a product, the product ownership will start making sense and you will have a much better picture of who your customers and stakeholders are.

I have definitely not covered all issues you may encounter with Product Owners. The above ones are merely the ones I have seen most frequently. If you have others (ideally with how they may be overcome), please share them with me!