The Long Distance Product Owner

I’m often asked questions I decide to answer on my blog. After all, if one person has the question, so do others. Here is the question we’re answering today.

How can we make it work when the Product Owner and Development Team are 12 time zones apart?

Answers People Don’t Like

Well, there are a few solutions which most people find outrageous. In descending order of objection:

1. Relocate the Product Owner to the location where the Development Team lives.
2. Fly the Product Owner to the Development Team for a few days every 6 weeks or so.
3. The Product Owner works 2 one half days per day.
4. The Product Owner makes herself available to the team at least one hour per 24 hours regardless of the inconvenience.

What Tends to Happen

A distributed team is one in which the majority of members live in different locations. This is not a distributed team. This is a remote team member problem which is MUCH less likely to succeed.

The Development Team will hopefully grow a team camaraderie, but it won’t include the Product Owner and herein begins the problem. Without facetime, there can be no real trust between the team and the Product Owner. This is especially true when communications are all written, rather than face-to-face in a video call or best of all, in person.

The lack of trust leads to come commonly observed behaviors:

• The Development Team works on things the Product Owner doesn’t know about
• The Development Team makes decisions about how the product should function the Product Owner disagrees with. This leads to rework and waste.
• The Product Owner is unable to fully understand and appreciate complexities like cross-team dependencies or systems integrations.

Frustration is high on both sides, so how do we break this cycle?

The Answer Most People Can Tolerate

One answer many teams find tolerable is to appoint a proxy Product Owner at the Development Team site.

This works better because the communication and deep understanding of Product Backlog items, features, and functionality must be understood between 2 people. This is much easier than trying to coordinate understanding between 9 developers and one Product Owner half a world away.

The primary and proxy Product Owner can meet for longer periods of time that are more easily scheduled when only 2 people are involved. They can collaborate during video calls on the features the team will add. The primary gets final decision-making authority in most cases, but this should truly be an informed collaboration wherein the proxy understands why decisions are made. This enables her to communicate those reasons to the Development Team and keep moving forward without guessing what the team should do next.

It is much more likely the proxy will come to understand the “why” of decisions and be able to communicate those effectively to the team as a whole.

Yes, there is still a scheduling conflict, but it’s easier to manage with only 2 schedules involved. Sometimes the primary PO can take the hit of working at night and sometimes it’s the proxy. It’s a give-and-take relationship now in which these people can build trust and effectiveness. The proxy Product Owner can now maintain a close relationship with the team and represent the product to the team with confidence.

The key is a very tight collaboration between the primary and proxy Product Owners. This allows the proxy to answer questions when they are asked, rather than waiting to consult with the primary Product Owner in their next meeting.

Is this ideal? No. But it just may be the least objectionable answer when compared to the others.