Prioritization: what to do before you start to prioritize work
Over the past couple of years, product managers have been pushed towards a more strategic role. Now more than ever, they are key in the decision-making process when a new product or service is built. But change takes time and is hard, and old ways of working remain ingrained in most organizations. When I talk to product managers and senior leaders, the topic of prioritization is mentioned a lot.
But when we dive deeper into what is actually hurting them, the problems tend to be slightly different from the ones that are stated. So, let’s first discuss prioritization.
What is prioritization?
Simply put, and in this context, prioritization is the ranking of work. The question then becomes, how do we define what factors contribute to the priority of a task?
Prioritizing something is an easy fix, and we all know data is driving the world. We define the parameters, weight them and create a formula that calculates priority. The only thing that we need to do is input the raw data that allows the algorithm to compute and – voila! – we have a prioritization list.
Easy right? So why do businesses keep struggling with prioritization? The problem is twofold:
- Businesses do not have the data necessary to allow a simple formula to solve the issue for them. The decision making is done by product managers or product owners who are far removed from value conversations (and sometimes even customer related conversations).
- A simple formula is not that simple. The number of variables that allow for a prioritization model that doesn’t miss anything, is very high and would be very complex. When context changes, the formula changes. But context changes fast and building a formula that accounts for it is anything but simple.
Both points above relate to the same root problem. Product Managers need to be closer to the business and the customer if they want to make better decisions.
So, what do people mean when they say they need to prioritize ‘better’?
The best way to explain this is to share a real world example with you. A client told me that they needed to learn how to prioritize. One of their teams had developed a service for their existing clients that had a very poor uptake. Let’s say that the service was a way to access tailored data.
The market had already shown that it was not interested in that model. However, the team proceeded to develop the same service for all other data sets. Effectively creating a number of services that weren’t actually going to be used.
Well, prioritization is an issue here, but it is certainly not the issue. We can use a traditional 2×2 matrix of impact and effort or a sophisticated prioritization mechanism but, there’s something that precedes prioritization. The understanding of why we are building something, be it a product, service, or feature.
Had they done user research or tested the business model, they would quickly see that the user was not interested in that model. If the team weren’t feeling confident just through user research, a prototype would clear most of the doubts. That information would also allow them to build an economic model for the idea and put it against other ideas.
How quickly can you do user research and prototyping? In this case, it would take only a couple of days to reach the conclusion that it wasn’t worth the investment.
Before thinking about prioritization of work…
What we need to understand is that we can’t really prioritize until we have the data to input into our ‘formula’. That data can only be collected by doing the work that precedes prioritization companies are looking for. While the sophistication of a formula is welcomed and reassuring, often it’s not what we actually need, a simple look over an excel spreadsheet with the data that was collected can be enough to make informed decisions over priority.
If we solve the right problems in our flow of work, we improve the entire process. By solving the wrong ones, we reinforce the problem.
If you want to prioritize work, make sure that you have a prioritized process and structure to collect the data that you need to do it, and that the data is actually collected.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
