All about ... product prioritization
One of the main tasks of a Product Manager is to prioritize things, whether that's prioritizing larger features in a backlog or smaller features within a deliverable. There's a constant organizing and reorganizing of the different items and this shuffling of the pack needs to be based on some criteria. The question then is what is the criteria you're working against?
o aid this process different frameworks of prioritisation have been created and we're going to take a quick look at some of these here.
MoSCoW
First developed by Dai Clegg and used in the Dynamic Systems Development Method (DSDM) framework of agile delivery, MoSCoW is a firm favourite for prioritising requirements as it follows a fairly straightforward approach, using plain English phrases, namely:
Must have - this requirement must be included in the delivery, whatever happens
Should have - this requirement should really be included in the delivery, if at all possible
Could have - this requirement could be included if we had an opportunity, but if not then it's not the end of the world
Won't have - this requirement definitely won't be included in the delivery
It's a very handy thing to get non-product people involved in prioritizing their own features, as they can understand the concepts easily and means they don't have to rank each item against each other, only to determine whether it definitely is needed or not. The downside of course is that if you have 10 items that are all classed as Must Haves then there's no way of prioritizing them against each other and thus a delivery without all of the items would be classed as a failure. There also is a fair bit of subjectivity in there, with one person's must-have being another person's could-have, but you'll find that with a lot of prioritization frameworks.
RICE
RICE is another acronym, which this time stands for Reach, Impact, Confidence and Effort, and was created by the team at Intercom (the messaging platform). These categories are used to score a feature with a combination of the score allowing you to rank different features against each other. The higher the score, the higher the priority. The categories themselves relate to the following:
Reach - how many people will your feature impact over a given time period, for example, 100 new sign-ups in the quarter = a score of 100
Impact - what kind of an impact will the feature have on a key factor, for example, a huge (4) high (3), medium (2), low (1), so a high impact would = a score of 3
Confidence - how well do you know what to do and what the impact will be , for example, high (100%), medium (75%), low (50%), so high confidence would = a score of 100%
Effort - how much work will be required to deliver the feature in a person-based time frame, for example, a person month, a person week, so two people for a week each would = a score of 2
The output of this is a calculation which multiplies the reach, impact and confidence (100 x 3 x 100) and divides it by the effort (2), giving you a RICE score (15,000), which could be compared against another feature where the scores are different such as one where the reach, impact and confidence are 1000 x 3 x 50 and the effort is 4 person weeks, giving a score of 37,500, meaning this would be seen as the higher priority.
Product Tree
One approach that has taken more of a hold recently is the Product Tree, where the metaphor of a tree is used to describe the underlying infrastructure to support a product (the roots), the core product itself (the trunk), the primary product features (the branches), and the new ideas (the leaves). Some extend the metaphor to the return on investment of the ideas (the apples).
It is an interesting mechanism for visualising the different elements and has a bit of a mindmap feel about it as you follow branches onto leaves, and in practice, it needs just a few Post-it notes and Sharpies and away you go.
To me though, Product Tree is more of a road mapping tool than a prioritisation framework, as you can visualise the way the different ideas fit in the tree’s growth (nearer to the trunk and the near term the idea, whilst the nearer to the canopy the more long term the idea), but to get to the right location on the tree someone somewhere is making a prioritisation decision and it's not part of the Product Tree itself.
Conclusion
There are more frameworks and more ways in which to look at prioritisation, but ultimately as product managers, we're considering what value is this going to deliver for our business. The more value for the least effort then the greater the chance of prioritisation, than low-value high effort items. The important thing is to make sure that everyone is clear on what the criteria for prioritisation are and that they contribute valuable information in order to inform the decision-making.
If you can then get people to not only suggest ideas but to provide justification for the effort and estimates of the return on the investment then you'll have people doing a lot of the hard work for you, although this is often harder than you think. In many businesses, the suggestions you get will often only be focused on saving time and becoming more efficient, as these are the things that people notice the most, and you'll have many less suggestions for new income streams or cost saving initiatives.