Prioritization of features when the world is excited for you to build everything.
One of the most difficult thing about building software, is building the right software. Identifying who your stakeholders are, what do they want.. no no as in what do they really want, not what do they think they want, separating wants from needs, and removing your own set of assumptions and biases so you can sit together with UX and Engineering, to build the right product. It’s an absolutely difficult task and requires several times of falling on your arse and failing to get it right, maybe. It doesn’t have to be that way and I am not a believer in learning through failing. I do believe however, that you can learn from your mistakes and that you cannot always have the 100% right answers, but you can get close to it, if you approach it carefully.
Unlike software, relationships with humans (your stakeholders) are not undo-able. Therefore saying no to someone can be an extremely difficult but necessary task. Specially when it comes to building software. During your first release or at pre-release chances are you will receive requests for features from most people. But applying the Pareto principle (80–20 rule), where you are trying to have an 80% impact on your stakeholders and growth by solving 20% of the right problems requires careful examination of each of the tasks. I am a big believer in keeping software features to a small set. Build few things in your software, keep it simple, solve the problems that will have impact on 80% of your customers, ignore the edge cases (for now), but do them extremely well. You must not ever comprise quality for quantity.
So how do you go about this? How do you prioritize feature requests such that you can send out the appropriate no’s and yes’s?
I have been facing the same problems with some of the projects that I work on and to be completely honest a lot of prioritization skills come through experience. However, there are techniques and processes that can help you with this as well.
Few days ago, I sat down with one of our PM’s and he introduced me to the technique of RICE prioritization.
RICE is a prioritization technique that was originally introduced by Intercom (correct me if I am wrong). Here is the blog post about it from Intercom (I highly suggest giving it a read):
It’s a prioritization technique, that can seem trivial and obvious at first glance, but the things it talks about I have found are usually ignored by lots of people in the product world for no good reason. In the excitement of building new things, people loose sight of building the right thing. As a side step, this is also a skill I try to look for when identifying great product managers. It’s that they seem to be able to maintain a level of calmness and are able to separate their emotions, even when every around them is just itching to build new things.
So back to R.I.C.E. It stands for:
Reach
Impact
Confidence
Effort
These are the 4 things RICE encourages you to talk about and give a number to it such that you are able to prioritize based on total scores with all of your team mates. Similar to several analysis tools your probably learnt in project management school. Here is a breakdown of it, basically a TL;DR of the actual blog along with few additional points that I like to talk about.
Reach:
The feature/product in question, how many users will this affect during the first few months that it is available? Are you able to quantify it? If not FIGURE THAT OUT FIRST.
According to Intercom, reach is measured in number of people/events per time period.
Impact:
Of the people that your product/feature will reach out to, what is the impact it will have on them? I also like to ask the question is it an actual noticeable pain point that you would be solving with this? It’s hard to measure impact so keep it in a simple non-granular score (more details in the above link)
Confidence:
This is where you separate enthusiasm from the project. How confident are you about your estimates? Do you actually have data to back it up, or are you just making assumptions?
Effort:
How much effort will this feature or product take? Do you have the right resources? A product/feature that will take a year to build but has major impact is perhaps not as great as a product that will take weeks to build but has a mid-level of impact?
The technique wants you to assign numbers to each and at the end use the RICE score to prioritize (read the blog post! to get full details!)
While I don’t particularly care about the final number the technique spits out, and don’t always use it to base my decisions. I have found this technique to be an incredible conversation starter within the team and it helps everyone get aligned and on the same page. This allows you to get opinions of people in a structured manner and you can then further refine what you have learnt and your new found information to further figure out what you should be building.
Never rush the process of identifying the “what” before you start building.
CREDITS:
Credit goes to Intercom for sharing their technique with the world. It has been of great use to me. Thank you.
https://blog.intercom.com/rice-simple-prioritization-for-product-managers/
