Product Owner Proxies – A Primer

For the first blog post on the site, I thought I would tackle a topic fraught with danger – that of the Product Owner Proxy. Sometimes the business is unwilling or unable to provide a Product Owner (PO) who can really fulfill the requirements of the role. In my experience, it’s usually because the business appoints someone to be the Product Owner without understanding the commitment level required to fill the role and the Scrum Team finds itself either directionless or having problems because their Product Owner isn’t available. In this particular case, a Product Owner Proxy can be added to the team to help redirect and guide the day-to-day needs of the team.

First Things First

Let’s quickly review what Product Owners do. The Product Owner needs to bring the customer and business needs to the team so they can effectively build a product. This includes having an understanding of what the customer needs, working with the customer to differentiate between “must have “and “like to have”, and understand the product and the market so they can answer questions for the team and guide the work. In those cases where there’s no direct customer, they need to understand the market and determine what features will benefit the end user. They bring the “what” to the team; the team brings the “how”.

Proxyship 101

The main reason to select a Proxy is when the regular Product Owner in unable to meet with the team on regular basis (daily stand ups, etc. – they absolutely need to be present at planning meetings¹). Proxies fill that hole by being available and accessible. If you are selecting a Proxy but the person won’t be able to fulfill those requirements, pick a different Proxy. Ideally, a Proxy is physically co-located with the team; if not (e.g., because the entire team is remote), they need to be very heavily connected to the team (Skype, instant messaging, cell phone, etc.).

The Proxy is a very difficult role to fill and many Proxies find themselves with a lot of work to do. They need to understand the backlog items and the product well enough to answer questions from the team and to keep the team on track when the Product Owner is unavailable. They need to be connected to the Product Owner on a regular basis to understand shifting priorities and nuances of the needs. They need to be able to answer questions such as: Why are some backlog items ranked above others? What does the customer need next and why? This doesn’t mean that they need to know as much about the market or the customer as the PO does on a daily basis, but they will need to understand enough to answer questions for the team.

One good rule of thumb is that your Proxy should be communicating with your Product Owner at least once a day. This is especially true if something comes up at the stand-up that may be a blocker or may impact the work in the sprint. Otherwise, a touch-base conversation may be sufficient.

A Day in the Life of the Product Owner Proxy

If your organization requires a Proxy, it’s likely that your Product Owner will only be attending the meetings they are absolutely required to attend – the once-per-sprint meetings of planning, review, and (ideally) retrospectives. This means that the Proxy will need to attend all of those plus the daily stand-up meeting to hear from the team what they accomplished yesterday, what they plan to work on today, and what blockers exist. The Proxy should answer questions that arise, ensure that the team is working on the highest priority items in the sprint, and work with the ScrumMaster to remove impediments.

Cautionary Tales

The Product Owner Proxy needs to not be afraid to ask questions or go back to the Product Owner when they have questions or need information. They are a conduit between the Product Owner and the team and Scrum relies on open, transparent communications. The PO needs to know when the Proxy is uncomfortable making a call or if they lack information necessary to guide the team. Sometimes priorities and needs change; the Proxy should be communicating those to the team and make sure the team’s efforts are aligned with the Product Owner’s priorities. Additionally, the Proxy needs to escalate back to the Product Owner any issues, blockers, or problems that arise with the team.

Another caution is around time management. Being a Proxy is similar to being a Product Owner. Most trainers will tell you that being a good Product Owner is pretty much a full-time job. Same thing with Proxies. It’s possible, with well-established teams, that a Proxy could cover up to two teams and best if those teams are working on the same or similar work. Ideally, Proxies cover a single delivery team.

ScrumMasters should check periodically with the Product Owner to make sure he or she is aware of any issues that have come up to ensure that the Proxy and the PO are in sync. Open and transparent communications are the bread-and-butter of Scrum. You don’t want to be surprised at the Sprint Review that your team delivered what the Product Owner didn’t want. Additionally, many Product Owners have additional authority that Proxies lack and can be very helpful in escalating issues that require remediation.

Closing Thoughts

I personally have been a Product Owner Proxy for several projects in the past. It is a very demanding role, but when the Proxy and the Product Owner have a good understanding of what the team is doing, what the product needs to deliver, and they have a good partnership, the role can be very rewarding. Scrum teams looking to add a Proxy should do so only if absolutely necessary, but it can work and work well.

Do you have experience with Product Owner Proxies? Leave a comment below!

Notes:
1. If your Product Owners aren’t attending your review and planning meetings, you need to explore getting a new Product Owner – a Product Owner Proxy won’t cut it.