Agile product road maps are different than the traditional "waterfall" road maps.
Waterfall road maps have major milestones called out and teams can work for months (or even years!) on the deliverables that are planned out to hit those milestones. It's kind of a "set it and forget it" model, to quote infomercial legend Ron Popeil.
Agile road maps differ in that you're only planning work for the upcoming 2-3 weeks. That gives you the opportunity to re-prioritize work beyond that period based on business conditions.
Agile is good in that it gives me, for example, flexibility to change priorities if something more important comes up. However, it's easy to understand how this can frustrate a business partner or client if you're not willing to guarantee a date for something 2-3 months away given how work is prioritized.
That is an understandable frustration for business partners and clients. How do you overcome that? Make sure you're transparent about how you build your road map, not just sharing what's on it. It's okay to let certain people see behind the curtain a little bit. If the end result is more understanding on the part of those impacted by a road map, that's a great thing!
An agile product roadmap is a flexible method of product development that focuses on short-term sprints to achieve greater goals. A common practice in the product management industry, agile product roadmaps keep teams on the same page in regards to the vision and goals for a product. However, agile product roadmaps tend to focus more on short-term procedures and are more flexible than the traditional product roadmap.