Loading...
Latest news
How to Keep Your Product Strategy From Turning Into a Game of Jeopardy
The Maturity of your Market Dictates the Type of Product that You Need
Politics and your next release
What is a Successful Product? An Overview of Metrics and KPIs to Track Product Success
Product Management – You’re doing it wrong
CollaborationCultureDevelopmentOrganizationProduct MarketingProject ManagementSaeedScrumStartupsStrategy

The Scrum Title “Product Owner” must die!

saeedwkhan -

by Saeed Khan

no-product-ownerThere 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

68 comments
  9. Arran Hartgroves

    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…

    1. Saeed

      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

      1. Brian Deyo

        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.

  11. Joe

    “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.

    1. Saeed

      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.

    1. Saeed

      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

  18. davina

    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.

  24. Carol Kollm

    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.

    1. Saeed

      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.

  27. Rohan Jayasekera

    Great post, Saeed. Given that the role of Product Owner is a requirement in Scrum, and given that the name “Product Owner” is well established there, I think that “must die” is admirable but futile. I think we have a much better chance of success if we focus on educating people that Product Owner is a role, not a job title, to be filled by someone with a real job title like (in many/most cases) Technical Product Manager. Then the existence of the term “Product Owner” can be limited to members of the Scrum team, and the rest of the world can be spared. That is, I don’t think we can kill the term, but we can quarantine it.

    1. Saeed

      Rohan

      You are correct, given the history and the momentum of that title it would be difficult to change. But it doesn’t mean we should not speak out. It is a role, NOT a title, and it needs to be defined properly and “quarantined”.

  37. Pierre Neis

    Very interesting point of view.

    If PO must die then what is the sense of Technical Product Manager? or Backlog Owner (Sprint?Product?Release?).
    I agree there must be a clarification on Product Owner’s role or an update because to few Scrum Projects didn’t use it properly: multiple PO’s for 1 team, PO team in Europe and Development Team in India.

    Some points should be clear in Scrumers heads like:
    – it isn’t research but it is the development of a Product/Service for a customer (users)
    – you can use Scrum for Project Management or for Process Management
    – development team works in complexity filed during the Sprint, the outcome must be simple(PSI) and evaluated by a Specialist (SPO) (eg Cynefin framework)
    – starting a development project it is not changing the whole company. Implementing Scrum as Organisational Framework can be another project or is a consequence of the on-going process.

    So, Scrum is a project with limited time and scope (single product/service). If it isn’t true, then you are running a Program (and that’s a non-addressed rock’n roll.

    As conclusion, I would say that a good project has 2 gardeners, I nourish the Product Lifecycle, the other keep the process on track. And, like in every languages, when you change the term (the common understanding) then you change the language.
    Shortly: Scrum is a culture with its own nouns, a PO is crossfunctional in a projectised environment. If you want to keep functional silos, then be a Technical Product Manager.

  42. staplegun

    Part of the problem is job titles are often stated from a particular point of view. A ‘Business Analyst’ is often not really analysing the business overall but just creating technical requirements for IT projects. But becuase it was a role generated by a need in the IT department, it is a name given to someone who works with the business people ‘out there’ (outside IT) and interprets it into words we (IT people) understand.

    It feels like ‘Product Owner’ has the same lineage – we need someone who deals with all that business ‘stuff’ (we don’t understand) so we in the project can get on with software development (that we do understand) (yet feel like it meets their/the business’ needs).

    This post is a start at trying to give the PO a name that makes sense to the business as well as IT people. Though I think we will need more input from the business side to get a better understanding. My guess is they see it as something like a ‘Project Liaison’ person?

    1. Saeed

      Staple

      Thanks for the comment. There are many potential titles. It’s hard to find 1 that fits all scenarios — projects, products and applications. I’ve proposed Backlog Manager — https://onproductmanagement.org/2011/06/27/good-bye-product-owner-hello-backlog-manager/.

      As a role, that title seems best. It’s unambiguous in its responsibility and is not easily inflated or altered to be something it’s not. It also fits well with the CORE aspects of “Product Owner”. i.e. to groom and prioritize the backlog, to work with the Scrum team etc. It avoids all the P&L and other convolutions that people want to throw in. i.e. why would a “Backlog Manager” ever need to worry about P&L, or define strategy or vision etc? They just focus on ensuring the backlog is dealt with properly.

      Clearly he/she does not work alone, so it’s easy to define who he/she works with, where information and decisions come from etc.

  50. SĂ©bastien Sacard

    Thank you for this in-depth analysis of what seems to create a lot of trouble. I particularly like the comment from staplegun who thinks the problem comes from who name the role. Engineering team needed a “Product Owner” whoever it is, as long as they provide answers. Business people needed a “Product Manager”, whoever it is, as long as he deliver values. Today, both organizations are conflicting.

    I used to work at Yahoo!, as a Product Development Manager, while we were migrating to Agile. Now, I guess I would be called Product Owner. I used to work with Product Managers who were closer to customers. Actually, they were Product Marketing managers as they were in charge of rolling out the product in different countries and building partnership.

  52. A View on Product Ownership vs. Management – EntreProducteur

    […] The Clever PM: Understanding the Difference Between Product Managers and Product Owners The PM Vision: Duties of Product Manager vs Product Owner Responsibilities & Product Ownership and Management in B2B Commercial Software Product Focus: A Product Owner is not a Product Manager On Product Management: The Scrum Title “Product Owner” must die! […]

  53. Thomas

    Being in a situation that feels like we have 3-4 people occupying even the more limited space, for extra scale could we even go to “technical product management team”, composed of most or all of the four alternative job titles you gave, each for a different individual?

  55. Geert Bennenbroek

    I like your article Saeed. I am a fan of going against the grain in over-analyzing roles or disciplines or attempts to fit everything in a fixed set of rules. I think that success is a 90% result of having the right people in the right place. People who do what they like most, who are allowed the freedom to exercise their role as they see fit and are respected for it.

    To be honest, I couldn’t care less what the name for a specific role, tool or event is as long as it follows healthy principles of becoming better at what we do, together.

    In my perspective, Agile and Scrum take a step towards a more humane way of working, but it’s not the ultimate end-goal. Within a couple of years time, we’ll probably have another principle that we love and adopt. One that, hopefully, takes yet another step towards healthy work environments with guidelines as our reference, courageous organisations willing to experiment and happy people to get the work done.

    All the best,

    Geert

  57. indeks

    We are Pressure Cleaning Company ( also known as Pressure Washing , Power Washing ) ! We’re a Family owned company that takes Pride in our Customer Service as well as our work

Comments are closed.