TLDR: from my perspective as a CTO-doing-product-manager-stuff, the key part of building a roadmap is not what the document says, but what I learn and the connections I make through building it and maintaining it. If I just throw a bunch of features in a planner with no clear alignment to the org's goals and user needs, that's not a roadmap, that's a wishlist. I get confidence in our roadmap when at any given point, I can direct people to it and explain how the future we imagine links to the things in the document. From an engineering perspective, I always appreciated roadmaps when it was clear why something was in there, because it told me there was a plan and not just a bunch of unconnected things in a trello board.
Roadmaps can be intimidating, both to read and of course to create. If they are good, they can be useful in helping stakeholders and users understand where a product is going and gaining alignment as it gets updated with collected inputs, but they often deviate not into a tool for clarity but one of pressure.
With pressure to deliver on made up deadlines come stressful release cycles, and with stressful release cycles come low quality features that get shipped just to get it done before the made up deadline.
After a while, so many things deviate slightly from the plan that nothing makes any sense. It's no longer a matter of pushing a schedule by 3 days but one where plans for an entire quarter are delayed and inconsistent. As a team grows, this becomes an ever bigger problem; executives expect results consistent with the growth of the team, and the teams are now demanding a cleanup of all the mess they had to create to reach the deadlines that someone else imposed.
Roadmaps should be a guideline, an idea of where we're going. I am not even sure they should exist beyond a quarter. When we place a deadline, it should matter. It should mean that is the absolute latest date in which we can deliver safely, not just that someone in the C suite will have a tantrum if it's not done.
Roadmaps should not contain details that are best left for the team in charge of the implementation, and they certainly should not contain detailed lists of tickets that someone will then have to figure out.
Teams should be given the freedom to explore solutions to a problem rather than being presented with the complete solution; it's the people closer to the work who are often able to draw the correct implementation and cut the scope to deliver as much value as possible within a constraint.
Roadmaps should be a tool for clarity. Reasonable roadmaps cannot be built in 30m meetings in a vacuum. When it comes to roadmaps, I think the heavy work of doing them is what brings the highest value. Analyzing customer usage, insights, feedback. Talking with users, with support, with stakeholders. Figuring out what the space looks like outside your org. Figuring out if the current state aligns with the organization's vision for the future. Understanding in detail the why, and not worrying too much about the details of the what. Comparing what would not get done if this other thing gets scheduled. Understanding the trade offs.
It's not so much the roadmap that matters, but the process and learning that got it done.
Roadmaps are not just the what, but the why, when, and for whom.