Product Owner by Proxy

Last time around we introduced the idea of context and coordination. Context gives us mission and purpose… it tells us what to do. Coordination gives us a sense of timing and sequence… it tells us the most important thing to work on next.

Our agile Product Owner is responsible for establishing context and coordination for the team.

As products grow in size, as we add more stakeholders into the mix, the context of the solution grows, as does the need to coordinate across a broader cross-section of the organization. Scaling the Product Owner role is the fundamental problem we are trying to solve when we talk about scaling agile.

Balancing the Needs of Multiple Stakeholders

Once we get larger than a start-up company or a departmental IT initiative, the Product Owner becomes responsible, not just for deciding what to build, but for assessing the requirements of all the interested parties… balancing their often competing objectives… and deciding what goes in the product.

The Product Owner might have ultimate say, but they are no longer the only person with influence on the direction of the product. Other folks get to weigh in.

The Product Owner abstracting a cloud of interested stakeholders for the team.

To get a visual on the type of organization I am talking about, you might consider our small start-up software shop from the last post. Their product has taken off and the stakeholder list has grown to include a group of investors, a sales and marketing team, a training and support organization, and a more diverse user community. Lots more people have an opinion on what direction we take the product… some of them are spending money to make it happen.

The Product Owner balancing the competing needs of several stakeholder groups and negotiating the optimal feature set. This creates more shared accountability and dilutes the Single Wringable Neck model.

Faced with increasing external complexity, the Product Owner has to spend more time managing the expectations of the customers and the business. Because the Product Owner is trying to understand and manage the demands of a more diverse set of stakeholders, they often lose their ability to work closely with the team.

When this happens, the team loses context… and the team starts coordinating their work based on their best guess about what is important. The Product Owner is no longer driving the development process… they have deferred that responsibility to the team. This is probably one of the worst places for an agile team to find itself.

The relationship between the Product Owner and the Team has broken. We need some way to repair the situation and keep the team building the right software. The stakeholders are going to continue to put demands on the Product Owner’s time and attention and their availability is going to continue to be at risk.

Product Owner By Proxy

Often the solution is to insert a Business Analyst, a Project Manager, or even a senior developer as the Product Owner. This division of labor becomes necessary because the job has gotten too big for a single person to perform the role. The real Product Owner focuses on customers (and other stakeholders) while the day to day interactions with the team are delegated to the proxy.

This diagram show the BA as the proxy Product Owner for the team. The Product Owner becomes only a part time participants on the team and the BA fills the role of providing context and coordination for the team

As we mentioned in the last post, and alluded to here… Product Owner proxies can keep the team moving but will ultimately degrade the accountability the Product Owner has for the emerging solution and degrade the quality of the information available to the team.

Unless the proxy is truly empowered to make binding decisions on behalf of the Product Owner, I am not a big fan of this approach. More often than not, the proxy is just NOT the Single Wringable Neck. You can hold them accountable, but unless they get to really decide what happens with the product, accountability is going to break down… they will defer to the real owner every time.

Someone on the team has to be empowered to set the context and must be there to coordinate for the team… without that, getting DONE gets nearly impossible. How many teams have a backlog of completed features waiting for the Product Owner to accept them. Believe me, it happens… and it is a real problem for many teams.

We need a better solution than absolute insistence on a single Product Owner model… or even a proxy. Next post we’ll look a simple team based Product Ownership approach.