Prioritization Frameworks for Product People
Prioritization Frameworks for Product People
Prioritization frameworks RICE and Eisenhower matrix
In today's edition of The Discourse, we're going to talk about how important is prioritization, and how to get there. What happens when you exercise the prioritization muscles?
Lots of things to unpack. Before we get started, subscribe if you're new here:
Why Prioritize?
Time is the only finite resource.
This is true for founders, product people, makers – or anyone who is building products to solve customer's problems.
What happens when you don’t prioritize?
When everything is a priority, nothing is a priority.
As human beings, we work sequentially. Multitasking is a myth, and when we try, there is a context switching cost.
This makes prioritization super important.
There is also an opportunity cost of time. In simple words, it is the value of the next best option you give up whenever you make a decision.
Let me explain with a simple example:
I could build a feature A in my product that generates $30,000 in revenue. Whereas if I would've built this other feature B, it would have generated $100,000 in revenue. Now, the opportunity cost for building feature A is actually -$70,000.
This makes the skill of prioritizing high leverage.
But there is a right way and a wrong way to prioritization, which we'll get to in a bit.
How does it help?
If you want to increase the likelihood that each feature that you add to a product becomes a hit, then you need to ensure that you are making the right product decisions.
So will you get the decision bang on all the time? No.
Because you need to generate and maintain momentum through a series of quick wins. Momentum is definitely underrated when it comes to building products.
Although a week or two of missed momentum might not seem like a lot, but when you have many of these in a row – then it’s a problem.
Is it cumbersome?
You might say - I would rather do things than plan. And I don’t disagree – overplanning and overestimating is a useless exercise. But there needs to be a method to the madness.
“The more you sweat in training, the less you bleed in battle.”
What to prioritize?
You should prioritize problems and needs. Features are nothing but solutions to the problems. Furthermore, some problems will be more painful than others.
And you know it is a real problem if the user has already tried solving it, but that solution was ineffective or too costly.
If you're prioritizing features, always understand the problem that is being solved behind the feature.
How to prioritize?
You could prioritize through gut, but people tend to overvalue this ability.
If you're not data-informed, then the decision may not always be optimum.
In this case, using a framework adds objectivity that can be debated on its merits without looking at the person.
The Eisenhower Matrix classifies tasks into Important vs Urgent.
But we still end up classifying a P1 or a P2 according to the urgency of the feature. This results in the important but not so urgent tasks to be constantly delayed.
Downsides to the Eisenhower matrix is that it doesn’t drill deep into importance. What makes something important? How sure are we that this is important? And what’s the difference in effort between two options.
In order to balance this further, a better framework that I have come across for feature prioritization is RICE (or some variation of it)
RICE = (Reach x Impact x Confidence) / Effort
Reach
How many people will use this feature in a given time period?
Will this touch all the active users? Or a subset of them? How often? Is it a one-time action or a daily action? For e.g., approx 100 customers within a month use Feature A every day in a month, and 200 customers use Feature B only once a month.
Impact
Now coming to Impact – how important is that action leading to a core metric?
The metric could be whatever you chose under acquisition, activation, engagement, retention, or monetization.
For instance, if your goal for the month or quarter is to improve the activation rate, then A feature in the Profile screen might be way less likely to move the needle than a feature in the onboarding flow.
You will achieve this target metric by removing some user annoyance or reinforcing positive behavior.
The scale is usually a T-shirt sizing. VH (3) High (2) Medium (1) Low (0.5) VL (0.25).
Confidence
How confident are you that this feature will succeed? And more importantly, what is the source of your confidence?
Is it intuition? Is it feedback from one prospect or a customer? Or is it through a combination of product analytics and user interviews?
All of the above will define the likelihood of success.
This chart on confidence by Itamar Gilad is really helpful. You should bookmark this and keep coming back to internalize it.
This chart should serve as a heuristic, but you can create your own confidence charts to keep it simple.
Something like High confidence (100%) Medium (80%) Low (50%) should work.
And once selected, you just have to keep the scaling consistent.
Effort
How much effort will it take to ship this feature?
This is done to identify time-sinks with a low probability of success. This is especially true for early-stage companies where you have limited resources, and you want the maximum bang for the buck.
This is calculated in person-hours or person-days. Mostly engineering effort, but could include other aspects too.
For e.g., Feature A takes 8 hours to build, while Feature B takes 36 hours. Now, considering other factors, we can make a more informed decision.
What Stage the Product or Company is at?
Now, depending on the stage the company or product is at, you'll have to tweak things. In the early stage, you neither have much product analytics data nor do you have a lot of customers. You don’t have a lot of signals about what to build.
The first goal is to start building these lines of signals where you start getting feedback. This can be achieved by talking to a lot of users and customers and collating their feedback in a commonplace.
Since time is at a premium, less time can go in planning.
In that case, once the goal is identified - the variation of the RICE matrix to follow is the Impact vs Effort matrix.
In the beginning, the goal should be to deliver value to the customers in timely increments. So, focus on the quick wins first which are low effort – high impact. This creates trust in the customer, and you will be able to work on the high effort – high impact ones after that.
Hunter Walk writes that you should not focus on too many low effort – low value tasks. He calls this snacking. I agree that there is a tendency to cover all the smaller items first, but they might not provide enough value.
Include it in your workflow
I've found the best way to ensure that you follow this prioritization framework is to include it into your existing workflow.
Here's a Notion template that will help you and your team follow it. You can duplicate it for your own workspace.
This table can then be included in the Sprint planning docs that you follow.
So when you're looking at your next set of features, you should always ask the question - what to do first?
That's it for today. Thanks for making it all the way to the end. How do you prioritize? Comment below and I'll be happy to discuss it with you.
Talk to you soon!
— Kavir
P.S. Hit the subscribe button if you liked it! You’ll get insightful posts like this directly in your email inbox every week.