During roadmapping, each product team articulates the "understand needs" for their product area and what we will do with the information to improve the product. This process is often led by the PMM.
From there, we work with the product team to document hypothesis to test based on information we need to know and detail the best approach to prove of disprove those hypothesis.
At that point, it's all about execution and pulling together what we learn in a compelling way.
With regard to systematically influencing roadmaps, I feel like this is an "always on" job. First, I try to bring the product team along while research is done. That might mean having engineers and designers sit in on customer interviews or sharing early learnings during team meetings. While I typically recommend having some kind of "report out" - as a memo or a discussion / presentation. The final product shouldn't be a surprise.
We often do recaps of everything we learned on a given area at the end of a half, but I find that the real "influence" happens consistently over the course of a year when we share what we learn in ways that can be debated and then acted upon.
Also, very tactically, I find opportunity sizes are really important. Make it clear what you expect will be gained by acting on your findings / solving a need. Findings without opportunity sizes are often a hard sell.