How to Get Research Recommendations on the Roadmap

If you've ever spent weeks on a research project only to watch the findings get politely acknowledged and then quietly shelved, you know the feeling. The roadmap gets built, priorities get set, and somehow your work ends up as a footnote. It's not that your PM doesn't care about users. It's that by the time you showed up with something to say, the decisions were already half-made.

Over several years of teaching our live course Product and UX: Building Partnerships for Better Outcomes, one of the biggest pain points we hear about is that designers and researchers feel locked out of the planning process. Too many UX teams struggle to get user-centered features onto the roadmap.

Getting on the roadmap isn't about finding the magic phrase that makes stakeholders care about UX. It's about being earlier, more deliberate, and more fluent in the language of the people you're trying to influence. None of this is easy, and some of it won't work even when you do everything right, but here's what actually helps.

1. Know When the Roadmap is Actually Built

A surprising number of designers and researchers have no idea when their organization's planning cycles happen. They find out a roadmap exists when someone shares a Confluence page, at which point it's already too late to shape it.

Find out which planning cycle drives real prioritization decisions at your company, and when it happens. Ask your PM directly: "When do you do your planning, and how can I get looped in before priorities are set?" Most PMs aren’t hiding it, they just haven't thought to share it.

Once you know, get yourself on the calendar for the rituals around it. Sprint planning, quarterly reviews, roadmap grooming — even attending as an observer gives you a window into how decisions get made. Don't wait to be invited.

2. Understand What's Already on the Roadmap and Why

Before you can make a case for something new, you need to understand what you're asking people to deprioritize. Walking in without knowing that is one of the fastest ways to lose credibility with a PM.

Some items are immovable, like executive mandates, contractual commitments, and regulatory deadlines. Pushing against them can signal that you don't understand how the business works.

Other items are softer. They're on the roadmap because someone thought they were a good idea six months ago or because they've been there so long nobody remembers why they were added in the first place. Those are your openings. Better yet, look for places where your idea complements something already planned rather than competing with it. The goal is to walk in already knowing your PM's constraints, not discovering them in the middle of your pitch.

3. Get into Discovery Before Solutions Are on the Table

The best time to influence a roadmap is before anyone calls it a roadmap. By the time priorities are being formally documented, people have already formed opinions, and changing them is much harder than helping shape them in the first place.

Ask to be involved in early problem framing — not the handoff meeting where you get specs, but the earlier, messier conversations where the team is still figuring out what they're trying to solve. If that process doesn't exist at your organization, ask your PM: "Is there a way I can get involved earlier, before solutions are already on the table?" Sometimes they'll say yes. Sometimes the decisions come from above and there's nothing to be done, but that's useful information, because it can save you a lot of time and frustration.

4. Translate Research into the Language of the Roadmap

Before you can argue for something, you need to understand how your PM thinks about priorities. Some roadmaps are organized around features — a list of things to build. Others are organized around problems or outcomes — metrics to move, risks to reduce, customer segments to win. Those are very different conversations, and walking in with the wrong framing wastes everyone's time.

Find out what your PM is actually measured on. Retention, activation, conversion, support volume — whatever shows up in their quarterly reviews is what they care about. When your research connects directly to those things, it stops being a UX concern and starts being their problem, too. That's when it gets traction. If you don't know what metrics drive your PM's priorities, that's the first conversation to have — before you make any kind of case for anything.

5. Don't Just Present Findings — Make a Recommendation

Research findings are not roadmap arguments. "Users are confused by the navigation" is a finding — it describes a problem and leaves all the interpretive work to whoever is reading it. For a PM juggling competing priorities, that interpretive work is easy to skip. They'll nod, say it's interesting, and move on.

Recommendations are different. A recommendation tells someone what to do with the information. "Users are confused by the navigation, and we think it's contributing to the dropoff at step three — here's what we'd suggest testing," gives a PM something to act on. If you're consistently delivering findings without recommendations, you're doing half the job and wondering why nobody's listening.

6. Time Your Research so It's Useful, not Retrospective

Even well-framed research gets ignored if it arrives too late. A finding that lands after a decision has been made isn't useful, and it trains your PM to brace for bad news rather than look forward to your input.

Map your research cadence, or at least the official reporting, to planning cycles as much as you can. If quarterly planning happens in September, your findings need to be ready in August. A five-person usability study that surfaces a critical problem two weeks before planning is worth more than a twenty-person study that arrives two weeks after.

7. Diagnose Why Research Gets Ignored Before Reacting

Is it a timing problem? Fix it upstream. Is it a framing problem? Tie research more explicitly to open questions rather than just cataloguing observed problems. Is it a trust problem? That one's slower because you build trust by being right, being consistent, and being useful in small ways before you need to be believed about big ones.

Sometimes research gets ignored because it conflicts with something someone has already decided to do. That's not a research problem; it's a political one. The conversation you need isn't about the data. It's about how decisions get made on your team, and whether there's any real process for surfacing disagreement. That conversation is uncomfortable and doesn't always go well, but it's more honest than running another study and hoping this time someone listens.

8. Do the Legwork Before You Walk into the Room

An idea without a rough sense of effort, feasibility, or dependencies isn't a proposal — it's a suggestion, and suggestions are easy to table.

Before you make your case, talk to the engineers who would build it. You don't need a formal estimate — just a directional sense of whether this is a two-week effort or a six-month one. A concept that surprises the engineering team in a planning meeting is a concept that gets pushed. Also talk to whoever else has a stake — legal, data, marketing — not to get signoff, but to know where the friction is before someone else names it as a blocker in front of your PM. You want to surface those potential problems as early as possible, so you’ll know how to fix them or at least respond to them when they show up later.

9. Prepare for the Actual Meeting

Know what you're asking for before you walk in. "I'd like to get this on the roadmap" is easy to smile at and do nothing about. "I'd like two weeks in Q3 to validate this problem before we commit to a solution" is something that requires more of a response.

Lead with the problem, not your proposed solution — one invites a conversation, the other makes people defensive. Anticipate the objections and think through your responses before you're sitting across from someone. Bring something tangible that people can look at and react to. And think about who else should be in the room, or who you should talk to beforehand — an engineer who's already looked at feasibility changes the dynamic considerably.

If the answer is no, ask what it would take to get to yes. You'll learn whether this is a timing issue, a priority issue, or whether the door is closed. Sometimes it is, and it’s always better to learn that early so you don’t waste more time on a lost cause.

10. Advocate for the Work that Doesn't Advocate for Itself

Accessibility and usability improvements get cut when roadmaps get crowded. There's often no specific customer request driving them, no sales team pushing for them, and no new revenue in most cases. If UX doesn't make the case, it doesn't get made.

"This is the right thing to do" doesn't move roadmaps, but legal and compliance risk does. So does audience reach — accessibility improvements frequently benefit users beyond the ones they're designed for. Support-ticket volume, satisfaction scores, and task-completion rates can all make usability investments legible in terms a PM can use to justify the work.

It also helps to reframe the conversation. Usability debt accumulates the same way technical debt does — quietly, until it doesn't. Teams that bolt features onto an unstable interface for years eventually hit a wall where everything costs twice as much to build. That's a risk argument, and it tends to land differently than a design-quality argument.

11. Build Credibility Before You Need Influence

Everything above is harder if your PM doesn't trust you. And trust isn't built in the meeting where you need it.

Have regular conversations that aren't about deliverables. Share what you're seeing in research before it's formally written up. Ask about their problems, not just the ones that overlap with your work. Be honest when you're uncertain or when a previous recommendation didn't pan out — PMs work in an environment where everyone is trying to sell them something, and a partner who gives them the unvarnished version is genuinely valuable.

It's Not Really About the Roadmap

A lot of this comes down to a simple shift: stop thinking of yourself as someone who delivers UX work and start thinking of yourself as someone who shapes product decisions. Those are different jobs, and most design education prepares you for only one of them. The organizational skills — knowing when to show up, how to frame an argument, when to push and when to let something go — get learned slowly, through trial and error and a fair amount of frustration. Hopefully some of this speeds that up.