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 RICE framework, MoSCoW technique, value vs complexity quadrant, Kano model 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.
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 The Product Management Triangle which talks about three major stakeholders for a product: 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.
- Users: For the stakeholder user, 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.
- The Business: For the stakeholder business, 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.
- Developers: For the stakeholders developer, choose a metric which measures the effort from developers e.g. Complexity, ease of implementation, story points etc.
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, lower the prioritization points, higher will be the priority of the feature. Thus, we will build e-book reading feature first.
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, higher the prioritization points, higher will be the priority of the feature. Thus, we will build e-book publishing feature first.
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.