The curious process of prioritisation - Simplifying decision drivers to relatable and understandable factors

Build up

One aspect of product management has remained consistent during my career - that is the fact that there are more ideas than there is bandwidth to develop and to address them. That is why an important part of product management is to perform prioritisation of ideas.

This is something between an art and a science as some aspects are easily quantifiable, but others are less so and some cannot be quantified (not in an easy manner at least that would justify going down that route). It's also important that the prioritisation process does not get bogged down with too many stakeholders and opinions as everybody will have conflicting interests.

So how do go about doing it and remove guess work and provide transparency to stakeholders?

Considerations

At first let us take a look at different factors that could be driving the priorities in any given business.

Business metrics

1. Revenue - will this feature allow us to a) close new business, b) expand to new segment, c) enter a new market

1. Cost savings - will this feature be a) one off saving, b) applicable across multiple clients / products / technologies
2. Return on Investment - theoretically business wise this would be the best metric for prioritising any development effort, but unfortunately it is also the most time consuming one to consistently and accurately to establish.
3. Maintaining competitive parity - some features are required to be implemented to counter the progress that competitors make in their offerings, so that you remain relevant in the market. It could be argued that you can turn these into lost revenue, but it requires that you then have in place a good understanding of the market dynamics and competitive landscape.

Timing metrics

1. Strategic Alignment - how well will the implementation of this idea serve you product vision and differentiation that you have outlined in your company/product strategy
2. Innovativeness - is this feature going to be a me too or will it allow you to differentiate your offering in the market based on this and force your competitors to play catch up
3. Time Sensitivity - is the market (i.e. are customers) ready for this feature, is this something that is a regulatory requirement, did your competitors already introduce such functionality
4. Client demand - is this being asked by sales person(s) or has this bubbled up directly from customers. Is it really a deal breaker or nice to have? Is it being asked by a single customer or multiple customers across the potential and existing customer base

Development metrics

1. Cost of Development - How much will it cost you to develop and test this specific feature in your offering covering effort, tools
2. Complexity of Implementation - how straight forward is the implementation of this new feature, are there dependencies to others, is it a quick UX fix or requires complex API integrations in the backend and revamping of the internal architecture and other functionality
3. Capability - does the existing team hold the necessary skills to implement the idea or does it introduce the use of new technologies that the development team might take time to understand.

the above is not an exhaustive list of all the possible factors but as we can see there are a multitude of things that we can take under consideration. The problem becomes when we start to compare different factors as typically a feature that results in new revenue rarely results in cost savings. We could of course do a deep dive on the return on investment to bring both to a common metric, but on a day-to-day basis this is pretty excessive to be done for every feature in the backlog and would keep the Product Managers busy just churning out business cases.

So how to go about it?

Having become familiar with the way incidents are prioritised in the managed and support services industry I think we have an approach that we can take away as a learning for backlog prioritisation. This is to distil the various metrics introduced above to the following:

• Impact - this is the natural home for all business-related metrics with the view that the impact assessment is standardised i.e. $10M revenue scores 10 same as $1M is cost savings scores 10.
• Urgency - establishing this will be most subjective, but noting down some guidelines will help these discussions e.g. needed for closing a deal is scored as 8, major customer escalation is 10, UX colour scheme fix is 1, etc
• Complexity - here to keep things simple you should be scoring inversely i.e. easiest development work scores the highest i.e. 6 months development by entire team scores 1 and 1 developer for a week scores 10

and grade those based on a chosen scale (e.g. 1-10). This is somewhat subjective but having the team work together on the grading helps counter any individual biases. This also allows you not to get bogged down on too much details that are likely to be time consuming to obtain and thus slow down decision making velocity significantly.

Conclusion

It is important to have a lightweight process to prioritise different ideas for the day to day business, but this does not mean that you should skip on performing full business case creation for big ticket items that require additional investment.

I would also recommend having a two stage prioritisation approach where by product management prioritises the features based on Impact and Urgency before development team is consulted on the complexity factor and final priorities are set.

Balancing the prioritisation between new ideas (which you usually don't have lack of) and older ideas that are not so impactful nor urgent is also important. These are ideas but are required to be addressed so that you avoid building technical debt in your offering, which leads to the introduction of the last proposed prioritisation factor - Aging.

Aging is something that gets best addressed by having a dedicated development slots for each development cycle to use for these aged backlog items, rather than have them die a slow death in the backlog or trying to artificially bump them up otherwise.