We’ve all been there as a UX professional–
You’ve done research, provided recommendations, even shared a research report, and yet you find yourself looking at a roadmap based on a business need (important) and scoped by tech feasibility (also important), but what about user needs!? If you haven't been in this position before as a designer or researcher, hopefully this article will help keep it that way, and if you have - never again!
TL;DR What it comes down to is doing great user research isn’t enough, presenting your research once isn’t enough. We need to leverage that user research to influence product roadmaps concretely, so that user needs are at the heart of the conversation when prioritizing work.
Follow the 5 Pillars presented in this article and when the question comes up of “why is X so important? Why is X prioritized instead of Y?,” be able to answer the question confidently and empower your team to do the same.
It is without question that product roadmaps need to consider business goals, user needs, and technical feasibility. Why is this balance so critical, you might ask? As Laura Klein says in Build Better Products, “You can’t reach your own business goals without understanding the people that those goals represent.”
How might we get to a place where we can consistently influence roadmaps with UX research? Remember the 5 pillars and you’ll be set up for success.
Pillar 1: Research, release, repeat
As you kickoff a new project or initiative, follow the high level process of research, release, research, release. All important objectives or problem areas need to be investigated. As noted in the book Empowered, “This typically involves doing sufficient product discovery on the item so that your product team (especially the product manager, product designer, and tech lead) can determine whether the solution will be valuable, usable, feasible, and viable.”
Once your approach is validated as valuable, usable, feasible, and viable, you are ready to get going with the MVP. During the build, start research again! This time, investigate what is working, not working, and what problem should we solve next. From there, the cycle continues– as you release that second slice of work, research for the third slice, and so on.
What is also great about the research objective, “learn what problem we should solve for next,” is that this objective directly ties to the roadmap so from the moment research starts, the plan is for your learnings to impact the roadmap.
Pillar 2: Captain the (research) ship
From the outset of a research initiative, assume ownership. What I mean by this is you, the designer/researcher, are the captain of this Research Ship and you need to run the entire ship– this includes communicating with the crew making sure you're all aware of what’s happening and doing what needs to be done.
Define roles and responsibilities
Before starting research, it will benefit your team to clarify who is responsible for what. One way to do that is to run a RACI with your product partners. Maybe your team hasn’t done research together before. Do a RACI, and establish clarity.
If you’re the captain of the research ship, the PM is your second-in-command. As you are making updates to the research plan, they are reviewing and suggesting changes. If they add in a new question, you are reviewing and suggesting changes.
Keep the team informed and involved
The rest of your team should also be informed and involved. Let them know what you’re up to. Start a slack channel specific to research for the project, invite the tech lead, stakeholders, and any engineers or leads from other teams that may be impacted. Share your top interview takeaways as they occur so folks are up to date on what we’re hearing.
Sometimes being informed isn’t enough and you may need to actively involve them in your research. For instance, you may know that your next interview is with someone who has previously given feedback about SMS messages to diners, so invite the PM working on Diner Communications to the upcoming session! Tag them on slack!
Provide a clear recommendation
Don’t overwhelm your squad and stakeholders with dozens of recommendations — prioritize the most important ideas. Distill your findings into 3–5 high-level themes that can guide their thinking and shape the roadmap strategy. Once you have Product Managers’ attention and buy-in, make it easy for them to integrate your findings. Provide clear, relevant, and thoughtful recommendations to spur action. For example, in a recent research share-out, I provided a recommended priority order of what new functionality would be most impactful to users– this directly impacted quarterly planning for the product team.
Pillar 3: Collaborate with your squad to turn lemons into lemonade
Keeping in mind that the roadmap needs to balance business goals, user needs, tech feasibility, setup a sync cadence with product, design, and engineering leads to stay aligned on progress and roadblocks.
If your research findings don’t result in an obvious prioritization for the roadmap, gather all the team leads and stakeholders, and facilitate a prioritization exercise using the two by two framework. On the X-axis, plot out technical effort on a scale from easy to hard, and on the y-axis, measure low expected return to high expected return or low user impact to high user impact. Regardless of the labels, ensure everyone understands how you are defining each of them. For example, agree upon how you might define “expected return.” Map your research learnings along the two axes and prioritize based on the results.
Beyond development of the initial roadmap, it is important to continue communicating, whether that is sending slack updates for the project async, sharing looms of design progress, or meeting with your core product team, the important thing is you are all communicating, so you avoid any knowledge silos or veering down a path that doesn’t consider the user.
Pillar 4: Evidence at your fingertips
There are always those moments when we run into a technical limitation and in order to make your point, you need to be able to know what the precise user needs are and why particular functionality is important (or not). Documentation, evidence will be your best friend here.
Keep it current, keep it comprehensive, keep it organized and accessible so you can refer back to it.
Evidence checklist
- Synthesis boards (use a find and replace plugin on FigJam so you can find what you’re looking for quickly)
- Quantitative data
- Raw notes from interviews (just in case you don’t have comprehensive synth boards and you need to do a quick search and find in the middle of a meeting)
- Any other important links that cover user behavior or data
- All of the above in a bookmarks folder at the ready
Pillar 5: Hold the team accountable
Push back
As a designer, it can feel like we are always hearing why we can’t do something or it might feel like we are always compromising. That’s ok, it’s part of the job, but practice negotiating and compromising if needed.
Bring it back to the evidence
For example, on a recent project, a key piece of functionality was de-scoped because it required more technical effort than initially estimated. I pushed back, pointing out exactly why this functionality was so important to users and offering reduced scope somewhere else. With that, we brought the functionality into scope and the whole team was reminded why. Additionally, share your findings and practices with larger groups and stakeholders (i.e. in product talks, research share-outs, invite more people to slack research channels!)-- the more you share, the more your colleagues will be able to also advocate for user needs!
And that’s that. Simple, right?
In conclusion, follow the 5 pillars to set yourself up for success when it comes to influencing product roadmaps with user research.
- Research, release, repeat
- Captain the (research) ship
- Collaborate with your squad to turn lemons into lemonade
- Evidence at your fingertips
- Hold the team accountable
With the 5 pillars in your toolkit and at your disposal, you will do research, provide recommendations, even share a research report, but this time, you will find yourself looking at a roadmap based on a business need that is rooted in user needs and scoped by tech feasibility.
Good luck in your quest! If there is anything that has worked for you that wasn’t mentioned, I’d love to hear about your experience.
