Prioridad: A practical framework for product and feature prioritization
Updated on Mar 14, 2021
tl;dr: Prioridad is a proven framework for prioritizing new product functionalities, product design flaws (chores), and bugs. Priority is best calculated this way: Multiply the effect of the effort in your core KPI by the chance of success, and then divide it by the complexity of the implementation.
One of my favorite 'demotivational' posters has a picture of the pyramids of Giza with ‘Achievement' as title beneath it. This somewhat sardonic but very telling explanation follows:
You can do anything you set your mind to when you have vision, determination, and an endless supply of expendable labor."
Unfortunately for us — and I mean us as product managers — while we may have vision and determination, chances are good we’ll lack an endless supply of expendable labor (and time too, for that matter). It’s why we need to prioritize the efforts of our teams. We must identify the low-hanging fruit: the efforts that are easily achievable and don’t require much sweat when compared to the impact we can expect from them.
A few years ago, I compiled an early version of this framework. I put it to the test with teams at various companies, including Voice123, Bunny Studio, and Torre. After years of tweaks, improvements, and validation, I'd like to share it publicly. I call it Prioridad.
New functionalities, chores, and bug fixes
As a product manager, you and your team will usually work with three types of tasks: new functionalities, chores, and bugs. Bugs are flaws in your product that cause unexpected behavior when compared with the specs. These flaws are usually introduced by engineers. Chores are fixes for flaws in product design that resulted in a poor user experience. Such flaws are usually introduced by product managers or product designers.
First, you need to determine how you’ll prioritize among new functionalities, chores, and bug fixes. This will heavily depend on your business’s nature, the stage of your product (pre or post-product-market-fit), the size of your team. Two common ways of doing it are prioritization based on product excellence and prioritization based on time allocation.
Prioritization based on product excellence
This prioritization is based on the premise that having a product as flawless as possible is essential. This is frequently the case for companies where the product is the business. For example, SaaS and video games. Here, the prioritization is easy:
- You always address bugs first
- You then work on chores
- And only then you work on new functionalities
This applies to both product and engineering team members.
Pre-product-market-fit products are an exception to this rule. There, both the product and engineering teams most likely should — by default — be focused on implementing the new functionalities required to reach product-market-fit. Chores and bug fixes tend to be addressed only afterward.
Prioritization based on time allocation
This prioritization is based on the premise that having new product functionalities is essential even if the product continues having some flaws. This applies to companies where the product is an enabler of the business rather than the business itself. For example, online marketplaces (where users come for the network of buyers or sellers instead of coming for the product powering the network) and online stores (where users come for the items being sold, rather than the shopping experience).
Here, you can try to distribute your efforts evenly between the three types of tasks. To do that, split the time available to product and engineering teams into three-week cycles:
In some cases, though, this cycle won’t cut it. For example, when you’re implementing a complex feature or paying a significant amount of technical debt (note: the engineering team can also pay technical debt when implementing chores and new functionalities, but sometimes it is valuable to assign specific time to it).
By the way, both these cycle works well with the Experimento framework, scrum, and others.
Regardless of the way you go, each group of tasks, new functionalities, chores, and bug fixes, has its own prioritization logic:
Prioritizing new functionalities and chores
The Core KPI reflects the core interaction of the product. For example, in the case of Bunny Studio, the core KPI is number of projects fulfilled. In the case of Voice123, the core KPIs are projects submitted and messages submitted. Effect-in-core-KPI is the delta (the difference between the after and before) expected on that KPI once the new functionality or chore is implemented. Effect-in-core-KPI could be estimated in terms of the absolute number of core interactions over a time period, the revenue associated with them, or their respective percentage. Some examples of units include:
- 50,000 verifications/year
- $500k in projects/month
- 20% of verifications
- 20% of revenue from projects
Alternatively, Effect-in-core-KPI could be an index calculated by taking several other factors into account. Factors are multiplied or added depending on whether they compound each other or not, respectively. If added, all factors need to be normalized to a common scale, for example, 1 to 10, before adding them.
For example, at Torre, most teams analyze these compounding factors for each new functionality:
- Relevance to the job-to-be-done of the user (measured on a scale from 0 to 10. 0 for ‘it doesn’t solve the job-to-be-done’. 10 for ‘it will always solve it’.
- The total addressable market of the new functionality (measured in the number of people that could use it)
- Wow-factor (measured on a scale from 1 to 10. 1 for ‘Meh’ , 10 for ‘as impressive as the first time I saw the iPhone’)
- Conversion improvement (increased likelihood of visitors becoming registered users, measured on a scale from 0 to 100%-or more)
- Value perception speed (measured in 1/d, where d are the days it will take new users to perceive the value after they registered)
- Engagement (numbers of potential interactions per week)
- Virality (how many new users can we expect a new average user will bring to Torre during their first 30 days)
- Viral speed (measured in 1/d, where d is the number of days it will probably take a new average user to send the 1st invite to others)
- PR potential (measured on a scale from 1 to 10. 1 for ‘Meh’’, 10 for ‘first landing on the moon’)
While these factors apply to most teams at Torre, they don't apply to all teams. For example, the SEO team uses other factors such as monthly searches, competitiveness, user-generated content, etc.
Chance-of-success is an estimate on a scale from 0 to 100% and tries to capture the certainty of the effort yielding the expected effect on the core KPI. Initially, it’s a wild guesstimate. Its uncertainty can be reduced later on via prototyping and split A/B testing.
Implementation-complexity tries to capture the level of effort required to implement the new functionality or chore. Ideally, this estimate is influenced by the opinions of the product manager, product designer, and tech lead. The value can be work-hours or a Fibonacci scale.
For example, an effort expected to increase the core KPI by 30%, with a chance of success of only 10%, and 15 hours of work required, will look like this:
Regardless of the units and scales you choose for each variable, it’s important that you always use the same ones for all new functionalities you’re prioritizing.
Prioritizing bug fixes
One of the most important factors when prioritizing bugs is whether or not the bug blocks the user. In the context of this guide, a user is blocked when s/he can't continue through the expected funnel.
- Highest: bugs that block most users from using the product
- High: bugs that block a few users
- Medium: bugs that most users experience and don't block them
- Low: bugs that a few users experience and don't block them
Practical tips
- Always prioritize using the same formula. Prioritization only works when the same formula is used to compare multiple efforts.
- Add the priority value to the title of each effort. This will make it easier to sort your project/product management board by priority.
- For each effort, document the math, who did it, and when it was calculated. This will make it easy for others to question your assumptions and better understand your expectations. It will also help you identify whether the estimate may be outdated and need a refresh.
- Develop your intuition. After doing this math hundreds of times, you'll start developing an intuitive ability to prioritize efforts without doing the math manually and still have a high level of accuracy.
Additional reads
This Quora thread offers a wide selection of approaches to the same topic. Chapters 22 and 23 of Inspired by Marty Cagan, proposes prioritizing outcomes (results) rather than outputs (functionalities).
Related frameworks
- Experimento: A practical product management framework
- Usuario: A practical framework for user research and testing
- Indicadores: Performance indicators for online platforms (a template)
- And more…
Thanks to Jorge Vargas and Lucho Molina for sharing knowledge with me that is now at the core of this framework. Thanks to Andrés Cajiao, Carel F. Cronje, Daniel García, Daniela Avila, Luisa Moscoso, Renan Peixoto, and Tomás Gutiérrez for reading and commenting on drafts of this article.
