Feature prioritization is one of the more important things product managers do. And mostly, a framework is useful to uniformize the various qualitative aspect of prioritizing. Many organizations adopt a specific framework (most use HiPPO, but matured ones may use a variant that’s far more objective) that helps them position the backlog (and the promises). You may be using one of the following:
1. Impact — Effort prioritization
This one looks at primarily the impact that the feature/bug has on the user and business, and the effort required to build/fix it.
Each column is a 1 to 10 scale of value (10 being the highest). The stakeholders are specific for each column, i.e. a business stakeholder should not see nor contribute to the development column.
Based on the stakeholders, you can have more columns. The final score (average here) decides what you’ll do first — highest score gets the highest priority.
Note that the audience for this method require a maturity in understanding that these things are dynamic. This process needs to be repeated almost every release to re-gauge priorities.
2. The Magic Quadrant
The infamous magic quadrant:
The X axis should be for value to the customer. This could be something that they immediately need or want to use. It could also be based on what the actual buyer (rather than user) wants. The Y axis should be difficulty or cost to develop. This can be a rough estimate from your engineering team.
The priorities than are — Q1 (highest value, lowest cost), Q2 (highest value, highest cost), Q3 (lowest value, lowest cost) and ultimately Q4 (lowest value, highest cost). Some debate exists on swapping Q2 and Q3 — but that’s organization specific. Note that some orgs prefer to ignore Q4 altogether, but it’s good to hold onto those.
Variants of the magic quadrants exist:
- Revenue v/s customer benefit — useful for product driven organizations
- Revenue v/s development effort — good for ecommerce/services driven organizations
- The cuboid — an unnecessary complexity of adding the Z-axis to the magic quadrant, the axis being either revenue or any other metric you track.
Audience for this method is primarily business teams — the vagueness of this method, due to the fact that items in each quadrants are all similarly prioritized, can put off developers.
3. Vision-Mission affinity method
This method is specially useful for large organizations where the technology piece is a small part of the overall org — think giant retail houses who’re just making a move into digital. This might be familiar:
The above example takes factors from Targets mission statement for the year (btw, this is a good website for mission statement evaluation), and fits the features to those factors. E.g. if Target wanted to launch a mobile application with the ability to transacting in-store, this would feature high in the first 4 factors.
The audience for this primarily business — helps to sell to the board on the feature priority, using a language crafted by the board. Product-jutsu. 🙂
4. Hybrid Models
As is tradition in product management, there is no one model that works, every time. For every roadmap, every backlog I’ve groomed, we’ve ventured and tried a variation of the above, depending on the maturity of audience. A couple of hybrids stand out when it comes to easy feature prioritization:
a. Magic quadrant with impact/effort
This helps position key-deliverables with business while ensuring the dev teams know intra feature priority.
b. Vision-Mission with impact/effort
Good sell to the business with devs understanding the higher business goals and subsequently, better coherence.
5. HiPPO model
It would be miss on my part not to mention the most popular model of prioritization, rampant in many legacy organization — the HiPPO mode.
HiPPO stands for Highest Paid Persons’ Opinion.
The HiPPO model stands to introduce chaos where we product managers seek to find order. There are ways to tame the HiPPO — a post for another day — I’ve known and seen my bosses manage the HiPPO in a spectacular fashion.
So now that we have a good grasp on the various prioritization models, let’s talk about the three points of failure:
First failure occurs when at least one person in your organizations hierarchy doesn’t understand, or has issues with, the prioritized backlog. As product managers, we’re not only to ensure that we’ve prioritized the backlog and presented it to the business, but also to ensure that we have consensus with everyone involved. Communication to, and commitment from, the last level of hierarchy is paramount to our prioritization success. As my former boss used to say, our job doesn’t stop at building and maintaining a product — that’s only the beginning.
Second failure occurs when we don’t define success properly. The definition of success — whether it’s a feature launch or it’s a bug fix, has to be clear and known. E.g. a relatively small feature of implementing a tracking pixel isn’t successful unless the end users (marketing team, in this case) isn’t using the data from there, to generate the revenue they estimated from the tracking. Mostly, time & money commitment is done on a promise of better revenues. Our job only begins at sending out the release notes.
Third failure occurs when we are not resilient. The nature of business is to be dynamic — changing business priorities will lash down upon you like waves at a troubled sea. Our job is to ensure that in the face of the figurative death, our ship stays true to the internal processes. Sure, make the changes — follow the current — only till the harsh times last. Always come back to the processes you set. We’re the voice of reason when chaos ensues. We’re the ship that raises the sails at the first sight of good winds and calm seas. We stay the course, guiding when the times are tough. Doing this builds credibility that helps in the long run.
Hopefully, through this, you’ve got a firm grip on what to watch out for when implementing prioritization frameworks. I’d always love to know about how you deal with prioritization? Are there any frameworks I’ve missed out on? Help a Bro-duct manager out! Let me know in the comments!
Thank you for reading!