Agile DevelopmentCollaborationCultureOrganizationProduct ManagementRequirementsSaeedScrum

That Product Owner (er…Backlog Manager) debate again….

Tweet this: It’s that Product Owner (er…Backlog Manager) debate again http://wp.me/pXBON-2U3 #prodmgmt #agile

By Saeed Khan

There was a vibrant discussion on the Twitter Product Management Talk yesterday. The topic, a common one for Product Management types – the roles of Product Manager and Product Owner.

The discussion was lead by John Peltier who writes on Agile Product Management. Geoff Anderson who also participated, wrote a post on his blog – Tralfaz – about an exchange he and I had.

Geoff wrote about some of the issues he’s seen when companies add the Product Owner role.

These issues can be summarized as:

  • Putting very junior people in as Product Owners.  How junior? They “almost need to ask permission to use the bathroom”.
  • Organizational problems with Product Owners being part of Engineering. i.e. Putting the fox in charge of the henhouse.
  • The required frequency of communication needed between a Product Owner and Product Manager.

Here’s my take on these topics.

What is the right level of experience for Product Owners (or as I’ve advocated – Backlog Managers)

This one is easy. Put an inexperienced person in any role, and prepare to be underwhelmed. There is a trend to create junior “transition” titles — e.g. Associate Product Manager, Technical Product Manager — for people who are entering Product Management. Now there is nothing wrong with these types of titles, but the problems occur when there is a mismatch between the skills and the responsibilities for those roles.

Given the responsibilities of a Backlog Manager, such as ensuring the Eng teams stay focused on the right functionality, facilitating information flow, helping resolve problems as they are encountered, providing technical guidance when needed etc.  a junior person is the last person you’d want in this role.

The role needs a strong technical background, good judgement and decision making abilities, a persuasive attitude :-), and good communication skills. Doesn’t sound like a junior person to me. IMHO, the best person for this role, particularly in a company with a strong technical team, is an experienced ex-Engineer who wants to move into Product Management.

Where should the Backlog Manager reside

Without question, this role DOES NOT belong in Engineering. Plain and simple, it should be part of the Product Management organization, seated along with the corresponding Product Managers and Product Marketers who work on the same product.

Being part of the same team and sitting with them leads to the next point.

What is the right communication frequency

I’m always amazed at how much of a sticking point this can become in online discussions. What is the right frequency of communication between a Product Manager and a Backlog Manager? Well it’s quite simply the right frequency of communication. 🙂 i.e. whatever is required.

Sometimes it could be several times in a day. Other times it could be a few times a week. Other times, it could be once per week or even less. The reality is that there is always ebb and flow with information demand. But the question is how mature is the Engineering team and what kinds of day-to-day decisions are they making? Immature teams need constant care and feeding. Mature teams with experienced development management can work without daily guidance.

I personally have worked with remote teams (e.g. team is in India with me in North America) and aside from a weekly synchup call, other communications were primarily handled via email or if needed, a mid week phone call. And guess what, those teams delivered great products and didn’t lose their way because of any lack of communication.

So in short, what can companies do to succeed when implementing a Backlog Manager (or Product Owner)?

Get the right people, with the right level of experience, in the right organizational model and communicating the right amount and everything will work out fine. Easy!


Tweet this: It’s that Product Owner (er…Backlog Manager) debate again http://wp.me/pXBON-2U3 #prodmgmt #agile



  1. Erik van Eekelen

    Interesting article Saeed, thanks for sharing. I recognise most of what you say. One thing though:

    You say: “Immature teams need constant care and feeding. Mature teams with experienced development management can work without daily guidance.”

    In my experience, it is actually the mature Agile teams that will go to the PO more often to do micro-demo’s and ask questions. Immature teams will just work on themselves, think they understand what needs to be done and find out at the end of the iteration that what they built doesn’t meet the expectations.

    A PO that comes by only once a week would definitely be a red flag for me, mature team or not.

    1. Saeed


      Thanks for the comment. Your observation is correct and we are in general agreement though describing the issue from opposite perspectives.

      Immature teams don’t communicate as much as they should, which is why they need “constant care and feeding”. 🙂 Whereas mature teams will communicate more and thus don’t need that as much oversight. i.e. If the mature team is silent, you don’t have to worry, unlike an immature team where silence is not necessarily a good sign. In the end, as I said in my post, the right amount of communication is the right amount of communication, which should be determined based on need.

      I honestly think that there is far too much focus on this topic amongst Product Managers. Ensuring the right amount of communication happens is important, but why is the same amount of focus not given to discussions about finding the right price points or pricing models, ensuring the sales and marketing channels TOTALLY understand the value and benefits of the product, who they should (and shouldn’t be targeting etc), ensure that the messaging and positioning is rock solid etc.

      All of these other things have a MUCH larger impact on the success (or failure) of the product than the amount of communication that happens with particular engineering teams.


Leave a Reply

Your email address will not be published. Required fields are marked *