The opening analogy between a product roadmap and a literal map is thought provoking. But I think they're actually very different.
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).
If we really want to stick with the analogy, we could treat the map as not fully discovered.
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.
The Captain/Engineer analogy later on also has a similar problem. In my experience, engineering is always a major stakeholder in a (healthy) product roadmap. They often have good ideas for how to shape the product, they define what is feasible/costly, and have to build it in the end. On a ship, I don't imagine that engineering would be very involved in helping to set the direction, but I could be wrong.
Agreed, this seems to be one of those cases where a word was invented that can be confusing when read literally.
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
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).
I would argue about the roadmap being visual. When you present people with the gantt chart, people tend to focus more on the timelines rather than the direction. This inadvertently pushes you to follow clearly defined deadlines and makes your roadmap a release plan instead (which Jira or similar tool is much better at).
We've been experimenting with gantt-style vs a simple table/list-view [1] and found that in many cases the latter actually works better in presenting the product vision, albeit at the expense of longer reading times.
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."
Any article about roadmaps that has a lead in image of a Gantt chart is guaranteed to be missing the actual art of roadmapping. Any sufficiently agile/customer centric product company should never get near Gantt charts, with time estimates and dependency sequences, for roadmapping. No one can predict the future like that.
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.
In the theory you might be right, but any company with a defined budget will simply ask for timelines and see it nicely displayed (often as gantt). Why do you think most Product Manager still use excel? Simply: Management wants this and you are not the boss... just my experience.
I agree, but also any real life product manager will likely have major stakeholders who can only comprehend what's happening or where the budget/time is being spent if they see it in the form of a gantt chart.
In the end, it's just a tool in a box of various others.
Gant charts can be used as a "living document" presenting the latest estimates. While individual task can deviate from the estimations the bigger picture view can be a nice rough estimate. I dont get the hate of the "YOU CANT PREDICT ANYTHING!1!1!" agile crowd subset. Getting good at predictions and dealing with deviations is what project management is all about, using tools that help you in this process is much advised.
This is missing what really matters (business wise) for a product roadmap: ROIC.
Most product roadmaps I see tie strongly to what additional markets/ customers can be served by the enhanced features. That justifies the continued investment in the product-line by the business.
Return on invested capital (ROIC) is a calculation used to assess a company's efficiency at allocating the capital under its control to profitable investments.
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.
[+] [-] unclesaamm|5 years ago|reply
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).
[+] [-] dreamer7|5 years ago|reply
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.
[+] [-] cyb_|5 years ago|reply
[+] [-] catmanjan|5 years ago|reply
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
[+] [-] Jibranio|5 years ago|reply
About the living document part, maybe I've not emphasized it enough (it could come earlier in the article maybe).
Ty
[+] [-] PixelMath|5 years ago|reply
[+] [-] tjomk|5 years ago|reply
We've been experimenting with gantt-style vs a simple table/list-view [1] and found that in many cases the latter actually works better in presenting the product vision, albeit at the expense of longer reading times.
[1] https://www.getshipit.com/blog/should-you-use-gantt-product-...
[+] [-] tootie|5 years ago|reply
[+] [-] Jibranio|5 years ago|reply
I think a roadmap should be created based on the audience that's consuming it. So the answer in many cases is, "It depends."
[+] [-] jSully24|5 years ago|reply
[+] [-] Jibranio|5 years ago|reply
[+] [-] dchuk|5 years ago|reply
[+] [-] Jibranio|5 years ago|reply
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!
[+] [-] esel2k|5 years ago|reply
[+] [-] fookyong|5 years ago|reply
In the end, it's just a tool in a box of various others.
[+] [-] Pilottwave|5 years ago|reply
[+] [-] rubidium|5 years ago|reply
Most product roadmaps I see tie strongly to what additional markets/ customers can be served by the enhanced features. That justifies the continued investment in the product-line by the business.
[+] [-] sequence7|5 years ago|reply
[+] [-] Jibranio|5 years ago|reply
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!
[+] [-] unknown|5 years ago|reply
[deleted]