Some of my clients grow frustrated with their disengaged, unskilled Product Owners. In an effort to get the work done, they create a new Scrum role called “Proxy Product Owner.” This person’s job, in a nutshell, is to do the “real” Product Owner’s job for them, particularly the less glamorous parts: meeting with stakeholders, writing user stories, attending Scrum meetings.

Sounds harmless, right?

Unfortunately, creating the role of “Proxy Product Owner” is one of the quickest ways to derail an agile transformation.

Here’s why:

The Product Owner is the “buck stops here” role in Scrum. They form and articulate the project goal, determine which requirements are most important, decide which stakeholders will be told “no” and which will be told “yes”, and establish when it is time to call a project “done”.

When you dilute that authority by introducing a role Scrum never had in the first place - a Proxy Product Owner - you set into question who, exactly, the “real” Product Owner is. This opens the door for Scrum team members, stakeholders, and pretty much everybody to start thinking like this: “Well, we don’t like the answer we got from Person A, so we’ll ask Person B.”

It also ensures the “real” Product Owner will never get better at his/her job. Really, why should they? They now have a person who will 1) do all their work for them and 2) take the blame for every bad thing that happens, while THEY take credit for the good things.

Is it ok to have people help the Product Owner? Absolutely. But they are just that - helpers. They are not “proxy” anything. If you are choosing a Proxy Product Owner because the “real” PO isn’t getting the job done, then it is time to reassign the role of Product Owner to someone who will actually do it.

This struggle happens often in IT organizations. They want the Product Owner to be in the business units, which is understandable. But those people are sometimes unwilling and unable to fulfill the role.

That’s ok.

Keep the PO role inside IT - for now. Make it a goal to grow the people in the business units into the Product Owner role when they are ready. Over time, as these potential POs realize that it is the Product Owner who makes all the final decisions as to requirement priority, they get more interested in fulfilling the role.

I had one client who did this brilliantly. A mid-sized chemical company, they wanted their business unit partners to be Product Owners, since they were the people closest to the customers. But the business units were having none of it. Their attitude was, “That is what we pay IT for - to manage our projects. We’re busy and we don’t have the time.” So my client said, “No worries - we will take care of the PO role.”

And they did. For about a year.

But then their business unit partners noticed something. It was this “Product Owner” person who got to make all the decisions about priority and details… not them. One business unit stakeholder eventually protested, “Hey - I should really be the Product Owner, not you guys. I actually understand customer needs, so I should be making these decisions.”

Their key ScrumMaster, who is a very sharp lady, did not miss a beat:

“You know, you are absolutely right. Would you like to go to Product Owner training so you can take on the role?”

Clever. Perfect. And everyone was a willing participant.

If the “real” PO cannot do the job, take it away from them. That is how the world works - if you don’t perform, someone else steps in to take your place. Prove yourself worthy later and we can reassess.

The Product Owner role is too important to be filled weakly. Don’t give it to the person who “should” perform the role. Give it to the person who will perform the role.