I'm not posing that this is the preferred or only way of creating a product roadmap. (I used this image because it's familiar with people when they think about product roadmaps).
I think a roadmap should be created based on the audience that's consuming it. So the answer in many cases is, "It depends."
That could be a way to go. Another option to represent time in a less fixed manner is to use a now-next-later roadmap schema.
It's more to the point of what's important vs. time as a measurement.
Certainly important, and I could try to fit it in here. But I feel it fits better in an article that talks specifically about the financials of product development (in general).
I could of course mention it and link to a piece that's relevant.
Not sure where I'd put it in my current article though. Maybe under the 'purpose of a roadmap' part.
Gantt charts are not my preferred way of mapping out a vision and direction. But like some others stated, many orgs just like to work with that. It's also why I chose it as the header image, because it's familiar.
Kinda bummed out that would keep people from reading the article, but not I can't cater to everyone.
Good point in the difference between a software engineering (SE) team and engineers within a ship.
I've worked as a software engineer myself and indeed SE's usually have a clear view on helping shape the product. Though, depending on how big the org is, engineers may not have much of an influence on the vision (why a product gets made for the user).
So yes it depends. I could certainly highlight where the analogy doesn't work (though at the moment of writing it felt I'd take away from the main point).
Thanks for writing such a clear piece of feedback. I think you're right in that the analogy doesn't fully translate. And I may yet rewrite that.
At the moment it felt like a fun small story to intro the idea of a map.
About the living document part, maybe I've not emphasized it enough (it could come earlier in the article maybe).