A very common challenge faced by Product Managers of all experience levels is understanding and implementing some form of repeatable process around prioritization. Some people take a very light approach, making decisions based on their own experience, data, and beliefs about the direction of the product. Others take a much more rigorous approach, applying scorecards and “objective” measures across a plethora of different possible metrics. I’m here to tell you, there’s nothing wrong with either of those approaches, but it’s also become clear to me in my years as a Product Manager that there’s no “silver bullet” to ensure that your prioritization decisions will be right more often than they’re wrong, and placing too much value in systems and scores often just results in a false sense of security that the “process” was right, when digging in you’ll find that those “objective scores” are nothing more than a system to be gamed. There are, however, three things that I think every prioritization system needs to take into account. So, without further ado, let’s discuss value, difficulty, and instinct…
Prioritization is About Value
If we think about the primary problem that we’re trying to solve with our prioritization efforts, it should be that we’re trying to deliver the most value possible, as quickly as possible, that benefits our end users and our customers. If this is your goal (and if it’s not, shame on you!), then one of the most important factors to consider in your prioritization efforts is the value that something will actually bring to the table. Some people score this with a numeric value, others use a monetary value — whatever works, so long as you’re actually considering how much value your efforts are supposed to deliver. However, basing your decisions solely on market value can often result in deprioritizing technical debt and infrastructure investments — please, for the love of whatever deity you believe in, do not fall victim to this. While technical debt and infrastructure might not have obvious customer value, failing to adequately invest in them will cause your product to fail at some critical point for some critical customer. If you’re using customer value as the sole or primary metric, please ensure that you have an entirely separate track of work that allows you to pay down your technical debt and invest in infrastructure improvements. Trust me, you’ll breathe much easier knowing that there’s not some unknown debt item that’s going to cause everything to come crashing down at the worst possible moment.
Prioritization is About Difficulty
While customer value is important, it’s equally important that we understand the amount of work that’s going to go into any feature or improvement to our product. It doesn’t matter if the value to the customer is insanely high, if you’ll never actually get through the work to deliver the improvement in time to capitalize on the opportunity. All too often, Product Managers make judgment calls about how “big” something is without involving anyone from their development, support, or delivery teams — this is a rookie mistake that Product Managers with 10+ years of experience make all the time (yes, even I do this sometimes). Assessing the amount of effort required to bring any feature or capability to life is most accurate when it’s done by involving the people who will actually be working on it — they know their abilities better than you do, they know the technology better than you do, they know the existing code better than you do, etc. This doesn’t mean that you have to break everything down to tasks, or even user stories — but it does mean that you need to consult with your technical teams to have the best idea about how “big” something is, or how long it might take to make happen. When we’re tasked with assessing the difficulty of solving a problem, make sure we’re relying on input from the experts and not merely using our own opinions, which will be wrong more often than they’ll be right.
Prioritization is About Instinct
Objective, quantitative data is an amazing input into any prioritization process — and the more data you can get, the better your decisions are likely to be. But there’s also an ineffable quality to prioritization that is what makes the whole process more art than science. To be honest, if all it took was objective data dumped into a spreadsheet that pushed out a score then you wouldn’t really need Product Managers to drive prioritization efforts. You’d have an AI system that looked at your ideas, took all the available input, and told you exactly what to do and exactly when to do it. Fortunately for those of us who have decided on Product Management as a career, this is not the case — there’s always going to be some subjective analysis involved in looking at the data and making decisions about whether or not the direction the data is pointing actually makes sense in the broader scheme of things. I’ve worked in environments where decisions were made by some Six Sigma, spreadsheet, “objective” data process — and this wound up pushing updates that nobody wanted, nobody cared about, and worst of all wasted engineering resources. The Product Management team knew there were better options, knew there was other subjective data to support those efforts, but were forced to sit back and “let the system work”. But it didn’t work, because it ignored the total experience that great Product Managers bring to the table. A great Product Manager knows when to insert instinct and experience into the equation and shift or rearrange choices made solely on “objective” data. Without an instinct, without a gut-feel, only the safest choices will be made, and innovation will go out the window.
