Refactoring the Role of the Product Owner

The PO spot has become a major point of focus in recent years, especially when the PO is doing a less than spectacular job.

However, the issues people are having with the PO are a natural consequence of how it evolved. Luckily there is a solution for the PO problem!

As you may know, the “Product Owner” evolved from XP’s “Onsite Customer”.

The “Onsite Customer” concept had a lot of problems in execution, and so, it was refactored somewhat to the “Product Owner” role.  However, a few mistakes were made.

In some Agile methods (such as “Scrum”) the PO actually performs several different functions;

1) They are overall in charge of the project

2) They are the primary “voice of the customer”, or customer proxy

3) They must understand and coordinate many different business functions such as budget, backlog, customer feature requests, and prioritizing what the dev team works on.

Now, in a traditional business environment, there would be a “Project Manager”, and that PM would normally have a technical background.

Therefore, they would have an understanding of technical debt, and the need to architect or rearchitect a system, not just throw features at it.

The problem with the PO is,

1) They are usually converted Business Analysts and generally do not have a technical background

2) They have complete control of a technical endeavor which is generally beyond their core competencies

So how do we fix the problem? Very simply.

We refactor the PO to be the CP. The Customer Proxy.  They prioritize the backlog, still, and juggle customer requests versus bug fixes but they do not have absolute power over the entire project.

Enter the Return of a Real Project Manager, with technical skills, who the CP now (rightly) reports too.  The PM can then arbitrate conflicts between the Dev Team and the CP, keeping in mind the tradeoffs in terms of maintenance over the long term and juggling the profitability of doing any particular feature versus just doing whatever the customer says they want.

This lets the CP focus solely on what the customers want; the dev team to focus on what they need to succeed, and the PM to juggle the various tradeoffs and arbitrate conflict.

Putting a technical person in the PM role means the team will no longer be directed solely by a soft skills BA who does not often understand the technical project that is being managed.

Some may decry this as a return to the old, but the old had a lot of advantages compared to the new. To me this represents the best of both worlds.


About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

3 Responses to Refactoring the Role of the Product Owner

  1. The Product Owner roles, as it is written in Scrum, probably works well for small-medium organisations, but I am dubious as to how well it works for large orgs. I’m also not sold on a “Customer Proxy” concept, though I can appreciate you calling it out a spade for what it is. I think the Agile community hasn’t followed through on some of its original promising of really understanding the customer and delivering with speed. The more I look at Lean Startups the more I believe that having anyone dictate requirements as if they know the solution 100% is a bad idea. After all, don’t we statistically have a problem where 60-80% of the system is never or rarely used?

    • PostAgilist says:

      Hi Renee

      Thanks for the comments. Well, there is more on the PO I could write about, but, regardless of size from what I can see the PO issue is one of the largest pain points out there for people doing Agile.

      I think you bring up a point that I’ll be blogging about later on a related topic but basically, I also feel that the listening to the customer at all is oversold and not one size fits all.

      Listening to the customer makes sense if your developing a product for a customer, and they own the spec. If you are creating a product to sell in the marketplace, then you should understand what the customer wants better than the customer.

      After all, didn’t Henry Ford say that if he listened to his customer, he’d have built a faster horse?

      In more modern times, would anyone tell Rovio that they want to play a game where they shoot birds like golf balls on their cell phone? No; they had the vision.

      So what I’m doing with the CP, and why I think it works well in more cases, is that

      1) The Customer still has a voice
      2) The Customer voice is no longer driving the entire project
      3) The Customer voice can always be the voice of the customer without having to wear multiple hats wherein they juggle whether they should listen to them or not…someone else gets to do that


  2. Mike Pearce says:

    Great article PostAgilist! This makes sense! I’m not sure about the reporting direction, or whether one needs to be subordinate to the other – I’d rather see them work together, or at least be pragmatic about the decisions made.

    I blogged about Henry Ford and his faster horse a while back:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s