Good questions Logesh! I’ll be able to answer the first two of them, as I didn’t quite understand the third one.
To your first question about triggering changes in your roadmap, it probably helps to keep in mind that lots of things will change your roadmap. Every day, as you build and measure, you should be constantly learning, and those lessons will be translated into new hypotheses, new experiments, and sometimes even entirely new problems to tackle on the roadmap. Don’t think of your roadmap as a fixed document outlining what will be done, but instead a flexible artefact that is used to outline your assumptions and change them as you learn more. It’s there to make sure that you and your team have the same assumptions, and that you’re all pointing in the right direction. If you learn something new that means you need to change your course, capture it in your roadmap and make sure everyone’s on board!
This takes me to your next question, about how to get tricky stakeholders on board with your roadmap. The best thing you can do is change your language around your roadmapping processes. Don’t talk about features and delivery dates on your roadmap - that’s your release plan which is a different, and much shorter term document. Instead, talk about the roadmap as a prototype to check your assumptions about the challenges the company will face going forward, and the experiments you might run in order to solve each of the problems. Take the pressure off the roadmap from being some perfect oracle of what will be build, and instead take advantage of what it’s strong at, which is checking assumptions about the future. That said, different stakeholders can be tricky for different reasons. If you find that your hands are tied and you’re still being asked to make an old school timeline roadmap, here are a number of ways you might break it down and make your argument: Free Your Product Roadmap and Ditch the Timeline - Mind the Product