Product roadmap prioritization: how to effectively plan your roadmap

Product roadmap planning can be challenging, especially for small product teams.

You have a vision for what you’ve built, and ideas about how to get there. You also have customers who you value a lot. These customers often come with an overwhelming amount of opinions, requests, and demands.

You don’t have the resources, time, or desire to build everything—and you never will.

So, how do you decide what gets built or changed? And, what should you focus on first? How do you determine what feedback and requests are the highest priority?

The 7 steps of product roadmap planning

The general product roadmap planning process for organizing and prioritizing product feedback looks like this:

1. Gathering product feedback
2. Learning the “why” behind feedback
3. Separating bug reports and feature requests
4. Organizing and prioritizing bug reports
5. Organizing and prioritizing feature requests
6. Prioritizing all final lists
7. Assembling your product roadmap

When you’re initially building your product roadmap, deciding on anything can seem daunting.

This process helps you leave aside biases, gut feelings, and unreasonable requests. You’ll be able to focus on what really matters.

Check out this post for more product roadmap best practices. 

The roadmap prioritization process can be different across industry and company types.

What we’ve described here is a very basic, generic process that you can mold for edge cases if you need to.

Let’s get started!

1. Gathering product feedback

The two types of product feedback you should round up for this process are:

• Feedback from your existing customers
• Feedback from potential and previous customers

Let’s go more into detail with both of these groups.

Gathering existing customer feedback

If you’ve already been stashing away product feedback and requests somewhere, it’s time to dig them out.

If you haven’t been gathering feedback yet, it’s OK. You have an extra step to take, but it’ll be worth it. Starting to track feedback will help you drive customer satisfaction too. 

Go ahead and get into your:

• Emails
• Social media
• Survey results (if you’ve done them)
• Support tickets
• Any other channels you have that could contain product feedback

Product feedback means:

• Bug reports (both from yourself and your customers)
• Any other issues customers have communicated (e.g a confusing onboarding flow)
• Feature requests or recommendations

To start out, you can throw these things into a Google Doc, a spreadsheet, or even on a piece of paper. At this stage it doesn’t matter, as long as you have a good overview of everything.

Gathering feedback from potential and past customers

Your existing customers are a priority. But, reaching outside that zone can be incredibly informative.

If someone already uses your product, they have decided that it’s doing a decent enough job for them. This isn’t always true—but it’s true more often than not.

Think about breaking the barrier for people who want to or would use your product, but can’t in its current state. It’s a very simple principle of potential business growth, and a great discovery exercise.

Reach out to:

• Members of your target group who are using a competitor’s product
• Members of your target group who don’t use a product like yours at all
• People or companies who started a trial, but never converted
• People or companies who churned soon after converting

Finding out why they’re not your customers can add a completely different perspective, and supplement your roadmap with ideas and opportunities you weren’t even aware of.

Our article on how to gather feedback for your SaaS product offers a more in-depth overview of the process. And, here’s a case for why you should be collecting customer feedback in the first place.

2. Learning the “why” behind feedback

You’ve gathered your product feedback. That’s a great start.

But, try to be very careful about how seriously you take every piece of feedback.

Not all feedback is equal. With limited time, resources, and skills, you need to learn to challenge every piece.

If you take every request or complaint at face value, prioritization for your product roadmap becomes impossible.

The solution for this is everyone in your team getting into a habit of asking “why?”

(Note: we’re talking about feature requests and general issues, not bug reports.)

The “why” isn’t meant to be naggy, demanding, or whiny. It helps you (and your customers) understand what they’re really trying to do. And that helps you focus product development on customer need. 

Here’s an example of a lovely, calm, helpful “why?”:

• Very important customer: We want you to add the reports button in the main menu instead of it being in the dropdown. It’s very important.
• You: Thanks for the feedback! Do you mind if we ask how that would help you, or what the issue is with the current location? We want to understand our customers’ requests as well as possible, so we can focus on the right things.
• Very important customer: Kyle from accounting keeps forgetting where it is.

Learning moment: This company doesn’t have a real problem (Kyle might disagree). They have a minor issue that can easily be fixed by:

• Adding a step in your knowledge base about getting to the reports view
• Changing some wording in the product for better understanding of navigation
• Sending Kyle a post-it note with the location of the reports page that he can stick to his monitor

Imagine just putting that button on the dashboard without asking why. Hundreds of people would be contacting you because now they can’t find the reports button.

Kyle would be happy. But at what cost?

Tl;dr: Asking “why?” will help you understand the real value of every request and make an informed decision. Prioritization becomes much easier.

It’s OK if you haven’t done this extra asking yet. If you need more context right now, reach out and ask. It’s very unlikely anyone will mind.

In the future, try to ask as soon as anything comes in.

3. Separating bugs and feature requests

It’s time to get into the fun stuff!

The first step is to separate your pile of product feedback into two large buckets:

1. Bug reports (and everything else that is broken in your existing product)
2. Potential feature requests, recommendations, and other “additions”

As for the tool to use for this: 

1. Use a spreadsheet. You’ll need a few (easy!) formulas later on.
2. Use a feedback management tool like Canny 

4. Organizing and prioritizing bug reports

The first bucket to tackle is your bugs and bug reports.

Note: Some bugs are obviously critical. If your entire product is down, you need to deal with it now. What we’re talking about here are issues that are an inconvenience, but not deadly.

Step 1: Organize

The first thing you’ll want to do is group similar bugs together. A few people have probably reported the same thing. These things might also align with the stuff you’re already aware of.

Pull all similar bugs into one list—and add who reported it under it. You should end up with something like this:

Now, instead of a giant list of overlapping things, you’ll have a list of unique issues, all separated.

Step 2: Prioritize

For each bug and who’s reporting it, consider these things:

• Is it a paying customer? (On a scale of yes = 2, and no = 1)
• How important is the fix for them/their retention (A.K.A., how mad are they at you)? (On a scale of 1 to 3, with 3 being very, very mad)
• How many people or companies reported the bug? (Just the number)
• Where do you place the fix on your importance level (On a scale of 1 to 3, with 3 being very important)

Then, add up the “scores” to get a “total score”:

Once you’ve calculated a “score” for every bug, create a conclusive list of them, ordered by the “total score” of each bug:

You’re doing great! Set that list aside for now. We’ll move on to feature requests.

5. Organizing and prioritizing feature requests

This is product roadmap planning gets really exciting. You’re about to get a good overview of all the new product features you could be building soon.

Step 1: Organize

Group similar feature requests or recommendations together, and add who asked for them.

You’ll end up with this:

Also similarly to your bugs, you’ll end up with a few of these lists, depending on how many “groups” of requests you have.

Don’t forget to add the “outside” requests from your potential or churned customers.

Step 2: Feature prioritization

For each request and who’s asking, consider these things:

• Is it a paying customer?
  • (On a scale of yes = 2, and no = 1)
• How important is the potential feature for them/their retention/happiness?
  • (On a scale of 1 to 3, with 3 being very important)
• How many people or companies asked for the feature?
  • (Just the number)
• How much do you agree with the request, and/or think it’s necessary
  • (On a scale of 1 to 3, with 3 being strongly agreed)

On your “agreement,” think about these questions before giving your score:

• Will it give you a business advantage of any kind (e.g separate you from competition)?
• Is it something that you’ve considered doing before anyway?
• How does it align with your vision of the product?

Then, add up the “scores” to get a “total score.” It’ll look something like this:

Once you’ve calculated a total score for every feature request, pull them into a conclusive list:

There you go! You started with a messy list of bug reports, complaints, requests, and recommendations.

Now, you have everything organized in a clear, visual overview.

You’ve done a giant amount of work. Now, it’s time to get into consolidating it.

6. Prioritizing all final lists

There are many prioritization frameworks for organizing your lists into concrete to-do’s and not-to-do’s.

We’re going to use two different methods for making your final decisions:

1. A simple cost/value matrix
2. The MoSCoW method

Firstly, let’s get into the evaluation of cost versus value.

When we say “cost,” you can think about it either in the financial sense, or you can consider “cost” to be “effort.” Use whichever definition makes more sense for your business.

Cost/value matrix:

It’s pretty simple. You take into account both the value and cost/effort of a task, and place it in the matrix.

You already know what the “value” is, based on the “scores” you calculated for each item earlier. To know which score is “high” or “low” on the value scale, just take the highest and lowest “total scores” from your list.

Now, you need to figure out the cost—or effort:

• How much time would it take you to do this?
• What resources would it take you to do this?
• Would you need extra resources or time to get this done?

Start placing your feature requests and issues into the matrix.

For example:

• Feature request: Adding photos to customer profiles
• Value: Very high, total score 26
• Cost: Low, Jim could do this in a week because he’s a badass, and has no other outstanding tasks
• Placement: high priority

Once you’ve placed all your tasks on the cost/value matrix, it’s time to get into a little bit of MoSCoW.

Note: in some situations you might opt to only look at the effort required for a roadmap item. In these cases, you could use a similar tool called an effort matrix. It helps you plan out more operational tasks, but is less useful when looking at things like customer value. 

The MoSCoW method

The MoSCoW method divides your tasks into four buckets—must have/do, should have/do, could have/do, and won’t have/do.

You don’t have to use the MoSCoW lists if you’ve already filled out your prioritization matrix. But, it does help you re-organize your tasks into lists instead of a visual matrix. This makes placement into an actual product roadmap later on a little bit easier.

This step is easy. Take priorities 1, 2, 3, and 4 from your matrix, and divide them into the four MoSCoW columns.

Like this:

And there you go! You have an organized and prioritized list to start placing in your product roadmap.

It’s good to keep this list handy—even the items that you’ve decided not to deal with now. Who knows—in the future, maybe your “won’t do” items will become relevant again!

There are a lot of different priortization frameworks you could use, depending on your needs. Check out our list of product prioritization frameworks for 19 of them including the KANO model, opportunity scoring, the effort matrix, and more. 

7. Building your roadmap

You made it! Now you can start placing your prioritized list of activities into your product roadmap.

How you manage your roadmap can also have a big impact on how succesful your product planning is. 

A roadmap is your strategic plan that outlines the roadmap items you need to complete to achieve strategic goals. 

That could be as simple as writing it out in Word, or creating a visual roadmap in Excel. Check out some good Excel roadmap templates here. 

But, there’s an easier way that will make your roadmap more accesible and useful. 

A product roadmap prioritization tool lets you automate prioritization. This lets you easily find your top roadmap items. Then, you can simply move these items to your roadmap. 

On top of saving you time, it also helps the product management team keep all your stakeholders updated. Anyone with access can reference the roadmap at any time to see what projects are underway. You could even make it public so all your users can see what’s coming. 

Stakeholders can also participate in prioritization decisions. They can add their vote or comments to roadmap items.

For example, your sales team might share that a major deal depends on building a new product feature. If this was factored into your prioritization formula, your product team would see the feature’s score increase. They could then prioritize features that would win you more deals and new revenue. 

Looking for a tool that can do all that? Check out Canny 🙂

Product prioritization helps you build a better product

The key to building better products is having a clear product vision and roadmap. Effective prioritization lets you build a roadmap to achieve that vision. 

Product roadmaps are exciting. You could even make it public to keep your (potential) customers, stakeholders, and fans in the loop (and here’s why you shouldn’t worry about having a public roadmap).

We suggest using a tool like Canny to build and prioritize your roadmap. With Canny, you can collect feedback from users, and build your roadmap from those feature requests. You’ll also be able to easily keep everyone informed (from customers to internal team members).

Good luck!