The dreaded roadmap
Once I was asked to provide a quarterly roadmap for a product that didn't exist yet, and was held accountable for meeting it. It didn't go well, and in retrospect I should have just refused, but on the other hand I probably would have been fired, so instead I did the only thing possible: I provided a figment of my imagination in the hope that my management would go away and we could continue working. Hopefully by the time we had a product the roadmap would be forgotten. We never had a product, at least not while I was there, so the end result was the same.
The figment of the imagination wasn't that much the list of features (those actually made sense), but the quarterly schedule. The development of the product was at an early stage and we had no real idea of how long it was going to take, let alone what would be the fabled quarterly iterations that we were asked to commit to.
This led me to the first lesson about roadmaps: until you have a product, you don't need a roadmap (you also don't need product managers but that's another story). Until you hit 1.0, your focus should be solely on getting the product out of the door as fast as you can. Instead of thinking about schedules, demos and incremental deliveries, you should think about how to enable your team to work as fast and as effectively as possible and show visible progress day after day, progress that gets closer and closer to the product vision, or further enough that you know some steering is required.
Once you do have a product, unless it's perfect, it has no competition and it generates revenue over time until the end of times, you will need to evolve it. At that point you need a roadmap. The roadmap is very important to convince customers that it's worth staying with your product, and to convince your team that there is interesting work coming up. The roadmap is the "what" and it should not be confused with the project plan, i.e. the "how". A roadmap is not concerned with development milestones, dependencies and some such (however it is used to inform these)
While I was dealing with the quarterly roadmap request above, I participated in a meeting with a potential partner and we exchanged roadmaps. Their roadmap is the one that really opened my eyes. It said "avaialble now", "2024" and "2025-2026". No concrete delivery dates, just the stuff they thought they were going to do 'at some point" with increased level of vagueness. Unlike our quarterly roadmap, this was actually useful, interesting and, most of all, honest.
Product leaders that I respect seem to agree that the best format for a roadmap is the now-next-later roadmap. I.e. what you are working on at the moment, what you will be working on next, and what ideas you have about what you might work on later. The timeframe of what is next and what is later depends on your product and how quick it is to add and release features. It can be current sprint/next sprint/backlog, current/next timeboxed released or this year, next year, future.
In conclusion, the "roadmap" is one of the most overloaded and misunderstood terms in the software industry. It can be a marketing tool, a project plan, a hard commitment, wishful thinking etc. I've never been a product manager so what I wrote is probably obvious to professional in the fields, but I had to learn it the hard way.