Feature prioritization

We, as product managers, generate innumerable ideas. Somehow we prioritize them in our head. My head is bursting, we don't know what to do with these ideas. In your “list of ideas” some kind of hell is going on ... This is especially familiar to people who are just starting their way in business, or just starting their way with products.



This article will help you quickly (on your fingers) throw away most of the hundreds of features. And leave only those that really benefit the business.



First, consider the variable table of prioritization methods:







Based on this table, we can draw a conclusion.



Horizontally, there are internal prioritization methods that are resolved within the company - the team.



If users participate, then, accordingly, they are external.



Vertically, how much data is there for making decisions.



Quality when you do in-depth interviews from dozens of respondents. And quantitative when there are many different analytical data.



External methods are applied:

When the product has just been released, and we do not yet understand the deepest needs of the consumer.



When there are key departments within the company that make decisions (analytics, marketing, sales, stakeholders).



Internal methods are applied:



When there is a history of which functionality changes metrics, you can do prioritization within the team.



Refinement of the results obtained from external methods;



We've covered the main differences between internal and external methods.



Next, we will look at prioritization methods such as fast (fingertip) and slow .



The fast one allows you to discard the most not valuable functions, and the slow one helps you choose the best from the remaining ones.



Fast methods



Reach / Frequency method



Reach - audience reach. How many people are willing to use the feature.



Frequency - the frequency of using the feature.







Ideally, we want the top right corner. Those who use it all the time and the whole audience.



Poker planning method



The idea is taken from Agile methodologies. ( Evaluation is done within the team. )



Evaluation of the benefit of a feature The



team is given the following condition: 1 finger is a bad feature, 2 fingers are a feature of norms, 3 fingers are a feature just a bomb.



You say a feature and on the count “one, two, three,” the team members raise their fingers. Consider the average score. (You can invite external people from other projects).



Estimation of costs



We collect developers, talk about the functionality and also set the condition: 1 finger - they will quickly do it. 2 fingers - development will not be difficult. 3 fingers - the development will be very difficult and time-consuming.



Next, we divide the benefit by the cost and get a rough estimate of the functionality.







Feature 4 has the highest percentage, which means it will definitely be at the top of the prioritization table. Feature 2 has the lowest percentage - we definitely throw it out of our backlog.



Slow methods



RICE



Developed by intercom.



This is a method of prioritizing ideas and product features that includes 4 factors that the product manager uses to evaluate and prioritize features:







Reach - audience reach. Do not forget that the coverage of exactly those people who will see this feature.



Impact - the impact of a feature on the user. His joy, boosts, emotions from this feature. (0.25 - very bad, 0.5 - bad, 1 - average, 2 - good, 3 - excellent)



*** Some people think that impact is exactly the effect of a feature on a company. That is, how many metrics will we raise with this feature?



Confidence- Confidence in the hypothesis. Quite an important parameter that shows how good you think the hypothesis is, because we don't always come up with super-top ideas. (High = 100%, Medium = 80%, Weak = 50% and below)



Effort - Development complexity. Usually indicated in months. (half a month 0.5)



ROI prioritization



Initially, you need to create a hierarchy of metrics. If your product is not Amazon or google, a tree structure is more than enough. What comes from what. For example, Life time Value directly depends on Retention. Excellent! This will be enough for an online store. Further, by analogy, depending on the scale of the product, you can use analytical data and make formulas.







It is very convenient when you have an idea, to know which metric it will affect. And understand at what level the tree is. And the closer the invented feature is to the main metric, the more profitable it is. The further, respectively, there is almost no chance that it will affect the main metric.





An example of prioritizations from the metric hierarchy







With the team, we assign the “weight” of the feature, how much who believes in it. + is placed on those chosen by the majority. You can focus on them for the next six months.



ROI prioritization example







We have the number of users per year. We forecast that 70% will use the product and 50% will purchase the product.



I estimate that the introduction of the feature will bring the company 4% of the profit.



Knowing how much profit we have from one payment, by simple calculations we get the amount that our feature will bring in addition for the year.



Then we go to the developers and understand how long the development will take. We translate everything into human hours and get the development cost.



With this data, we can calculate the ROI ((income - expenses) / expenses * 100%) of the feature.

Thus, we can count all the features from the backlog and prioritize it.



***You can also make a more detailed study of the table with Real% conversion, pessimistic and optimistic.



Pros:



You get monetary value. People love money.



People believe numbers.



Cons:



Absolute values ​​are not taken into account

Much depends on the personal skills of the product manager.

Small features are not clear how to count.



Nuances:



Calculate profit, not revenue.



Typical mistakes of product managers



1. Evaluate alone.



Always ask someone to check your calculations. A fresh look is always good;



2. Do not take into account the effect of one part on other parts of the product.



It is very important to think about how the whole ecosystem works so that other parts of the product do not sink;



3. Become a hater.



There are always haters who use the product, but they are always not happy with something. The main thing is not to be confused between ordinary haters and people who want to help the product. Do research deeper;



4. Quantitative assessment is not always better than qualitative assessment.



If the product is new, or not great, it is best to communicate with your audience and understand their deeper needs.



5. Dig into the little things. Look at the product from above!



Outcome



Summing up, I can say that the prioritization system that works in Yandex is unlikely to work if you want to apply it to a startup that employs four people.

Companies are different, they have different goals, different tasks, different positioning and position in the market - someone barely makes ends meet and it is important to make money literally tomorrow, otherwise the start-up is over, and for someone money is no longer so important in comparison with the situation in the market or reputation, someone has money for scaling and the main task is to attract new users, while someone cannot scale due to infrastructure limitations and wants to reduce the number of users, but earn more money from existing ones. In general, not everything is so simple.



Thank you for your time.



All Articles