Awesome work!

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."

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.

Thanks for the feedback!

Others already mentioned some about product roadmaps.

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

Yes! It's something I should definitely add to the article. Thanks for pointing out.

Hey, thanks for the feedback.

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.

Cheers!

I'm not an expert in this matter, but it seems that the aspect of the chart that folks are questioning is the timeline. Could it be as easy as removing that aspect to dissuade the perception of a pseudo-commitment when presenting the roadmap?

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.

Cool analogy, thanks. It could be a nice way of explaining it when I eventually get into talking about examples of product roadmaps.

Love this example!

Fog of war is very applicable to product development. And a roadmap is never a 100% correct representation of course. One can strive.

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).

Cheers!

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).

Ty