The Scrum Title “Product Owner” must die!
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.
- 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.
- I’m not criticizing any particular individual, even though my examples may appear that way.
- 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).
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.
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