Research Roadmaps: A Tactic for Greater Org-Wide Alignment (Template Included)

Building a clear, shareable, roadmap of your research efforts can help you better prioritize your work and better demonstrate that work’s value.

One of the best things I did as a user researcher was creating an intake form for research requests. It streamlined the painful back-and-forths, rounded out incomplete requests, and cut unnecessary meetings.

Finally, I had a straightforward way for teams to request research that gave me enough initial information to determine the next steps.

I remember introducing the process about five years ago to an organization I had been at for six months. I met with my stakeholders and then widely shared the intake form with them and other departments. It was announced at our All Hands meeting that Thursday. I was giddy with excitement and went on to my weekend.

The following Monday, I opened my inbox to an influx of research requests; it looked like Google Forms had taken over my inbox. I certainly hadn't been expecting a response like that. Quickly, I realized I had no way to visualize what I was currently working on, what was coming up, and what I needed to save for later. Colleagues reached out for updates, and I had no easy way to explain what was next.

The research roadmap and backlog

For a while, I tried to organize the incoming requests to different folders: to review, reviewed, started, blocked, and iced. However, moving the files around and finding a project to update stakeholders was an enormous burden. At one point, I wondered why I had done this. In a nutshell, I had managed to create more work for myself when trying to streamline a process.

Coincidentally, my teams were doing their quarterly planning when I was frantically organizing completed intake forms. I sat through one particular planning session, and the product manager was sharing their roadmap. One the roadmap, it had their current work and upcoming work, with an accompanying backlog of projects to be prioritized.

Suddenly, it clicked! This roadmap and backlog were precisely what I was missing and what I needed. Not only that, but my teams would be familiar with the structure! I bounced out of that meeting and immediately set to work creating a user research roadmap and backlog.

The benefits of a research roadmap

At first, the use of the roadmap was just for me to visualize the intake documents and projects. But soon, this socialized document was the key to updating stakeholders efficiently and effectively.

The research roadmap and backlog were crucial for a few different reasons:

1. Showcasing current and future capacity.

The roadmap showed the teams how much capacity I had for current and upcoming studies. Since colleagues could see what slots were available, they knew when they had to reach out to me. Instead of last-minute requests, teams started coming to me earlier on to ensure their spot in the roadmap.

This process changed the culture to be more proactive when planning research since it was evident when I could take on new studies and was already too busy. We were also able to put several smaller studies together into one, lessening the number of times we had to recruit.

2. Being transparent about the prioritization of work.

Before I created a roadmap, no one outside of my manager and a few colleagues knew what I was doing. If you asked people outside of the product team about upcoming research studies, they'd meet you with silence. Sometimes, that even happened within the product team.

The research roadmap showed people what I was working on, and, when I coupled it with a prioritization process, teams knew why I was working on a specific project rather than another. Since teams have a lot to focus on, giving them one place to see what is happening was very helpful. In addition, having this document meant that research wouldn't get as lost. We had a track record of previous studies so, when a colleague wanted to know if we'd researched a topic, they could start with our prior roadmaps.

3. Providing clarity around what researchers do.

When I start as the first user researcher at an organization, it takes some time to help people understand the value of user research and how I can help them. Through this roadmap, I was able to show people what I was working on and how I could work on similar studies for them.

Instead of explaining how I speak to users, teams could see the types of ongoing projects. With this information, I had more colleagues asking if we could do something similar to a study I was currently running, but for a different topic. After viewing the roadmap, people had a better sense of user research and the value it could bring to each team.

4. Highlighting potential improvements.

After creating my first roadmap, I saw a long list of evaluative research studies—usability test after usability test. This information was a massive signal that we were over-indexing evaluative research and not leaving enough time for generative research.

cWhen I had mapped out the current and upcoming studies, I went to my manager and showed him that we weren't incorporating enough discovery research. We also discussed the long list of projects in the backlog and decided to create a rolling research program.

5. Demonstrating the impact of user research.

One of the essential parts of our job is to show our impact across an organization. A research roadmap is like a tracker of your work. You can tangibly show how much research you have done, what teams you have worked with, and what crucial topics you covered. On an individual level, during performance reviews, it was easy to look back on my work, provide names of people/teams I worked with, and understand what I had accomplished.

Key components of a research roadmap

When I started seeing all these benefits, I knew I had found something special and wanted to continue this initiative. At first, my roadmap and backlog were incredibly simple. They included the project's name, those involved, and the approximate study dates. But, over time, they evolved and became much more robust. Now my roadmaps include:

1. The project name. Pick something that everyone has agreed on, which will make it easier to find later.
2. The project type. Note the methodology or type of study the project is. Try to get granular here!
3. A brief description of the project background and goals,
4. The priority level of the project, which I calculate before it goes on the roadmap
5. My capacity/support level for that particular project.
6. The team that is involved in the research
7. Main stakeholders involved in the research. You can use the RACI model here (responsible, accountable, consulted, informed).
8. The current status of the project.
9. The approximate timeline of the project. If you want to get into the details here, you can give a timeline breakdown such as:
   1. Recruitment starts August 23rd
   2. Recruitment ends August 30th
   3. Sessions begin September 2nd
   4. Sessions end September 10th
   5. Analysis begins September 12th
   6. Analysis ends September 15th
   7. Report shareout September 19th
10. The incentive amount for the study, which can help with budgeting in the future.
11. A link to the intake document or research brief, which has all the relevant information for the study, including script, deliverables, and a report.
12. Any other necessary resources

Including more data helped give the teams more context when looking at the roadmap and allowed them to dig deeper if needed. Of course, you should always cater to what your team needs, so constant feedback is important. Take a look at my template here!

A note on backlogs:

My backlog is essentially a stripped-down version of the roadmap, including:

1. Project name
2. Project type
3. Brief description
4. Team
5. Intake document, if applicable

Get started

When getting started, your first step is to talk to your teams. I asked a few stakeholders if they would be interested in the concept of seeing upcoming and current research. Everyone responded with a resounding yes. However, as a researcher, I knew that just because someone says they would use something doesn't necessarily mean they will. That is why I started very small with an MVP (minimum viable product).

Once I had this MVP going, I talked to my stakeholders and got feedback. First, I asked them the standard usability testing questions, such as what was missing or confusing. Then, I started to build out my roadmap with their responses by including the additional information I noted above. These meetings helped me get a sense of what was truly needed by my teams to create the most valuable roadmap possible.

After setting up the roadmap and adding some projects, I sat with my teams to ensure we aligned our roadmaps. We looked at what was coming up for them and which of those projects needed research. I updated my roadmap accordingly. I also attended their quarterly planning and updated my roadmap bi-weekly when I met with stakeholders to ensure everything was up-to-date. Although it was some effort, the value I got from the roadmap and backlog was incredible.

Instead of spending my time in those meetings and constantly sending updates, I had one place everyone could go to know exactly what the user research team was up to. As the research team grew, this became even more helpful since we could easily see what each person was doing and ensure we weren't repeating research projects.

Building a user research roadmap and backlog can streamline and optimize so many parts of our process, allowing us to focus on what we really love, conducting impactful research.