One of the important tasks as a Product Manager is to prioritize. Deciding on what (and when) to do is a critical job for the role of a Product Manager. This post is NOT about the importance of prioritization and why prioritization is a perennial challenge for a product manager. This post deals with a generic framework which a Product Manager can easily apply for prioritization. There are lot of techniques and framework available for prioritization like , , , etc. But there are situations when we don’t have enough data to use a particular framework or the particular framework itself is not applicable exactly. Instead of using the framework, we tend to fit in the framework to get our answers. This led me to the quest of deriving a simple generic framework for prioritization which can be used in most of the scenarios. RICE framework MoSCoW technique value vs complexity quadrant Kano model In order to get to that, I went back to the drawing board and started with the fundamental elements in a software product’s context. For reference, I looked at Daniel Schmidt’s which talks about three major stakeholders for a product: The Product Management Triangle users, business and developers. So essentially while doing the prioritization, we need to consider these three stakeholders. Step 1: Choose a metric for each stakeholder First step is to choose a metric that represents each stakeholder. Now this metric may vary from case to case, but it would be common for a stakeholder across features which needs prioritization. For the stakeholder , choose a metric which measures the impact of the feature on the users e.g. NPS, average visit time, stickiness ratio, app store ranking, retention rate etc. Users: user For the stakeholder , choose a metric which measures the effect on the business objectives e.g. Revenue, MAU/DAU, average revenue per user, average order value, customer lifetime value etc. The Business: business For the stakeholders , choose a metric which measures the effort from developers e.g. Complexity, ease of implementation, story points etc. Developers: developer Step 2: Assign a co-factor to each stakeholder Next step is to assign a co-factor to each stakeholder, depending on contribution of that stakeholder towards the overall vision of the product, the current objective and the goal. Suppose the objective is to take the product to the market as early as possible to gain the first mover advantage, then the co-factor of developer stakeholder would be the heaviest. Step 3: Calculate the prioritization points And the last step is to multiply each factor with the stakeholder metric and calculate the prioritization points. Priority can be decided on higher or lower prioritization points depending upon the current objective Figure 2: The Prioritization Matrix where, Please note that the metric value can either be an exact value or the relative value. The focus should be on prioritizing the features not getting the value of prioritization points Let us take a simple case. Suppose we want to build an e-book app which allow users to read and publish e-books. Feature 1: E-Book reading— A feature which allow user to discover e-books and read them by downloading the e-book Feature 2: E-Book publishing — A feature which allow user to write memoirs on the go and ultimately compiling it as e-book and allows publishing the e-book over the platform Let’s choose a metric for each stakeholder User: Expected number of users Business: Expected revenue in $ Developer: Story Points Absolute Prioritization The prioritization matrix would look like as follows: Figure 3: The prioritization matrix for the case Suppose the current objective is to take the app to the user as the earliest. Hence the developer stakeholder would have the heaviest contributing factor in the prioritization decision. Figure 4: The prioritization matrix if the goal is to take the market earliest In this case, Thus, we will build e-book reading feature first. lower the prioritization points, higher will be the priority of the feature. Now suppose the current focus is the revenue. Hence the business stakeholder would have the heaviest contributing factor in the prioritization decision. Figure 5: The prioritization matrix if the goal is higher revenue In this case, Thus, we will build e-book publishing feature first. higher the prioritization points, higher will be the priority of the feature. Relative prioritization Sometimes, it is difficult to define the metrics in absolute value because of lack of available data or the nature of the metric itself etc. In such cases, one can still use the prioritization matrix but instead of calculating prioritization points, one can calculate relative priority. Let us take the above case Figure 6: The prioritization matrix with relative metrics Here A denotes higher and B denotes lower. Since the current objective was higher revenue, Business stakeholder had the heaviest contributing factor and hence e-book publishing feature takes more priority. The simplest method of prioritization is to keep in mind the impact on each stakeholder of the product on building that feature; the overall objective/goal and contributing factor of each stakeholder in achieving that objective. I’ve been using this technique for quite a while and surprisingly it has worked for me for almost all the use cases. Please do leave a comment if you find this technique useful. And please don’t hold back if you have any feedback to make this technique better and more useful.
