All of Prioritization is about making tradeoffs.

People have a flawed view when they talk about prioritization. It isn’t limited to ordering items in descending order of importance. Importance, urgency, viability are a few factors to consider while talking about prioritization. If you have worked in corporate YOU KNOW that priorities change. Pivoting becomes crucial if business demands it. Sticking to your roadmap could come at an opportunity cost.

While there are a gazillion frameworks out there for prioritization let me start with the most basic of all. We will move to advanced frameworks later in the blog.

The Eisenhower Matrix

Nothing can be as simple as the good’ol Eisenhower Matrix diagram. You don’t even need a table or any tool to remember this simple chart which is a good way to prioritize minor ad-hoc items.

If something is super urgent and is important you should be doing that activity immediately. If it can wait, but you know that its needs to get done in the future you must schedule it for a later time or date. While there could be tasks which are urgent but are not super important, how about assigning someone else to do it or doing at a later time. Most importantly there are tasks which feel Urgent and Important – these tasks should be skipped altogether.

Back when I was in college, I had a classmate who used to skip a few classes especially ones which were supplementary classes. When I asked him why he did that, I starkly remember his response – “It doesn’t matter. I would be just wasting time over there.” He had one thing which most of us did not – Clarity on what matters the most”. Identifying the top left quadrant is paramount for delivering impactful work. If you wrongly prioritize the bottom left quadrant – you would be doing shallow work. Shallow work is easy and sometimes necessary (eg. operational activities) but you should not be spending a good chunk of your day doing that. Identifying things that matters and working on it with a singular focus is the differentiator.

If you are an IC (Individual Contributor), you wouldn’t have team mates you could delegate work to. In this case you will have to find time to do shallow work. Personally for me, I dedicate an hour and a half per working day to work on shallow tasks. This could be something like creating support tickets for the engineering team, looking at customer feedback or even something as trivial as following up on a task with the engineering manager. These tasks do not require excessive mental effort and therefore should be worked upon only in non focus hours.

What we have discussed so far is a simple prioritization model which applies to small and medium level tasks. Most of what I have discussed above, simply cannot be applied to making major product roadmaps. The Eisenhower matrix is great for adhoc/impromptu decision making but when we deal with prioritization of items like creating a 3 month roadmap, there are a gazillion data points you’ll need to consider. I will start with my favorite and most used prioritization model – the RICE framework below.

RICE – Reach, Impact, Confidence, Effort

RICE is a great tool for prioritizing roadmap items. I am talking about the big boulders like epics and goals. RICE has rescued me time and again when management has asked me “Why item A should be prioritized over item B ?” I was able to confidently answer this question because RICE follows a quantitative approach. It scores items based on Reach, Impact, Confidence and Effort and the scores of each of these items are ordered in descending order. This order is the order of priority. Lets delve into each of these aspects in detail.

Reach – Reach is a subjective term which differs from Product to Product. For eg. Your product could have a total of 500 users. Here your Reach is 500. If your product has 5 million users, then your reach is 5 million. If you are releasing a feature to only premium members of your user base – say 100 of them, then the reach here is 100. Reach is simple terms means the number of users who are going to be affected by the addition of a feature or a change in the product.

Impact – Impact will tell you how far a goal will move. There is one problem though. While Reach is an objective value, Impact is a subjective value. Usually graded as 0.25, 0.5, 1, 2 or 3. Different stakeholders could give different value to Impact depending on their understanding of the problem and their experience.

Before we discuss Confidence, we should ideally look at Effort. To have a good idea about Confidence, the Reach, Impact and Effort values must be in place.

Effort – Effort is the time and the manpower required to build a feature or to execute a change. Teams calculate this based on the sprints, weeks or months. For eg. if product requires 2 weeks to plan a change, design requires 1 week to design it and engineering required 3 weeks to build and deploy then the total weeks spent on the change would be 2+1+3 = 6 weeks which is 1.5 person months. I personally use sprints and no of devs involved to make the change. If 3 devs are working for 2 sprints, then the change/feature should get done in a month’s time. This is considering a 2-week sprint.

Confidence – Confidence refers to the degree of certainty regarding the values assigned to the three parameters: Reach, Impact, and Effort. A confidence level of 100% indicates complete assurance in the accuracy of the data provided. A confidence level of 80% suggests moderate certainty, implying some degree of caution due to incomplete or uncertain information. Confidence levels of 50% or lower indicate that the estimates are primarily based on assumptions, reflecting a higher degree of uncertainty and less reliable data.

Based on these factors we calculate the RICE score.

Once the RICE scores for each item are obtained then it is just a matter of ordering them in descending order of the RICE score. You now have a solid justification of why an item came first and why an item came second.

Kano Model

Imagine this – you have users and multiple stakeholders giving you inputs for new features. All of them look promising on the surface. Organizations use various software like UpVoty or Feature Upvote to gather ideas to improve their product. These could be simple feedback from customers to fully fledged feature requests. How do you sort them out given that every week you will be receiving a barrage of feature requests? This is a common problem we all face in Product management. Most of the time these features often end up in the backlog only to be discovered later while you are cleaning the backlog.

The solution to this problem is the Kano Model. There are two steps to the Kano Model

1. Categorize
2. Prioritize

1. Categorize
   Categorize the ideas/feedback into 3 buckets
   a. Basic Features (Must have) – These are the must have defacto features. You cannot & should not skip these. If you don’t include these features, it will create customer dissatisfaction which might result in customer churn. For eg. The ability to message in an instant messaging app is a must. Sending a multimedia message may not be a must have but it’s a good to have.
   b. Performance Features – These are not necessarily a new feature but they are net success metrics. For eg. the delivery rate of a messaging platform or the low latency of a continuous feed in a social media app. These define how good of a performance is exhibited by an already existing feature or a new feature in question.
   c. Delighters – These features make the app unique and exciting. You can choose not to include these features but adding them intentionally can improve customer delight. These are not must haves mind you, but they can act as an anchor to pull new users onboard. A great example is the Augmented reality feature in many e-commerce applications where users can try out clothes or glasses virtually. Is it mandatory to have it in an e-commerce application? No. Is it a crowd puller? Hell Yes.
   
   
   

Once you bucket your feature requests based on the above categories you can now prioritize them in order of Basic Features, Performance Features and Delighters. The Kano Model is especially useful in prioritizing a new application from scratch. Unlike the RICE framework, you cannot quantify your prioritization decisions using the Kano Model. Yet it serves as a quick and reliable framework to follow.

Buy-a-feature

This is a personal favorite of mine. I have done this only once and I wish I could do this every time stakeholders are competing for their features. The idea is simple yet so intuitive that you see human motivation upfront.

The best part about this framework or technique as I would like to call it, is that you don’t really have to prioritize features. Your stakeholders will do it for you!
In this framework you set a fixed price for each feature you are planning. Some features would be expensive and some would be cheap depending on the overall effort of Product + Design + Engineering. Some would cost $100 and some $10.
You will now invite all stakeholders and give each one of them an equal fixed amount to spend on the features they want. You can use paper slips or invent your own currency as well! The overall money distributed to stakeholders must not exceed the total sum of the amount set on the features. Say each stakeholder gets $250 and the total cost of all features is $2250.

Now stakeholders are asked to purchase features using the money they have. They also have an option to pool money to purchase expensive features. Your job is to observe and take notes. This is fun to watch.
At the end you will be left with purchased features which truly matter and there would be features which weren’t sold. Tradeoffs were made which uncovered the true value of the ask.

Conclusion

The frameworks shared above are commonly used in Product. I personally use the RICE framework often. Your decisions must be defensible, and it does just that. Despite everything I have shared if the management wants something to be done asap, well – that just goes up the priority list. Compliance tasks are always prioritized as they attract monetary penalty. Choosing which one to use totally depends on your team, use case and whether you are looking at something like a road map or a quick decision framework.