What to build, what not to. Feature prioritisation and trade offs.

After years of working in IT, I’ve realised the value and the need to keep making clever trade offs. This became more evident when I decided to move to a role of a Product manager. It is an important approach to master as using it effectively will sooner or later determine the success of your product as well as of your career.

In this post I’ll discuss my thoughts about prioritisation and trade offs with real life experiences and a few points and frameworks that will help you make better decisions.

A few days ago, in a conversation with a fellow product manager, an important scenario of product prioritisation came up. After his subscription-based app was released to the store the team discovered critical bugs on the registration-page and subscription-page that were causing massive dropouts on both pages. The team, with limited resources, had to make a decision on which page should be fixed first.

My peer who was the product owner, first turned to data, to help him guide his decision. He noticed that 6% of all registrations convert to subscribers within the first 3 days. There were an almost equal amount of conversions after the 3 day metric. It was also obvious that every dropout from the subscription-page was a loss of revenue for the company.

In this case prioritising the subscription-page to be fixed first would be an apparent choice, as revenue is considered to be one of the most important metrics. However the product team decided to prioritise the registration-page first. This may sound confusing at first but following was the thought behind that decision.

By fixing the subscription-page first, already registered users would be able to subscribe, thus directly increasing revenue. However by patching the registration-page first, the team was able to capture vital user information after the fix. A few days later after both the pages were patched, the team was able to retarget and the recently registered as well as previously registered users, thus pushing them all towards a similar rate of conversion.

As a product owner you will often have to make hard decisions to prioritise certain features that will drive product success. There are many frameworks for prioritisation, and we will look at one or two later. However, besides prioritisation, you will also have to trade off certain tasks and push them to the backlog, if not take them out completely.

The key is not to prioritise your schedule, but to schedule your priorities.

There are many factors to consider while making such trade offs, but for the sake of brevity let’s talk about the most important ones.

The Product Vision

The product vision guides the roadmap of the product and envisions a future with people using your product. It makes absolute sense to refer to the product vision to make trade offs and prioritise tasks. This ensures that the decisions you make are aligned with where the company wants to see itself in the next 5–10 years.

Key Metrics along with the North star

Many organisations may prefer to have revenue or number of bookings as their north star metric. On the other hand some may prefer Engagement or CLTV as their north star or one of their key metrics.

Regardless of the preference, these key metrics act as strong indicators while prioritising and trading off tasks. For instance, A startup would focus on acquiring new users and keeping them engaged and may use these as key metrics. This gives the product team an indication to prioritise engagement tasks like social-shares etc. and keep that booking-flow-ui-update on the backlog.

Product Survival

More often than you may think, you will come across instances where you have no other option but to push a task to priority 1. Product survival forms the base of prioritisation as, neither your 5 year vision nor success metrics will matter if your product does not make it to the next financial year.

In 2020, Apple made it mandatory to have an apple-sign-in button, in all login pages where other social logins were used. They had a deadline set to mid-2020 and companies had no other option but to de-prioritise other tasks and build the apple-sign-in function into the app, as you wouldn’t be able to push product updates to the Appstore if your app didn’t have this functionality.

Prioritisation frameworks

As always, there are tons of people who’ve faced issues, and some have come up with solutions and frameworks to help others make better prioritisation decisions. Although there are many prioritisation frameworks, I’m going to talk about 2 simple ones that I use quite often.

I’m going to keep it short, since there’s already a ton of documentation on these frameworks, but I’ll add links so you can read more if interested.

RICE framework

RICE stands for Reach, Impact, Confidence and Efforts.

To use this, you take a list of features(tasks) and set them in a table. You now map each feature with the number of people that it will reach.

I usually consider the maximum reach as my products MAU. However, all features may not reach all of your users. If you have a 10,000 MAU with a 10% conversion rate and your new feature is useful only to people who have booked, then your reach will be 1,000.

Next you map the feature with its estimated Impact, and the Confidence that your team has in that particular feature. Confidence is usually mapped with 50%, 80% or 100%. Any feature below 50% confidence, doesn’t belong to this list.

Finally you gauge the efforts required to build the feature. I usually map efforts on a scale of 1–5, but you can add the number of months if you have a clear picture of the efforts.

Once you have these features listed with the RICE numbers mapped, you can calculate the score using the following formula :

RICE score = (Reach * Impact * Confidence) / Efforts

These scores now give you a clear indication on what features to prioritise.

MoSCoW framework

The MoSCoW framework boils down prioritisation to some very basic steps.

M — Must have : These are non-negotiable features that are important for product survival. They take number 1 priority.

S — Should have : These include key features that may not be crucial but will have a high impact once completed.

C — Could have : Nice to have features that could help deliver customer delight and impact on a lower scale.

W — Will not have : Features that will not have a high impact, and usually something with huge efforts, could fall under this bracket. These are usually features that could be moved to a backlog or dropped out completely.

Thank you for reading. Please share this if you’ve learnt something new today.