Good Bye “Product Owner”, Hello “Backlog Manager”

by Saeed Khan

A few weeks back, I wrote a pair of posts about the title/role of Product Owner in Agile development environments:

In those two posts, I talked about some of the problems with the role and general definition of “Product Owner”, as well as the “scope creep” that seems to be occurring by Scrum advocates that give more and more “Product” responsibility to that role (e.g. budget, strategy etc.).  Aside from the clear overlap with Product Management responsibilties, the title is a misnomer: It’s really “project” focused and the “ownership” is really more about the stories and backlog, than the entire product.

In the first post, I suggested other titles for the role such as “Technical Product Manager”, “Backlog Manager” or “Project Owner”.

A comment from Rohan on that article suggested that the name “Product Owner” was too entrenched in the Agile community to have it “die” and so it would be better to try to contain the role vs. change it. At the time, I agreed with that thinking, and in my second post, focused more on the (re)definition of responsibilities as opposed to the title of the role.

Over the last several weeks, as I’ve thought about this more and done some additional reading, I decided that my original thrust — that both the name and responsibilities must change — was correct.

And with that, I’ve come to this post.

What does the “Product Owner” actually do?

The following are some descriptions of the responsibility of the Product Owner taken from Scrum focused sites on the Web.

The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.)

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog.
(Source: Mountaingoat Software – a well known Scrum certification company)

The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.
(Source: Wikipedia – Scrum Development)

Of course, there are lots of other sites to select from, but these three, all fairly reputable, generally agree on the focus of the “Product Owner”. The focus is on managing user stories, prioritization of those stories and assisting the Scrum team during sprints in answering questions etc. and ensuring the work done by the Scrum team is aligned with the business needs.  In short, it’s all about managing the backlog.

Welcome “Backlog Manager”

Whether it’s the product backlog or the sprint backlog; whether it’s prioritizing it, explaining it, pruning it etc, the focus of this role is to manage and oversee the backlog for the rest of the Scrum team and work with them as they implement it.

No, it’s not as sexy sounding as “Product Owner”. But as a ROLE, (as opposed to a title), it’s far more accurate and unambiguous. There’s a lot of work and responsibility (both explicit and implicit) related to managing the backlog. Work will not get done without someone actively working with “the business” to understand customer/market needs, and then working with the Scrum team to ensure those needs are met.

This is not a solitary role — the “Backlog Manager” is most likely part of a larger team — perhaps in Product Management (in an ISV) or a client facing team (in a consultancy).  Also keep in mind, that according to Scrum guidelines, there should be one “Backlog Manager” per Scrum team. i.e. for any sizable project or product – i.e. that has multiple Scrum teams — there will be multiple “Backlog Managers. In thinking about it, this makes a lot more sense than having multiple “Product Owners” — particularly when all the Scrum teams are working on a single product!

So, I’m sure there are detractors out there, but I’m casting a loud (and first vote), to change the name of “Product Owner” to “Backlog Manager”.  All those for? All those against?

Either way, I’d like to hear from you.


Tweet this: Good-bye “Product Owner”, Hello “Backlog Manager” – #prodmgmt #agile #scrum

47 thoughts on “Good Bye “Product Owner”, Hello “Backlog Manager”

  1. Christian Almgren Reply

    Its all very interesting. And partly you get to an interesting point where we touch the difference between Title and Role. For many they are the same. Truth be told, for many of us Product Managers we are today also working in the role of Product Owners. And I guess many of us at the same time guard our Title Product Manager as we dont want to be identified by the single role we are spending some of our time in.

    So we spend time in a role that to many the identify our whole existence with. And I at least are sometimes getting annoyed by that.

    Simply changing the role name for Product Owner will probably not fix that. But it will be step in the right direction to restrict the role name so that it reflects the role and dont try to take owner all roles the person might have.

  2. Stephan Haux Reply


    well thought post as usual – however I do think there is an important part missing in your role description for the “Backlog Manager”: In order to manage the list well, this person does need a lot of acumen on the business side – aka the reasons the team is developing the product. When coming into the role as you describe it this knowledge is most likely existing, but over time focusing inward and managing the backlog the knowledge get outdated and even worse more and more biased towards the needs of the developers and the product team one is a member of. Also there is no way to have the market knowledge and the backlog manager being seperated into two people as the knowledge transfer is just inpractical.

    So the best is to make the product owner idea work in its entirety. How could this be done? And aren’t there many examples of the product owners overworked and even broken?

    When looking a bit closer to the variation of needs for the presence of the product owner over the course of a sprint there are times with more requests and timeconsuming consulting and there off-peak phases. Typically in the sprint planning the product owner is down right the bottle neck. All his user stories will need explaining, developers scope on basis of their understanding and coming back with more questions important for estimates. This heavy questioning continues for some time in the early sprint and naturally reduces to a fraction when the sprint matures. With acceptance meeting coming up the involvement of the product owner does peak again requiring his judgement whether the requirements are met.

    The success of a product owner does depend on his discipline to use the middle and end part of the sprint to plan for him facing outbound again. This is the time to investigate for new set of user stories and to interact with the market again. It does require a lot of self motivation to do this when you are a single product manager/owner. When you are part of a product management organization it is crucial to enage again with peer product managers and get some higher level thinking going to enhance your roadmap.

    Certainly this does not work if the product owner is member of many scrum teams – 3 have been the max I have seen working. In case the market facing product does require more than 3 scrum teams it has been good practice to have a senior product manager lead the overall product having technical product managers be the product owners for parts of it. Those little teams actually do work extremely well as the senior PM does cater for the unexpected requests from outside having technical product managers being able to focus on managing the fixed releases, splitting them into sprints and helping the scrum teams. Also they remain current in their wider field as being an active part of the overal product (management) team for the market facing entities.

    • Saeed Post authorReply


      Thanks for the detailed comment. I think I will discuss your point further in my next post. I understand the concern but I don’t think it’s a big problem to address if the PM team is staffed appropriately and roles defined clearly. I’ve worked in several companies that use Scrum — none of them exactly the same :-). There are clear ways to keep the marketing knowledge flowing. I’ll talk about those in the upcoming post. Stay tuned.


  3. Romuald restout Reply

    Some roles are well defined by one task: a developer develops, a tester tests, but “Backlog manager” reduces the role to this one task. While managing the backlog certainly is a large part of the responsibilities, I believe “Backlog Manager” does not reflect the role of this individual.
    It has no more link to the product, whereas in most organizations, this individual will be attached to a product or a subset of the product and will be, along with the QA person, the individual with the deepest functional knowledge of the product.
    It becomes a generic role, like project manager. The main skill becomes the ability to manage a backlog and no more the knowledge of the content.
    Technical Product Manager, while not perfect, remains for me the role description that is the closest to what the role stands for.

    • Saeed Post authorReply


      Thanks for the comment. I also do like Technical Product Manager, though there needs to be a distinction between the role and the potential titles of people who can fit that role.

      I think that a TPM (title) can be an excellent Backlog Manager (role). This distinction is important. In my first article, I did advocate (somewhat) for the TPM. At the end of that post I wrote:

      The “Product Owner” is dead. Long live the Technical Product Manager.

      But as I thought about it more, I realized that I was confusing the role and titles.

      Also, as I mentioned in the post WRT “Backlog Manager”, it’s not a tiny role.

      “Whether it’s the product backlog or the sprint backlog; whether it’s prioritizing it, explaining it, pruning it etc, the focus of this role is to manage and oversee the backlog for the rest of the Scrum team and work with them as they implement it.

      There’s a lot of work and responsibility (both explicit and implicit) related to managing the backlog. Work will not get done without someone actively working with “the business” to understand customer/market needs, and then working with the Scrum team to ensure those needs are met.”

      The responsibilities of the role are no different than what they are currently (in most cases), except that the title is different to better and more accurately reflect the actual responsibilities.


  4. Dan Callahan Reply

    “Backlog Manager”, while not sexy, is a pretty good description of the role… especially given that (as others have written) you’d better be shipping before you’ve implemented all the content you think is needed. (This is especially true in industries where the game is massive scale-up.) So managing the list is critical.

    But what’s equally important is tearing up the list. There are all kinds of tools to help the team “remember” what’s on the list. But have you ever forgotten to implement a feature that was really important? Not likely. So I like to occasionally put the backlog aside and ask, “what are the top three features we need to implement right away?” Chances are, the responses will tell you what really needs to be done to get the product into the market.

    – Dan

    • Saeed Post authorReply


      I understand what you mean by “tearing up the list”, and I totally agree, but in my experience, that happens pretty much every time a release is planned.

      i.e. What was important but deferred from the last release doesn’t automatically get to the top of the list for the coming release. Those items are re-evaluated along with other new requirements based on new findings, market or business changes.

      Your question “What are the top 3 features we need to implement right away?” is a good one and one Scrum teams should be asking themselves every time they look at reprioritizing their requirements backlog.


We really want to hear your thoughts...