47 responses

  1. Gagandeep Josan
    June 29, 2011

    Very True. Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  2. Joni Hoadley
    June 29, 2011

    Very True. Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  3. W. Alejandro Polanco
    June 29, 2011

    Very True. Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  4. Laier Dmitry
    June 29, 2011

    Good Bye “Product Owner”, Hello “Backlog Manager” http://t.co/hO8kl3D

  5. Etienne
    June 29, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  6. Lionel Falk
    June 28, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  7. Alan Reed
    June 28, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  8. What For
    June 28, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  9. jen
    June 28, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  10. John Peltier
    June 28, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  11. Steve Johnson
    June 28, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  12. Christian Almgren
    June 28, 2011

    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.

  13. Seb. Altenberend
    June 28, 2011

    Good Bye “Product Owner”, Hello “Backlog Manager”:
    by Saeed Khan
    A few weeks back, I wrote a pair of posts abou… http://bit.ly/jnO8BD

  14. bawbgale
    June 28, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  15. Kate McGoey
    June 27, 2011

    Interesting debate, part 3: Good-bye “Product Owner”, Hello “Backlog Manager” – http://t.co/hPmLsMB #prodmgmt #agile #scrum #baot

  16. Julie Hunt
    June 27, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  17. Stephan Haux
    June 27, 2011

    Hi,

    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
      June 27, 2011

      Stephan

      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.

      Saeed

  18. Jim Holland
    June 27, 2011

    RT @onpm: Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  19. jeffallison
    June 27, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  20. Pranav Desai
    June 27, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  21. Dan Callahan
    June 27, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum See my reply

  22. Angus Robinson
    June 27, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  23. OnProductManagement
    June 27, 2011

    Good-bye “Product Owner”, Hello “Backlog Manager” – http://wp.me/pXBON-2DB #prodmgmt #agile #scrum

  24. Romuald restout
    June 27, 2011

    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
      June 27, 2011

      Romuald

      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.

      Saeed

  25. Dan Callahan
    June 27, 2011

    “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
      June 27, 2011

      Dan

      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.

      Saeed

  26. Load More Comments…

Leave a Reply

 

 

 

Back to top
mobile desktop