That’s it, your user research is done and you have found plenty of insights. (Well done!)

But how to sort them? How to transform them into actions?
Where to start?

It’s always difficult to pick the right insight to address first and to find an agreement among teams. It’s also difficult to put aside any gut feelings or emotional reactions to the user’s voice because it can mirror the issues you are facing yourself with the product.

This article will give you a framework to help you to build a high level product roadmap based on your findings.

It will help you to pick the most valuable projects with the right balance on the followings:

  • How important is it for the user?
  • How much will this cost you?
  • How much will you earn / or save?

Note: It’s important to involve the right stakeholders in this process: Product owner, UX, UI, Dev, etc. Once you have done you research, the following steps can be done with the team during a workshop. Be sure to prepare all the small cards in advance to facilitate the exercises.

How to build a roadmap based on user research - process

 

1- Gather and share the user insights

How to build a roadmap based on user research - Gather insights

First, identify the key insights in your research. Keep only the ones that reflect a common pattern between all your tested users. If necessary, use quantitative data to back-up your qualitative research and to help the rest of the team to build business cases.

At this point, it’s important to present your findings in the best way possible. Use any evidence you have and try to show the user in action (videos, photos, quotes and so on).

 

2- Sort and group your insights to create projects or themes

How to build a roadmap based on user research - Sort and group your insights

If you have different source of insights, group all the insights by themes and start to identify potential projects.

You don’t have to figure out all the details now, just the headline.

Let’s take a couple of (made up) insights as an example:

  • Google Analytics: an average of 4 visits before finalising the order
  • User interview: « I always do the research on my own and then I send it to my wife so she can review the options. And the end, she will make the final call and finalise the check-out. »
  • Call center: An average of 2 calls before finalising the order. First call: gather information. Second call: decision is made, proceed to check-out and payment.

This can lead to 3 potential projects: save my search for later / share my search / wish list.

 

3- Do a high level rating (pain, effort, value)

To help you to identify the most valuable projects, you need to find the right balance between what the user wants, what it will cost you to build it and what the business outcome of the project will be.

How to build a roadmap based on user research - High level rating

You should rate the 3 following points:

  • Pain level: Painful – Confusing – New opportunity
  • Effort: 1- small project, 2- medium project , 3- big project
  • Potential business value: $, $$, $$$

You have to define what it means for your organisation specifically. What is a « 2 »? What brings value to the business (growth, conversion, cost saving, etc)?

How to build a roadmap based on user research - example of a project

It doesn’t have to be super accurate. It’s a guess. You will probably be wrong, but you have to start somewhere!

It’s important to do this rating collaboratively. Try to include all the teams: Dev, UX, Product management, etc. The rating has to reflect the overall impact on your organisation. It can be a small project for the dev team but a huge one for the UX and marketing team.

 

4- Place on the chart

How to build a roadmap based on user research - place on a chart - Value - Effort - Pain level

To help you to visually sort all the project, you can now place them on a chart.

X: Effort level
Y: Pain level
And then, after placing your projects, draw circles with different sizes to express the value.

 

5- Select the projects and order them

Think about your product. Usually, users only use a few key features in a product. So, there is no point in adding new features if your experience is already broken.

My advice is to select your projects in that order:

  1. Fix
  2. Improve
  3. Innovate

How to build a roadmap based on user research - fix - improve - innovate - how to select your projects

So, start with the most painful and the easiest to fix. Then continue with what you can improve, but make a choice of the most valuable projects. Same approach with the new opportunities.

That’s the theory. You also have to consider your company strategy and your product vision. What do you want to achieve? What do you want to build? Sometimes, it’s important to pick a project because it will help you to build your vision even if it doesn’t seem to be the most valuable right now.

At that point in the process, it’s also important to decide which one you will abandon. Yes, you found insights around this topic but if you think it will cost you too much or there is no market for it, let it go, right now.

 

6- Place them on the roadmap

How to build a roadmap based on user research - place your projects on a timeline

First, pick the ‘meaning’ of your timeline. Is it delivery dates? or ready for dev dates? or beginning of the project? Then evaluate how many ‘effort points’ your can work on per month as an organisation? (including design, product owners, dev, etc). Then place your projects on the timeline.

 

Final thoughts

This framework is really useful when you have done a big research campaign. But as soon as user research is part of your process, you can continue to use this framework to update your current roadmap and evaluate the priority of your new findings compared to the existing projects.

In real life, you will have to consider in your roadmap all the other projects that are not coming from user research: SEO, marketing, the CEO’s ideas, etc. But you can integrate those projects and evaluate them in the same way. Does the SEO project have more or less value than project B?

This approach will give you some visibility, and help you and the rest of the stakeholders to make a decision together. It is not accurate and it doesn’t have to be.

Consider this as a contextualised product backlog that will be re-evaluated often. And if you need something more precise, you can take the first 2-3 months of your roadmap and create a more detailed evaluation and planning.

I hope it will help you. Any thoughts or experience you want to share?

 

Previous post

#Weekly shake: how to present your research, inside IDEO, your strategy is your story

Next post

#Weekly shake: Don’t listen to your users, how to hire engineers, avoid drop downs, hexadecimal colours and space invaders

1 Comment

  1. Ben
    14 August 2015 at 8 h 11 min — Reply

    Thanks for the insight.
    I will definitely try this approach, but it sounds straight forward and it is definitely a great way to involve everyone in the team.

Leave a reply

Your email address will not be published. Required fields are marked *