The Scrum Title “Product Owner” must die!


by Saeed Khan

There was a tweet this past weekend that caught my eye. It said something like “The Product Owner on one page”. It was retweeted many times.

When I looked at the link in the tweet I saw the image shown below. I thought, “Geez, now the Agilists are turning the Product Owner into some kind of superhero Product Manager?”. And we know what a problem that is. :-)

I had to write something to help clarify this never ending debate about what a Product Owner should be.

I’ve written about Agile previously on this blog, but it’s been a couple of years since I delved into the topic at any length. Before I begin, and before people misinterpret what I’m about to say, let me clarify a few things up front.

  1. I have nothing against the general concepts of Agile or methodologies like Scrum (or XP etc.). If tightly-coupled teams make for better communication and better results, then great.
  2. I’m not criticizing any particular individual, even though my examples may appear that way.
  3. It’s the title and overall definition of “Product Owner” that must change, not the need for some form of business focused oversight on software development projects that Product Owners typically deliver.

That aside, let me get started.

I have never liked the title “Product Owner”. It’s a very narrow-minded view of the term “product” and is not even consistent with it’s own description.

On the Scrum Alliance site, in the sidebar, you can see that Product Owner is listed as:

Responsible for the business value of the project

Yes, it says business value of the project, not product. BIG difference. But other than that, the description is very general, and quite  open to interpretation.

On Wikipedia, the Product Owner is described as:

he/she “who represents the stakeholders and the business”

Again, a fairly general description, but in short if you look at these two together, they seem to describe someone who has the business interests in mind for a given project and ensures that value is delivered back to the business.

It’s pretty clear that in the early discussions of Scrum, there was clear evidence for the need to have “the business” represented as part of the development process. Far too many projects floundered because of lack of input and alignment with business needs. So the problem being addressed by a “Product Owner” role was valid.

So the question is, how did the title “Product Owner” go from this high level general description as an overseer of the business interests for a given project, into what is a much larger singular role with broad strategic and tactical responsibilities that is described by the diagram on this page. (shown below).

Product Owner on one page - Roman Pincher

From one of the founders of Scrum

To find the answer, I decided to go to primary sources. Thank goodness for the wealth of info on the Web. Very quickly I came to Jeff Sutherland’s site. Sutherland, along with Ken Schwaber and others were amongst the earliest advocates of Scrum and were instrumental in it’s definition, development and growth.

Sutherland has a draft PDF of his book, The Scrum Papers: Nuts, Bolts and Origins of an Agile Framework available on his site. There’s a lot of good content in the 200+ pages, but there are also some problems.

The first key description is that of Scrum itself. On page 16, Scrum is defined as:

Scrum is an iterative, incremental framework for projects and product or application development.

There is nothing inherently wrong with this sentence, but it’s important to note that 3 contexts (projects, products, applications) are to be addressable via Scrum.

And on page 17, Sutherland describes Product Owner. Now, I’ll give some leniency as it’s a draft from Jan 2011, and he may have clean up the definition a bit, but the overall definition of Product Owner is a real mish-mash and clearly needs to be changed significantly to address the ongoing confusion in the market about that role.

The description from Sutherland’s draft is  a bit long so I’ve broken it up for easier digestion and analysis. But read through all of the following as it’s the source of the whole problem with the Product Owner role.

The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list.

The description starts out reasonably clearly, with the Product Owner taking on the role of an analyst, identifying and continuously prioritizing features. In many companies though, this process of collecting, understanding, prioritizing etc. is likely done by more than one person so right from the start, putting all of this on one individual is an issue.  But then the description gets downright problematic. He continues:

The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. In the case of an internal application, the Product Owner is not responsible for ROI in the sense of a commercial product (that will generate revenue), but they are still responsible for maximizing ROI in the sense of choosing – each Sprint – the highest-business-value lowest-cost items.

In practice, ‘value’ is a fuzzy term and prioritization may be influenced by the desire to satisfy key customers, alignment with strategic objectives, attacking risks, improving, and other factors.

First of all, why make this distinction and give the “Product Owner” of a commercial product profit and loss responsibility? There’s no reason for that in the context of a software development methodology. P&L is a pure business function, and may not even rest within a Product Management organization, let alone a someone whose primary role is interfacing with Engineering teams.

On the plus side, I’m glad to see the recognition of the fuzziness of value and that it can be determined in different ways. But the use of the phrase “high business-value lowest-cost items” is incorrect as medium- or even high-cost items can be prioritized above lower cost requirements based on need and business value.

In some cases, the Product Owner and the customer are the same person; this is common for internal applications. In others, the customer might be millions of people with a variety of needs, in which case the Product Owner role is similar to the Product Manager or Product Marketing Manager position in many product organizations.

OK…now here’s where the description has some other problems. Sutherland acknowledges that there is similarity between the PO and PM or PMM roles, BUT:

However, the Product Owner is somewhat different than a traditional Product Manager because they actively and frequently interact with the Team, personally offering the priorities and reviewing the results each two- or four-week iteration, rather than delegating development decisions to a project manager.

So, more communication is great and there’s nothing wrong with having someone from the Product Management team be more actively engaged with the Engineering team, but then why not just say that’s what is needed as part of the methodology. i.e. a new role that must “actively and frequently interact with the Team…” and not include unnecessary baggage such as P&L.

It is important to note that in Scrum there is one and only one person who serves as – and has the final authority of – Product Owner, and he or she is responsible for the value of the work.

This last line of the description – about having a single responsible person for the value of the work of “the Team” – needs work. The problem here is that for a “Product” there may be many Scrum teams and there is no way a single person can have regular and detailed interaction with those teams, continuously prioritize (and reprioritize backlogs) etc. i.e. this model works for simple “products” but breaks down for larger ones.

So what is the solution?

I’m glad you asked. :-)

From a Development perspective, the core issues that need to be addressed are:

  • the need for ongoing backlog prioritization
  • the necessary interaction with the Development team so they can make progress on the backlog and stay aligned with the needs of the business.

That’s it. Everything else, from P&L to budgets, to roadmap and vision (as shown in the diagram above) are irrelevant. In most companies, those responsibilities already have owners so there is no need to muddy waters and blend them into the “Product Owner” role.

The “Product Owner” is part of a team — i.e. the Product Management team — and is the primary interface of that team to the Scrum Team.  For a large product, if there are many Scrum teams, there may be multiple “Product Owners” working with those teams. i.e. there may be multiple “Product Owners” that are part of Product Management.

Thus the name “Product Owner” is itself confusing, if not inappropriate. the following are all better titles than “Product Owner”:

  • Project Owner
  • Technical Product Manager
  • Backlog Manager
  • Customer Advocate

There may be others.

As a “role”, the term “Backlog Manager” seems reasonable.

As a title, “Technical Product Manager” (TPMs) is best, particularly for companies building commercial products. It’s unambiguous…the person is part of the Product Management team, there can be multiple TPMs working with multiple Scrum teams (not necessarily in a 1:1 relationship mind you), and they have a clear technical focus.

It’s time to end the confusion.  The “Product Owner” is dead. Long live the Technical Product Manager.

Saeed

Tweet this: The Scrum Title “Product Owner” must die! http://wp.me/pXBON-2vL #prodmgmt #agile #scrum #innovation

See my follow up post:  A new (and better) defintion for Product Owner

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

We really want to hear your thoughts...


  1. Saeed,
    Nice thought provoking post. It’s all about scale. In a small company the PO may also be the PM and have direct ROI accountability. In a larger company, the PO might be a part of a larger PM team and only have part of the product roadmap and not own the vision. You want someone with the knowledge and authority to ensure what’s beng worked on directly supports ROI. Often by the time it gets to engineering there is a gap. The PO role was in response to this gap. This may or may not be a Technical Product Manager, depending on the size of the company.


    • Carol

      Thanks for the comment. And I agree with your description. The gap does need to be filled. How it is filled is up to the company based on size, existing organization etc. None of that is stated explicitly as part of the formal Scrum definition of the role. That definition is fairly rigid and expansive, both in terms of title and responsibilities. That’s one aspect of the root problem. The second is the actual title “Product Owner”. It’s a bad title. Even if it only is used to describe a role, vs. and actual title, it’s still bad. Given the response to this post, I’m planning a follow up post next to elaborate and clarify some points.


  2. Great post! The product owner role has been a bee in my bonnet ever since my organisation introduced it and moved us (product managers) into “strategic product manager” role. I have many problems with the definition of PO, but one of the fundamental problems, in my opinion, is that the PO role is not about the product but about the project, which means that, as a “strategic product manager” I cannot trust that decisions are made for the good of the product and not only for the good of the project.


    • Carol

      I would love to hear more about where you disagree. It’s not a cut and dried subject, but I clearly have my viewpoint. :-)

      Saeed


  3. “The description from Sutherland’s draft is a bit long so I’ve broken it up for easier digestion and analysis.”
    If a definition or description is long and complex it usually means that the definition is not clear enough and needs to be broken down further. This alone should be an indication that things are fishy.


    • Joe

      Thanks for the comment. Long descriptions do tend to imply lack of clarity. I was quoting from a draft of his book, so I’ll give some leeway, but the key points about P&L, interaction etc. were definitely some of the the troublesome parts.


  4. Great blog, good to see some background research!

    Are we however confusing responsibility with having to do the work? I have POs who own the vision, and roadmap, confirm release plans with team etc… Although the work is not undertaken by them…


    • Arran

      Thanks for the comment. When you say you have POs who own the vision/roadmap, can you explain what that means? i..e what does “owning” it mean? Do they define it or are they responsible for ensuring it is followed? I’d love to hear more on that as it is a point of confusion.

      Also, what is their relationship, if any, with the Product Management team? A little bit about your org structure would help.

      Saeed


      • I think this clears things up a bit “The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list.”

        They define “it” and drive the vision of the product as well as the value (which is a messy process of prioritization) and that requires lots of interaction with the team in order to understand the cost of story completion so they can prioritize correctly, but the entire team is responsible for making sure the roadmap is followed. That is a responsibility that is shared. If it is followed, execution is owned by the development team and likely the project manager/scrum master.