- \n
- Gathering product feedback<\/li>\n\n\n\n
- Learning the \u201cwhy\u201d behind feedback<\/li>\n\n\n\n
- Separating bug reports and feature requests<\/li>\n\n\n\n
- Organizing and prioritizing bug reports<\/li>\n\n\n\n
- Organizing and prioritizing feature requests<\/a><\/li>\n\n\n\n
- Prioritizing all final lists<\/li>\n\n\n\n
- Assembling your product roadmap<\/li>\n<\/ol>\n\n\n
\n![\"product](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\")
<\/figure>\n<\/div>\n\n\nWhen you\u2019re initially building your product roadmap, deciding on anything<\/em> can seem daunting.<\/p>\n\n\n\n
This process helps you leave aside biases, gut feelings, and unreasonable requests. You\u2019ll be able to focus on what really <\/em>matters.<\/p>\n\n\n\n
Check out this post for more product roadmap best practices. <\/a><\/em><\/p>\n\n\n\n
The roadmap prioritization process can be different across industry and company types.<\/p>\n\n\n\n
What we\u2019ve described here is a very basic, generic process that you can mold for edge cases if you need to.<\/p>\n\n\n\n
Let\u2019s get started!<\/p>\n\n\n
\n<\/a>Using a dedicated product roadmapping tool like Canny<\/a> makes prioritization much easier. <\/span><\/figcaption><\/figure>\n<\/div>\n\n\n <\/p>\n\n\n\n
1. Gathering product feedback<\/h2>\n\n\n\n
The two types of product feedback you should round up for this process are:<\/p>\n\n\n\n
- \n
- Feedback from your existing customers<\/li>\n\n\n\n
- Feedback from potential and previous customers<\/li>\n<\/ul>\n\n\n\n
Let\u2019s go more into detail with both of these groups.<\/p>\n\n\n\n
Gathering existing customer feedback<\/h3>\n\n\n\n
If you\u2019ve already been stashing away product feedback and requests somewhere, it\u2019s time to dig them out.<\/p>\n\n\n\n
If you haven\u2019t been gathering feedback yet, it\u2019s OK. You have an extra step to take, but it\u2019ll be worth it. Starting to track feedback will help you drive customer satisfaction too. <\/p>\n\n\n\n
Go ahead and get into your:<\/strong><\/p>\n\n\n\n
- \n
- Emails<\/li>\n\n\n\n
- Social media<\/li>\n\n\n\n
- Survey results (if you\u2019ve done them)<\/li>\n\n\n\n
- Support tickets<\/li>\n\n\n\n
- Any other channels you have that could contain product feedback<\/li>\n<\/ul>\n\n\n\n<\/figure>\n<\/div>\n\n\n
Product feedback means:<\/strong><\/p>\n\n\n\n
- \n
- Bug reports<\/a> (both from yourself and your customers)<\/li>\n\n\n\n
- Any other issues customers have communicated (e.g a confusing onboarding flow)<\/li>\n\n\n\n
- Feature requests<\/a> or recommendations<\/li>\n<\/ul>\n\n\n\n
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\u2019t matter, as long as you have a good overview of everything.<\/p>\n\n\n\n
Gathering feedback from potential and past customers<\/h3>\n\n\n\n
Your existing customers are a priority. But, reaching outside that zone can be incredibly informative.<\/p>\n\n\n\n
If someone already uses your product, they have decided that it\u2019s doing a decent enough job for them. This isn\u2019t always true\u2014but it\u2019s true more often than not.<\/p>\n\n\n\n
Think about breaking the barrier for people who want to or would use your product, but can\u2019t in its current state. It\u2019s a very simple principle of potential business growth, and a great discovery exercise.<\/p>\n\n\n\n
Reach out to:<\/strong><\/p>\n\n\n\n
- \n
- Members of your target group who are using a competitor\u2019s product<\/li>\n\n\n\n
- Members of your target group who don\u2019t use a product like yours at all<\/li>\n\n\n\n
- People or companies who started a trial, but never converted<\/li>\n\n\n\n
- People or companies who churned soon after converting<\/li>\n<\/ul>\n\n\n\n
Finding out why<\/em> they\u2019re not your customers can add a completely different perspective, and supplement your roadmap with ideas and opportunities you weren\u2019t even aware of.<\/p>\n\n\n\n
Our article on how to gather feedback for your SaaS product<\/a> offers a more in-depth overview of the process. And, here’s a case for why you should be collecting customer feedback<\/a> in the first place.<\/p>\n\n\n\n
2. Learning the \u201cwhy\u201d behind feedback<\/h2>\n\n\n\n
You\u2019ve gathered your product feedback. That’s a great start.<\/p>\n\n\n\n
But, try to be very careful about how seriously you take every piece of feedback.<\/p>\n\n\n\n
Not all feedback is equal. With limited time, resources, and skills, you need to learn to challenge every piece.<\/p>\n\n\n\n
If you take every request or complaint at face value, prioritization for your product roadmap becomes impossible.<\/p>\n\n\n\n
The solution for this is everyone in your team getting into a habit of asking \u201cwhy?\u201d<\/p>\n\n\n\n
(Note: we\u2019re talking about feature requests and general issues, not bug reports.)<\/p>\n\n\n\n
The \u201cwhy\u201d isn\u2019t meant to be naggy, demanding, or whiny. It helps you (and your customers) understand what they\u2019re really trying to do. And that helps you focus product development<\/a> on customer need. <\/p>\n\n\n\n
Here\u2019s an example of a lovely, calm, helpful \u201cwhy?\u201d:<\/h3>\n\n\n\n
- \n
- Very important customer:<\/b> We want you to add the reports button in the main menu instead of it being in the dropdown. It\u2019s very important.<\/em><\/li>\n\n\n\n
- You:<\/b> 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\u2019 requests as well as possible, so we can focus on the right things.<\/li>\n\n\n\n
- Very important customer<\/b>: Kyle from accounting keeps forgetting where it is.<\/li>\n<\/ul>\n\n\n
\n<\/figure>\n<\/div>\n\n\nLearning moment:<\/b> This company doesn\u2019t have a real<\/i> problem (Kyle might disagree). They have a minor issue that can easily be fixed by:<\/p>\n\n\n\n
- \n
- Adding a step in your knowledge base about getting to the reports view<\/li>\n\n\n\n
- Changing some wording in the product for better understanding of navigation<\/li>\n\n\n\n
- Sending Kyle a post-it note with the location of the reports page that he can stick to his monitor<\/li>\n<\/ul>\n\n\n\n
Imagine just putting that button on the dashboard without asking why. Hundreds of people would be contacting you because now they<\/i> can’t find the reports button.<\/p>\n\n\n\n
Kyle would be happy. But at what cost?<\/p>\n\n\n\n
Tl;dr: Asking \u201cwhy?\u201d will help you understand the real value of every request and make an informed decision<\/em>. Prioritization becomes much easier.<\/p>\n\n\n\n
It\u2019s OK if you haven\u2019t done this extra asking yet. If you need more context right now, reach out and ask. It\u2019s very unlikely anyone will mind.<\/p>\n\n\n\n
In the future, try to ask as soon as anything comes in.<\/p>\n\n\n\n
3. Separating bugs and feature requests<\/h2>\n\n\n\n
It\u2019s time to get into the fun stuff!<\/p>\n\n\n\n
The first step is to separate your pile of product feedback into two large buckets:<\/p>\n\n\n\n
- \n
- Bug reports (and everything else that is broken in your existing product)<\/li>\n\n\n\n
- Potential feature requests, recommendations, and other \u201cadditions\u201d<\/li>\n<\/ol>\n\n\n\n
As for the tool to use for this: <\/p>\n\n\n\n
- \n
- Use a spreadsheet. You\u2019ll need a few (easy!) formulas later on.<\/li>\n\n\n\n
- Use a feedback management tool like Canny <\/em><\/li>\n<\/ol>\n\n\n\n
4. Organizing and prioritizing bug reports<\/h2>\n\n\n\n
The first bucket to tackle is your bugs and bug reports.<\/p>\n\n\n\n
Note: Some bugs are obviously critical. If your entire product is down, you need to deal with it now.<\/em> What we\u2019re talking about here are issues that are an inconvenience, but not deadly.<\/p>\n\n\n\n
Step 1: Organize<\/h3>\n\n\n\n
The first thing you\u2019ll 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\u2019re already aware of.<\/p>\n\n\n\n
Pull all similar bugs into one list\u2014and add who reported it under it. You should end up with something like this:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nNow, instead of a giant list of overlapping things, you\u2019ll have a list of unique issues, all separated.<\/p>\n\n\n\n
Step 2: Prioritize<\/h3>\n\n\n\n
For each bug and who\u2019s reporting it, consider these things:<\/p>\n\n\n\n
- \n
- Is it a paying customer? (On a scale of yes = 2, and no = 1)<\/li>\n\n\n\n
- 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)<\/li>\n\n\n\n
- How many people or companies reported the bug? (Just the number)<\/li>\n\n\n\n
- Where do you place the fix on your importance level (On a scale of 1 to 3, with 3 being very important)<\/li>\n<\/ul>\n\n\n\n
Then, add up the \u201cscores\u201d to get a \u201ctotal score\u201d:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nOnce you\u2019ve calculated a \u201cscore\u201d for every bug, create a conclusive list of them, ordered by the \u201ctotal score\u201d of each bug:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nYou\u2019re doing great! Set that list aside for now. We\u2019ll move on to feature requests.<\/p>\n\n\n\n
5. Organizing and prioritizing feature requests<\/h2>\n\n\n\n
This is product roadmap planning gets really exciting. You\u2019re about to get a good overview of all the new product features you could be building soon.<\/p>\n\n\n\n
Step 1: Organize<\/h3>\n\n\n\n
Group similar feature requests or recommendations together, and add who asked for them.<\/p>\n\n\n\n
You\u2019ll end up with this:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nAlso similarly to your bugs, you\u2019ll end up with a few of these lists, depending on how many \u201cgroups\u201d of requests you have.<\/p>\n\n\n\n
Don\u2019t forget to add the \u201coutside\u201d requests from your potential or churned customers.<\/p>\n\n\n\n
Step 2: Feature prioritization<\/h3>\n\n\n\n
For each request and who\u2019s asking, consider these things:<\/p>\n\n\n\n
- \n
- Is it a paying customer?\n
- \n
- (On a scale of yes = 2, and no = 1)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- How important is the potential feature for them\/their retention\/happiness?\n
- \n
- (On a scale of 1 to 3, with 3 being very important)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- How many people or companies asked for the feature?\n
- \n
- (Just the number)<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- How much do you agree with the request, and\/or think it\u2019s necessary\n
- \n
- (On a scale of 1 to 3, with 3 being strongly agreed)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
On your \u201cagreement,\u201d think about these questions before giving your score:<\/p>\n\n\n\n
- \n
- Will it give you a business advantage of any kind (e.g separate you from competition)?<\/li>\n\n\n\n
- Is it something that you\u2019ve considered doing before anyway?<\/li>\n\n\n\n
- How does it align with your vision of the product?<\/li>\n<\/ul>\n\n\n\n
Then, add up the \u201cscores\u201d to get a \u201ctotal score.\u201d It\u2019ll look something like this:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nOnce you\u2019ve calculated a total score for every feature request, pull them into a conclusive list:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nThere you go! You started with a messy list of bug reports, complaints, requests, and recommendations.<\/p>\n\n\n\n
Now, you have everything organized in a clear, visual overview.<\/p>\n\n\n\n
You\u2019ve done a giant amount of work. Now, it\u2019s time to get into consolidating it.<\/p>\n\n\n\n
6. Prioritizing all final lists<\/h2>\n\n\n\n
There are many prioritization frameworks for organizing your lists into concrete to-do\u2019s and not-to-do\u2019s.<\/p>\n\n\n\n
We\u2019re going to use two different methods for making your final decisions:<\/p>\n\n\n\n
- \n
- A simple cost\/value matrix<\/li>\n\n\n\n
- The MoSCoW method<\/a><\/li>\n<\/ol>\n\n\n\n
Firstly, let\u2019s get into the evaluation of cost versus value.<\/p>\n\n\n\n
When we say \u201ccost,\u201d you can think about it either in the financial sense, or you can consider \u201ccost\u201d to be \u201ceffort.\u201d Use whichever definition makes more sense for your business.<\/p>\n\n\n\n
Cost\/value matrix:<\/h3>\n\n\n\n
<\/figure>\n\n\n\nIt\u2019s pretty simple. You take into account both the value and cost\/effort of a task, and place it in the matrix.<\/p>\n\n\n\n
You already know what the \u201cvalue\u201d is, based on the \u201cscores\u201d you calculated for each item earlier. To know which score is \u201chigh\u201d or \u201clow\u201d on the value scale, just take the highest and lowest \u201ctotal scores\u201d from your list.<\/p>\n\n\n\n
Now, you need to figure out the cost\u2014or effort:<\/strong><\/p>\n\n\n\n
- \n
- How much time would it take you to do this?<\/li>\n\n\n\n
- What resources would it take you to do this?<\/li>\n\n\n\n
- Would you need extra<\/em> resources or time to get this done?<\/li>\n<\/ul>\n\n\n\n
Start placing your feature requests and issues into the matrix.<\/p>\n\n\n\n
For example:<\/b><\/p>\n\n\n\n
- \n
- Feature request:<\/b> Adding photos to customer profiles<\/li>\n\n\n\n
- Value:<\/b> Very high, total score 26<\/li>\n\n\n\n
- Cost: <\/b>Low, Jim could do this in a week because he\u2019s a badass, and has no other outstanding tasks<\/li>\n\n\n\n
- Placement: <\/b>high priority<\/li>\n<\/ul>\n\n\n\n
Once you\u2019ve placed all your tasks on the cost\/value matrix, it\u2019s time to get into a little bit of MoSCoW.<\/p>\n\n\n\n
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. <\/em><\/p>\n\n\n\n
The MoSCoW method<\/h3>\n\n\n\n
The MoSCoW method divides your tasks into four buckets\u2014must have\/do, should have\/do, could have\/do, and won\u2019t have\/do.<\/p>\n\n\n\n
You don\u2019t have to use the MoSCoW lists if you\u2019ve 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.<\/p>\n\n\n\n
This step is easy. Take priorities 1, 2, 3, and 4 from your matrix, and divide them into the four MoSCoW columns.<\/p>\n\n\n\n
Like this:<\/strong><\/p>\n\n\n
\n<\/figure>\n<\/div>\n\n\nAnd there you go! You have an organized and prioritized list to start placing in your product roadmap.<\/p>\n\n\n\n
It\u2019s good to keep this list handy\u2014even the items that you\u2019ve decided not to deal with now. Who knows\u2014in the future, maybe your \u201cwon\u2019t do\u201d items will become relevant again!<\/p>\n\n\n\n
There are a lot of different priortization frameworks you could use, depending on your needs. Check out our l<\/em>ist of product prioritization frameworks<\/em><\/a> for 19 of them including the KANO model, opportunity scoring, the effort matrix, and more. <\/em><\/p>\n\n\n\n
7. Building your roadmap<\/h2>\n\n\n\n
You made it! Now you can start placing your prioritized list of activities into your product roadmap.<\/p>\n\n\n\n
How you manage your roadmap can also have a big impact on how succesful your product planning is. <\/p>\n\n\n\n
A roadmap is your strategic plan that outlines the roadmap items you need to complete to achieve strategic goals. <\/p>\n\n\n\n
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<\/a>. <\/p>\n\n\n\n
But, there’s an easier way that will make your roadmap more accesible and useful. <\/p>\n\n\n\n
A product roadmap prioritization tool<\/a> lets you automate prioritization. This lets you easily find your top roadmap items. Then, you can simply move these items to your roadmap. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Stakeholders can also participate in prioritization decisions. They can add their vote or comments to roadmap items.<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
Looking for a tool that can do all that? Check out Canny<\/a> \ud83d\ude42<\/p>\n\n\n\n
Product prioritization helps you build a better product<\/strong><\/h2>\n\n\n\n
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. <\/p>\n\n\n\n
- Value:<\/b> Very high, total score 26<\/li>\n\n\n\n
- Feature request:<\/b> Adding photos to customer profiles<\/li>\n\n\n\n
- (On a scale of 1 to 3, with 3 being strongly agreed)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
- Is it a paying customer?\n
- You:<\/b> 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\u2019 requests as well as possible, so we can focus on the right things.<\/li>\n\n\n\n
- Very important customer:<\/b> We want you to add the reports button in the main menu instead of it being in the dropdown. It\u2019s very important.<\/em><\/li>\n\n\n\n
- Bug reports<\/a> (both from yourself and your customers)<\/li>\n\n\n\n
![\"product](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/04\/roadmap-prioritization-min.png\")
<\/figure>\n<\/div>\n\n\n![\"Canny](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5705808\/e1d55d08-a2cf-44a3-a9a0-f3ca5ff21dfa.png\")
<\/a>![\"Gather](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/feedback-channels-1024x346.png\")
<\/figure>\n<\/div>\n\n\n![\"\"](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/image9-300x153.gif\")
<\/figure>\n<\/div>\n\n\n![\"Create](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-1-300x196.jpg\")
<\/figure>\n<\/div>\n\n\n![\"prioritizing](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-2-1024x237.jpg\")
<\/figure>\n<\/div>\n\n\n![\"bug](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-3-300x95.jpg\")
<\/figure>\n<\/div>\n\n\n![\"grouping](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-4-300x163.jpg\")
<\/figure>\n<\/div>\n\n\n![\"scoring](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-5-1024x198.jpg\")
<\/figure>\n<\/div>\n\n\n![\"list](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-6-300x95.jpg\")
<\/figure>\n<\/div>\n\n\n![\"cost](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/04\/cost-value-matrix.jpg\")
<\/figure>\n\n\n\n![\"moscow](\"https:\/\/canny.io\/blog\/wp-content\/uploads\/2019\/03\/chart-7-1024x173.jpg\")
<\/figure>\n<\/div>\n\n\n