Project OwnerAlthough agile has helped countless businesses bring new functionality to customers quickly and cost-effectively, many organizations are stumbling over an important agile concept: the role of the agile product owner. The consequences can be costly.

Setting the stage:

The product owner is a business representative who works closely with the agile development team to ensure that the team delivers functionality that the business and its customers need. Functionality is delivered iteratively, with the business making decisions and providing feedback to developers as work proceeds. Detail and decisions are frequently delivered on-demand during the development cycle through conversation with and feedback from the product owner.

When discussing product owners, we should keep in mind that this job title is not unique to the agile world, so clear definition is needed to avoid misalignment and misunderstanding of the role and function of the product owner. For example, in some businesses product owner refers to a senior leader who has responsibility for a particular line of business. A senior executive with strategic responsibilities isn't likely to have the bandwidth day-to-day to work closely with an agile development team. As a result, developers don't get the information they need, when they need it. Delivery dates slip, and developers begin to improvise, delivering functionality based on guesswork rather than on a clear understanding of business needs.

The level and experience of the best candidate product owners vary from business to business. However, once you have found the sweet spot, the next hurdle becomes scaling. Many of the businesses I work with need to increase the depth of talent in their product owner community as their organization matures. Out of the gate, very few have enough strong product owners to supply all of their development teams with the ongoing support they need. This need typically leads to reliance upon proxies or delegates.

What is a proxy product owner?

Scaling business expertise takes time. While that is happening, it is common to see Product Owners splitting time across too many teams to be effective, or delegating their responsibilities to junior team members in an attempt to plug the holes. Most of the time this second example is what we think of with the term "Proxy Product Owner." Just Google that phrase and you'll find plenty of vitriol on the topic. In most cases, the Proxy is a junior employee who runs back and forth between the agile team and a leader or committee, seeking answers to developers' questions and getting approval of decisions about the product.

There are more permutations of the proxy idea. A 2013 article by noted that "proxying can take several forms." There may be cases, for example, in which various stakeholders within the organization consider themselves the rightful product owner. A proxy might be appointed to act on the stakeholders' behalf or to arbitrate differences among them. In other cases, a supplier working with an organization might provide a proxy to represent the client's interests on the development team.

How can we reform this idea?

Obviously, a product owner who lacks business expertise and decision-making authority causes delays and other problems for the team and the product. As a result, the idea has deservedly taken a beating. But a true proxy, by definition, is someone with the authority and power to make decisions on behalf of another; in this case, the business. And that is precisely what agile teams need. This doesn't mean that the organization will need to create dozens of clones of its best and brightest executives. Our objective is to scale the organization's business expertise in a practical and reasonable manner in order to apply it across multiple teams. As your business scales up, the idea of having key leaders embedded in the delivery teams starts to break down. Delegation is a natural part of the scaling process, and is necessary if the teams are to get the input they need within the shorter agile development timelines.

Whether the term product owner or proxy product owner is used, it is crucial that the person representing the business has the time and expertise to provide the agile team with essential business information when needed; the authority and autonomy to make timely decisions during sprints; and the standing to build consensus and resolve disputes among stakeholders. One piece of advice I give my clients is to give their product owner autonomy to make decisions within the duration of a sprint. Product owners are rarely truly autonomous, and spend a significant amount of time aligning multiple stakeholders. However, once the intent is committed, we need our business representative to provide clarification, guidance, and timely decisions. Limiting the field of trust to the current sprint can allow a more rapid transition of our business team members into product owner roles.

Given the importance of this role and the confusion sometimes surrounding it, maybe it's time to coin a new term. One that won't lead businesses to appoint senior executives to integrated team level roles, and will help us target and grow the talent we need to scale. Regardless of who is in the product owner role, my advice is to always empower your business representative within a realistic set of guardrails.