In Age of Empires, a historical strategy game, you start with a few villagers and ,in some campaigns, an end destination - a relic to acquire or an empire to conquer.
This is similar to the founders starting a company with some idea of what the end result looks like.
But the villagers can only see a little ahead from their current position in each direction. So they have to go exploring. As they explore, they may discover unnavigable terrain like cliffs or rivers that they have to cross in the direct path to their destination. They may also come across hostile armies on the way.
As startups build their first version of the product, they too would have explored a portion of their domain before deciding on the roadmap. They encounter competing products with the same set of features which they'll have to overcome with more features or better versions of the same features. They too hit dead ends and pivot into a related product or service.
Another key feature of the game is that you don't get permanent visibility into the areas of the map that you have explored. You'll need to have watch towers or a portion of your army there to know what the rest of the empires are planning and how the area is developing.
Startups too cannot claim expertise in a field for long without constantly keeping up with new developments. But founders can choose to evolve their roadmap to keep them more attuned to certain domains and for more outfield developments, they may not want/ need to revise their product roadmap.
Fog of war is very applicable to product development. And a roadmap is never a 100% correct representation of course. One can strive.
On a warship at least, engineering would make inputs into command decisions, at least by identifying constraints such as when maintenance is required, redline limits, etc.
In fact the Kirk / Scotty relationship (as per classic Star Trek) is a fairly good model, except that there would be multiple Scotties, representing other functions such as damage control, weapons teams, etc. These different teams would have to mutually deconflict, e.g. scheduling maintenance / repair around critical warfighting activities.
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).
Cheers!
I'd say a product roadmap is more like a product recipe - you already have (or can get) the ingredients, so the roadmap is like the cooking method with charts
About the living document part, maybe I've not emphasized it enough (it could come earlier in the article maybe).
Ty
As remarked in other comments - once the objectives are agreed, the product roadmap can often crowdsource itself from other functions - engineering, design, etc.
One great book I think almost any Agile PM should check out is "The Professional Product Owner" by Don McGreal and Ralph Jocham.
Essentially they take you through Agile Product Management.
Thanks for asking, cheers!
Jibran
A product roadmap describes this direction and intent for a product that doesn't exist yet, like where you plan to go.
A map, on the other hand, is more of a summary or representation of _past_ knowledge. You create a map as you explore the territory to reflect what you've seen. And sure, you consult a map before setting out too.
I think this distinction is actually critical, because becoming too attached to a product roadmap as if it were a literal roadmap that can guide you to your destination is one of the main flaws of poor product management. The author mentions this a little in saying the product roadmap is a "living document", but I don't think it's emphasized enough. It's not just like a map that gets updated occasionally, instead it's more like this fabricated fantasy road trip plan (one that you have to undergo without an actual map).