Roadmap prioritization can be challenging, especially for small teams.
You have a vision for what you’ve built, and might even have a roadmap to get you 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 reason to build everything—you never will.
So how do you know, between your own ideas and your customers’, which changes to go with?
The good news is that you don’t have to make a hard choice. You do have to learn to balance between the two sides.
Today, we’re going to show you how to get started.
The process of product roadmap prioritization
The general process for organizing and prioritizing product feedback looks like this:
- Gathering product feedback
- Learning about the context and importance of feedback
- Separating bug reports and feature requests
- Organizing and prioritizing bug reports
- Organizing and prioritizing feature requests
- Prioritizing all final lists
- Assembling your roadmap
When you’re starting out, 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.
The 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!
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 it 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.
Go ahead and get into your…:
- Social media
- Survey results (if you’ve done them)
- Support tickets
… and any other channels you have that could contain any 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. Yet, 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 is 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.
Learning about the context and importance of feedback
You’ve gathered your product feedback—great start!
But, try to be very careful about how seriously you take any feedback.
Like we said in the beginning—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 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.
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. 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.
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:
- Bug reports (and everything else that is broken in your existing product)
- Feature requests, recommendations and other “additions”
As for the tool to use for this—you’ll need a few (easy!) formulas later, so go ahead and use a spreadsheet.
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 fair 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 (aka how mad are they at you)? (On a scale of 1-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-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, and we’ll move on to feature requests.
Organizing and prioritizing feature requests
This is where it really gets exciting when it comes to your future roadmap. You’ll get a good overview of all the new 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: prioritize
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 feature for them/their retention/happiness? (On a scale of 1-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 or think it’s necessary (On a scale of 1-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.
Come backstage, where we share an honest look into building Canny. You’ll be the first to know when we post new content.
Prioritizing all final lists
There are many methods for organizing your lists into concrete to-do’s and not-do-do’s.
We’re going to use two different methods for making your final decisions:
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.
Here’s what the cost/value matrix looks like:
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?
- How much 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.
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.
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 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 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!
Building your roadmap
You made it! Now you can start placing your prioritized list of activities into your roadmap.
Roadmaps are exciting. You could even make it public to keep your (potential) customers, stakeholders, and fans in the loop.
If you need a tool to help you prioritize your product roadmap, try out Canny!