Agile, Product Management, Professional Development

Agile product prioritisation: why business value is the only metric that matters

Now that we’ve established what a product manager does, just how does that product manager prioritise competing requests that come from all areas of the business? In our mind there’s only one way to do this: Business Value.  

It’s important to note that business value doesn’t just refer to actual dollars brought in but to the long term value of the product and its users – all of which can easily be traced back to dollars, but it’s not just about sales!

There’s a common misconception that perhaps the way to make sure you get your requirement easily seen to is to be the best salesperson for that requirement. We reject that statement – strongly. It’s not about razzle dazzle, it’s about how valuable that feature is to the overall business.  

How do you assess business value?  
It’s not an exact science and it’s not expected to be, but it’s the best tool you have to gauge priorities in development. Take into consideration all angles:
– Is it a USP and something that will set you apart in market?
– What is the associated effort from the team to put it in place?
– Is it attached to a commercial campaign or is it a traffic driver – how much of each is it worth?
– Are there other reasons you might consider doing it (to get an internal department on side for example)?  

Once you have all the answers to these questions it’s time to do some maths in your head. Add up all the pieces and then weight them relative to all the other requirements in your backlog. The ones that come out on top (have the biggest “bang for buck” so to speak) are the ones you do first.  

Now you continue to iterate on these calculations, always re-estimating and re-evaluating your bang for buck to make sure that your team is working on the items with the highest business value at any one time. By working in this way it may not always be obvious why you have chosen specific features (they may be hard to develop) or why you have said no to some features (when they are easy to develop) but you’ll always be working on the right thing.  

If you’re after a bit more insight into the overall agile product owner process, watch this video on YouTube.