Process for Prioritising the Product Backlog

I’ve spent the past year bringing a new product to market, as a consultant Head of Product for a start-up business unit that’s owned by a multi-national. I had the opportunity to pretty much start at the beginning: pulling together the vision, setting up a product council/steering group, talking to users about the initial concepts and shape the overall product direction.

After launching V1 of the product I ran a number of prioritisation meetings with key business stakeholders.

I’ve chaired and been involved in many different types of prioritisation meetings before. Somewhere there were up to 12 frustrated web editors (who managed sites where advertising was the major revenue stream) all had to bid for a slice of the scarce development resource. Prioritisation was done purely based on revenue: those sites whose demand for inventory was higher than what they were supplying won out.

Other prioritisation meetings comprised of me (the product manager) having to present and persuade senior stakeholders of the validity of a pre-prioritised backlog and drive consensus.

 Recently I decided to use the following process to not only prioritise the backlog but to aid in building unity among a group of stakeholders and win their confidence and trust:

1. We agreed on the goal for the next quarter – in this case it was to build our user base as opposed to driving revenue. A hard sell for an ad funded business. 
2. We went through the backlog and as a group agreed on the category of every item: User engagement, revenue, contractual, audience, acquisition etc... Most where no-brainers,  but the key was that the group felt that it had categorised the backlog. 
3. By common consent a champion was assigned to represent each backlog item (represented in the meeting was: Heads of Marketing, Ad Operations, Head of Product, Tech Team Lead and the MD/General Manager of the business unit). 
4. The champion would then give an elevator pitch on the importance of their backlog item followed by a brief Q&A cum discussion. 
5. We would then vote (in the same way you play poker in scrum) on how the item would best fulfill the goal we all agreed on. Each score is then entered into the spread sheet. 
6. When we get to the end of the backlog click ‘sort’ and hey presto we have a prioritised backlog.

Everyone embraces the outcome because: they participated, there was total transparency and we all bought into the goal for the coming quarter.

Finally I would present the prioritised backlog to the product council/steering group – in general it’s well accepted because either those present participated in its prioritisation or one of their subordinates was involved and reported back to them.

The quality of the prioritisation is directly related to the product manager’s ability to keep everyone on track, focused on the agreed goal as you vote on each backlog item.