Product roadmap planning can be challenging, especially for small 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:
- Gathering product feedback
- Learning the “why” behind feedback
- Separating bug reports and feature requests
- Organizing and prioritizing bug reports
- Organizing and prioritizing feature requests
- Prioritizing all final lists
- 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.
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!
Using a dedicated product roadmapping tool like Canny makes prioriziation much easier.
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.
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.
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.
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:
- 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: Use a spreadsheet. You’ll need a few (easy!) formulas later on.
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 where it really gets exciting when it comes to product roadmap planning. 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 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 methods 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:
- A simple cost/value matrix
- 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.
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!
7. Building your roadmap
You made it! Now you can start placing your prioritized list of activities into your product roadmap.
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 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!
