Simple right? The Product Manager prioritises the Product Backlog and the Product Owner works with the Scrum Team during sprint planning to create the Sprint Backlog, everyone’s working on the right stuff and everything is perfect. If only it was a simple as that!
In a perfect world, the Product Manager has ultimate accountability for the prioritisation of backlog items to maximise the value of the sprint. However, in a lot of organisations this role quickly becomes a stakeholder management role trying to balance the opinions of three key areas of influence. These areas will often see their opinions as the most critical to the success of the product. The biggest problem with this of course, is that they are all usually right, “from a certain point of view”.
The first view group will always and should always be the customers or users of the product. These are the people that are paying for your functionality and the value that you bring to them. These backlog items will often generate immediate benefit to the userbase and will focus on critical challenges that your customers are facing right now.
The second area is often an organisations leadership team, who should be aligned with the Product Managers vision for the product, but will frequently have their own thoughts and opinions relating to what is important and how quickly backlog items should be addressed. Dependant on the nature of the product this may change but new features that drive additional revenue will be highly prized by your organisation, along with functionality that may not drive immediate benefit but sets the product up to be more valuable in the future. That doesn’t mean you can forget about all that great customer feedback that highlights how the products is meeting the needs of your customers (see the first group).
The third cohort keen to have their say, will be the development team themselves. It is important to say that if you are only using your development team to develop code then you are missing out on a huge chunk of the value that they can bring. These people are closest to the technology and will have thoughts and ideas on how the technology can be used to solve real customer problems that may not have even made it to your backlog if they are fixated on code development. Development teams will also be acutely aware of where they have been forced to create technical debt to hit a deadline or meet a cost challenge or where automation can provide more capacity. They know that at some point in the future unless addressed, this may bite them and will be looking for opportunities to address it, even when this doesn’t bring direct immediate benefit to the customer.
Managing these three different stakeholder groups is a complex task that can tip the balance between success and failure of products delivered in using agile methods. In my experience, I have even encountered scenarios where prioritisation of backlog items is conflicted within with the stakeholder groups themselves, leaving the Product Manager with the unenviable task of facilitating the best outcome even within those groups.
It is not an easy challenge, but my advice to Product Managers is always to make sure that each of these parties are aware of each other, how valuable each of their inputs is and most importantly, the key factors that you are using influence the decisions to prioritise one backlog item over another. This will enable them to consciously support your endeavours to get the best results for everyone.
Obviously, this should always be where appropriate, don’t tell your customers that the new feature you are prioritising is going to significantly increase your revenue. They probably already know.
Are there any other key stakeholder groups that should be considered when prioritising backlog items, or any other advice to Product Managers on how best to manage these different groups and conflicting opinions?