6 Ways to Ace Product Roadmap Prioritization

One of the hardest parts of a product manager’s job is prioritization. Product managers receive feedback from customer interviews, NPS surveys, internal requests, user behavior, and more. They then must take all those inputs and transform them into a coherent set of prioritized work: a roadmap.

To take a pile of potential work and map it onto a prioritized list requires research, patience, and collaboration (and sometimes, a little intuition and luck). Product managers usually need to do their homework and approach product roadmap prioritization with an open mind, armed with

• Market research
• User research
• Input from stakeholders (internal and external)
• Business goals and company strategy
• Clear metrics or success criteria
• Strong opinions, held loosely

You may start the process thinking that you have all the information you need to prioritize. But more often than not, setting priority generates more questions. It is okay to identify unknowns and do more work to resolve them before coming back to prioritization. And sometimes you have to take the leap knowing you aren’t making a perfectly informed decision.

After all, the goal of product roadmap prioritization is creating an actionable plan that will meet your goals—not to have a scientifically perfect method.

The product manager is the shepherd of prioritization, not its director. If you’re the product manager, keep in mind that it’s your job to ensure that the roadmap is well-informed, meets stakeholder expectations, and can realistically achieve business goals. But you are not the ultimate decider of what gets done when.

Why product prioritization frameworks?

No team can do everything all at once—and they shouldn’t try. So product managers need some way of organizing and explaining their priorities.

Dozens of frameworks exist to help organize and sort potential features, tasks, and products. The best method or framework varies. It depends a lot on the product(s) you manage, the size of your team, and the maturity of your company.

Each one of these methods helps a team make a series of bets: which initiatives does the team think have the best chance of being completed on time, with the resources allowed, and that will meet the business objectives?

Because the “best” method may change over time, it’s a good idea to have multiple tools in your toolbox. Over time, you’ll use more than one of these methods, even at the same job.

Below are 6 frameworks you can use:

1. RICE
2. Value vs. Effort
3. Story Mapping
4. MoSCoW
5. Three Bucket
6. Eisenhower Matrix

Best for portfolios

Both RICE and Value vs. Effort are great when you want to add some hard numbers to your priorities. They’re especially helpful when you have clear business metrics and lots of research, supporting evidence, and scope estimates.

These methods are well suited to teams responsible for more than one product or a team that manages a portfolio of closely related features.

RICE

Intercom calls RICE “simple prioritization for product managers.” It’s an acronym that allows product teams to measure each feature or product by four aspects:

• Reach
• Impact
• Confidence
• Effort

For any given idea, a number is assigned to each factor, and a score is calculated.

A team can then sort its list of ideas by RICE score.

Pros: RICE is pretty straightforward. It assigns hard numbers to unwieldy priority concepts. Differences in scores between team members can foster healthy debate.

Cons: Teams must do a lot of work before RICE scoring to have confidence on Reach, Impact, and Effort. Assigning four scores to each item can take a long time if many items are up for discussion.

Value vs. Effort

A simplified version of RICE, Value vs. Effort (or sometimes called Value vs. Complexity) weighs the expected value of a product or feature against the expected work required to build and implement it.

In Value vs. Effort, you can assign a specific score to each feature or product by dividing Value by Effort. But you can also place each feature onto a quadrant: effort along the horizontal axis and value along the vertical access.

• High value, low effort ideas (top left) are quick wins that can be prioritized first.
   Examples: UX enhancements, small features
• High value, high effort ideas (top right) are big bets that should be carefully considered.
   Examples: New products, large initiatives
• Low value, high effort ideas (bottom right) are time sinks that should be avoided.
   Examples: Rebuilding an existing product, complicated feature requests with  low demand
• Low value, low effort ideas (bottom left) are easy, low-impact changes that can be sprinkled into the roadmap when there’s time.
   Examples: Quality of life improvements, UI enhancements

Pros: With only two factors to consider, this method is quick and simple. By assigning ideas into quadrants, you don’t just have a ranked list—you have categories of ideas.

Cons: “Value” can be subjective, so some lower-value items may end up with an inflated score. If your team has multiple product lines or areas, it can also be challenging to compare the relative values of ideas across products.

Best for new products and features

Story Mapping, MoSCoW, and Three Bucket all approach the same problem in slightly different ways. When a team needs to create an MVP or the next iteration of a product, the team must decide which features are included. These three methods allow you to rank features by most-to-least critical.

None of these methods accounts for effort or complexity. If your team has a deadline constraint, you may first determine your critical, must-have features. Then the team can work to trim down scope as much as possible during the requirements phase.

Story Mapping

In Story Mapping, the team writes out the steps of the basic user flow. Under each step, the team adds which features would be needed for for a user to complete that step and ranks them from most to least important. In the below diagram, we've mapped out the basic user flow for a dating app.

This method is great for defining a minimum viable product (MVP). What are the bare necessities required to have a workable MVP? This kind of discussion can be challenging, and a story map allows you to draw a line around what must go into the MVP—and then you can decide what set of features you’d ship next.

Pros: Features are put into the context of a user journey, so you can consider the holistic experience rather than line items. You can also re-use the story map for later iterations of the product.

Cons: This method doesn’t weigh the importance of the feature against effort, and it doesn’t account for additional business considerations, like complexity and risk.

MoSCoW

The MoSCoW method is based on an acronym that categorizes every feature into one of four categories (the “o”s were added in to make the acronym memorable):

• Must-have: The product is unusable without it, and there is no viable workaround.
• Should-have: The user would really want (and may even expect) this feature, but they can survive without it.
• Could-have: It would be nice to have this feature, but it isn’t a priority.
• Won’t-have: This kind of feature can actively be ignored.

Pros: All four buckets are from the user’s perspective, making this a great way to keep the user experience front-and-center. The categories themselves are intuitive and allow teams to bring in non-technical stakeholders.

Cons: It’s easy to put more things into the “must-have” bucket. A lot of features we think we absolutely need aren’t necessary for a slimmed-down beta or MVP.

Three-Bucket

A more basic version of MoSCoW is the Three-Bucket model. Slava Akhmechet lays out three buckets to categorize any feature for a product:

• A gamechanger: This feature will make people want to buy or use your product.
• A showstopper: People expect your product to have this feature and won’t buy it if your product doesn’t have it, but you don’t get any credit for including it.
• A distraction: This feature won’t generate demand or drive adoption.

Pros: These simple categories are easy to slot features into. For example, adding a chat feature onto your B2B workflow product may be a distraction, but integrations with a commonly used third-party system could be gamechanger if no competitor has it.

Cons: The three buckets lack the simple naming of MoSCoW and don’t allow for much room to prioritize within each bucket. It’s best to use this method if you’re looking at a handful of very different feature ideas.

Best for tasks and triage

Sometimes as a product manager, your job is to triage a set of tasks generated by other teams or by leadership. This situation is most common on teams that support other internal teams, like tech ops, QA, developer experience, and IT. Other times, you must quickly sort a list of requested features for a product that is in maintenance mode without going through a full planning process.

You also may need a method when triaging bugs or daily tasks, something that can work for both short- and medium-term planning.

Eisenhower Matrix

In these cases, you need a simple way of deciding what must be done immediately and what can wait. Enter the Eisenhower Matrix, named after American President and General Dwight D. Eisenhower, who invented this matrix to help him sort priorities.

Every task is sorted along two axes: urgency and importance.

• Urgent and important tasks (top left) are the highest priority and should be done as soon as possible.
   Examples: Resolving an incident, finishing a client commitment on a           deadline
• Less urgent and important (top right) can wait until you have time and availability to address them.
   Examples: Researching new technology, strategic planning
• Less urgent and less important (bottom right) are the least critical and can be delayed or ignored.
   Examples: One-off enhancement requests
  
   Note: These items can often just be labeled as “don’t do” but are helpful to       categorize to inform stakeholders why their request isn’t being addressed             right now.
• Urgent and less important (bottom) are items with immediate deadlines, but if they don’t get done, nothing critical will happen.
   Examples: Code review, attending a status meeting

Pros: This visualization is great for communicating why tasks are being addressed in a certain order. Its categorization is clear-cut and moves fuzzy strategic conversations into tactical, actionable steps.

Cons: It’s easy to accidentally overestimate a task’s urgency. It can also be easy to delay addressing important (but not urgent) items indefinitely.

Product roadmap prioritization best practices

No matter which method you choose, following best practices will make the process smoother for everyone.

• Always tie back to business goals: Your team’s priorities should align with company priorities. If you’ve prioritized products or features that wouldn’t affect business goals or metrics, you may be focusing on the wrong thing.
• Admit what you don’t know: While debating priority, you may realize you don’t have enough information to make an informed decision. You can table the conversation to perform more research. Come back to the discussion once you’ve answered outstanding questions.
• Foster healthy debate: Stakeholders, teammates, and leadership will all have differing opinions and preferences. Allow for disagreement that is based in mutual respect. Ensure everyone’s voices are heard, and focus on psychological safety.
• Involve stakeholders: It’s best to get input from stakeholders throughout the prioritization process. Stakeholders will have opinions, ideas, and suggestions. If you wait until the end of the prioritization process to get their feedback, you risk redoing work—or not getting the stakeholder’s buy-in on your proposed roadmap.

With these 6 methods, you can create priorities when building and communicating your roadmap. These frameworks can also help you foster communication and visualize priorities beyond abstract discussions. Choose the one that best fits your team’s situation and needs, and be flexible. If you’re finding that one way doesn’t work, it’s okay to switch to another and try something else. Prioritization is less about following a set of rules and more about choosing the best tool for the job.

If you’re building out your product management skill set, meeting with a mentor is a great way to get advice on improving and learning new skills. On Merit, hundreds of product mentors are available to meet with—for free. Sign up today.