On Product Prioritization
When it comes to prioritisation, common knowledge is that “customer comes first”. But your customers are diverse and they have very diverse needs — support team needs bugs fixed, marketing team needs to integrate new tools into the product, tech team wants to change the underlying stack, operations teams have their own requirements and most importantly, the end user of your product has his requirements. Juggling everyone’s requirements gets daunting. You find yourself falling into the trap of following your customers instead of leading them to the right product.
Perhaps the approach to prioritization needs to be a bit more scientific than “customer comes first”.
I believe that a product manager needs to do just by three stakeholders –
- the business: any feature that does not contribute to business objectives is futile
- the developer: this is the most scarce resource you have
- the end-user: this is the most demanding entity in the eco-system
The business is your top priority
The process of prioritization necessarily needs to start from the business. Good product managers at all times understand their organization’s business processes very deeply. They are in touch with what other teams are doing on the ground and are aware of what’s working and what’s not. They know which levers need to be pulled to tilt metrics in the organization’s favor. A strong product team works closely with the CEO’s office to understand and align on company’s top priorities. Without this, most product prioritization is moot. Imagine a scenario where the organization is struggling to increase revenue, while the product team is making the “Search Bar” more intelligent. It doesn’t quite fit. A PMs top priority necessarily must be the business and helping it achieve its goals. This is both the toughest and the most important objective.
Alignment across functions
The difficulty is further compounded when Product Managers have to work with other functions in the organization (needless to say, this is often the case) and if these functions have conflicting goals. Product Leaders need to put in the effort to identify key metrics that must to be pushed and evangelize these metrics within the org to ensure alignment in execution. For instance, let’s assume that your company’s top priority is to increase revenue. The strategy identified is to launch a new category and to improve conversion on existing categories. It is important then to identify the metrics that will reflect movement on this strategy and to ensure that all functions in the organization are working relentlessly to push the same metrics. In the absence of such alignment, most feature requests you will receive from within the org, will be tangential to what the product really needs.
80–20 Rule
Having aligned with the business and the org, the next most important piece to manage is developer time. How do you prioritize among features to most efficiently use developer time? I like to apply the 80–20 rule here. I prefer prioritizing features that have 80% of the impact with 20% of the effort. General prioritization order I follow:
1. P0 bugs are always prioritized; core loop shouldn’t break, acquisition and conversion should never break
2. High business impact, low effort features are always prioritized
3. High impact, medium effort features are prioritized next
4. High impact, low effort is prioritized over higher impact, medium effort feature which is prioritized over higher impact high effort feature
5. Feature requests that don’t have significant business impact are never prioritized over features that do
Despite these rules though, prioritization can become difficult when you have to choose between building for current requirements versus building for the future.
I prefer building for the immediate future (think 3 to 6 mths time frame). You need to have a long term vision in mind, but you need to execute for the immediate future, inching closer to your vision a little at a time. I always avoid features that will take months to build, unless absolutely critical (e.g. new product launch). This is especially relevant in a setup where you have quarterly or half yearly targets. You just can’t prioritize a feature that will itself take 6 months to build.
More importantly, the eco-system also deters you from doing it — technology will have changed, competitive landscape will have changed and your customer will have evolved significantly.
In Summary…
Being able to prioritize well requires a high degree of self discipline. Customer needs have to be filtered through the “business lens” to ensure you take an optimal decision. The objective is not to meet customer’s needs assuming it will help achieve business goals. Instead, it is to understand business objectives and design features that meet business goals by appealing greatly to your customers.
Note: The process of prioritization changes significantly when launching a new product. More on that in another post
