When planning a roadmap, product managers must sort through myriad possibilities and balance competing factors in order to decide what comes next. They have to prioritize—and while prioritization frameworks are useful in guiding your thinking, they aren’t silver bullets. If you trust in them completely, you’ll either end up either building the wrong things or jumping through hoops to justify your work.
Janna Bastow, CEO and Co-Founder of ProdPad, recently tackled this subject in a Product Management Today webinar. Read on to learn about the pros and cons of different frameworks and how to prioritize features without depending on any single framework.
Why is finding a prioritization framework important for product managers?
Janna Bastow: It’s the product person’s job to define what’s being done next and to rally the team behind those priorities. Prioritization, at its core, is about sorting out all those competing demands. It’s a frustrating job, so it’s only natural that we look for ways to make this job easier—to simplify it.
How do you define a prioritization framework?
At its best, a prioritization framework is a way to shape your thinking, to give you a common lens or angle so you can introduce some element of consistency in your work. They’re meant to augment our ability to think, not replace it. But at their worst, they can be tedious. A good product manager should have a wide range of frameworks in their back pocket, and the experience to know when to use them and when to let go.
What are some of the common prioritization frameworks?
One of the most common is none at all! Some people are prioritizing with nothing more than our instincts, and there’s actually nothing wrong with this. It doesn’t mean you haven’t been doing product management. It’s a good sign that you’re already asking the right questions.
I still come across people using the MoSCoW prioritization framework (meaning Must Have, Should Have, Will Not Have, or Could Have). But more and more, I’m finding this to be an outdated, project-focused framework. It’s set with the idea that you have a fixed scope and you’re looking at which features need to go into that. It doesn’t really give clarity when you’re faced with a long-term product strategy.
Impact vs. Effort is a popular framework because it’s a lightweight way of gathering insights to help with priority scoring. I like to think of this as the “gut feel meter.” You’re not meant to instantly know the time or dollars a priority will take, but you have a general estimation. The assumption is that more detailed estimates are going to happen later down the line.
Weighted Scoring is also popular, and I can see why because it’s the most complete. But, I’ve actually never found one that works. If often ends up sending people down the wrong path because product teams will come up with a result that doesn’t work for them for whatever reason (a deadline, customer request, etc.) and they’ll either ignore the algorithm or follow it and build the wrong thing. Both outcomes are sort of counterproductive.
One framework that has become popular recently is RICE (which stands for Reach, Impact, Confidence, and Effort). This adds an interesting criterion, which is confidence. If you’re 100 percent confident, then your reach and impact scores are tied down. But if you don’t have huge confidence in your reach and impact, you give a low confidence score and use that as a multiplier to bring the overall RICE score down. There are mixed reactions to this one. But the problem is that you’re still boiling it down to a single number and deciding based on that one number.
Story Mapping is a completely different take on a prioritization framework. I bet a lot of people are using this alongside other frameworks. It’s essentially taking a journey, so you map that out using cards at the top and then you itemize the different tasks users might do along the way under each of those things. You put the most important tasks along the top and then you draw a line. The things that fit above that line will go in your “MVP” or Version 1, 2, and so on. This framework is user centered. It helps you see holes in the customer journey and define iterations in your product. But, it’s not very good for outlining business-centric opportunities rather than just user centric, and it often leads to scope creep.
What prioritization framework do you prefer?
My personal preference is a combination of Impact vs. Effort and variations on Story Mapping. No framework is perfect, but most frameworks can be useful in some way. The key is to pick and mix the best set for your job. An experienced product person knows when to use one—like when they’re trying to get a consistent set of data to measure potential features in the backlog—and when to step away from them, like when their gut instinct tells them the scoring algorithm isn’t accounting for all the information at hand.
How do you check a framework?
I recommend you try a framework alongside your usual prioritization process for a week or two. Start sense-checking your results—are they similar to what your previous method was coming up with? Does it feel good against your gut? Assessing a framework isn’t just looking at final results, but also: Did it get you to ask the right questions? Did it help you surface assumptions faster or rally people around priorities?
Another prioritization tactic I haven’t mentioned yet is Product Roadmapping, and it’s a powerful one because it takes the focus on prioritizing feature X versus feature Y and instead focuses on the company-level objectives and the problems to be solved. The roadmap isn’t this perfect plan meant to be set in stone; it’s meant to be flexible and change. It’s laying out the assumptions and allowing the product team to check whether those assumptions are valid or not. You can use roadmapping as a way to understand your priorities and get team buy-in.