I finally want to say thank you for your step-wise approach, with pre-reading, sandbox, listening tour, reading the market, foundation pillars, inspection of repos (A bit agile...), Roadmap processing - now crafting the first roadmap draft, ...
I think your work here is very inspiring, and I have copied it into a document. In my opinion we need some sort of tool where we can collect links, content, documents, and everything in a searchable way for later use. All too often I find articles in links which I then try to access only few months or maybe a year or two later - only to then find them gone, deleted, or similar. There is a very high churn rate on good stuff, and once found something nice on the internet - it is oftenly extremely difficult to retain it in a workable way. And even if we can retain it, it is difficult to search it.
I like your entire approach, Aatir. I like for instance a bunch of your comments in your writeup, ie.:
"Companies that are uninitiated in the “ways of product” demand a roadmap as the first deliverable of a newly hired PM a few weeks into the job, affording them limited time for due diligence"
"A lot of PM content out there focuses on building a roadmap in more favorable conditions where the org affords the freedom to the PM to research, analyze, and deploy processes"
However, I would like to bring another perspective to it, or maybe dimension. It can also be that we are discussing culture here, and may even be we are discussing nomenclature.
Because, you also write: "Roadmaps are NOT the first step in product development."
So, here I typically take a different way, and here maybe I look into it all from an architectural point of view. Both technically and also a bit linked to the original meaning of architecture : I see the roads as connection points at a much larger scale, between infrastructural constructs, such as buildings. On the technical note, I see roads connecting entire projects, and I see projects as vehicles oftenly creating products or services.
So. When I have been hired to handle products, or projects, I have instead ASKED for the roadmap, connecting the other products or services or infrastructures in the companies I have worked for, and in lack of that, I have seeked to ensure that we in fact construct that strategic piece of work, prior to developing on products.
Furthermore I have avoided any closure on the roadmap, but instead - just as the engineer and architect would have done it - created provisions for other products, services and architectures and infrastructures - so - as indeed there is rarely time to "research, analyze and deploy processes" - but - many who take the hat of the "architect" on their head also think that they have to design the entire city of all buildings, sewage lines, electrical structures etc. upfront - very much prone to failure like its sibling the "Waterfall model", characterized by a linear and sequential process where each phase (analysis, design, programming, testing) had to be completed before moving on to the next. The Waterfall Model had its shortcomings, particularly in software development, because it didn't allow for much flexibility or adaptation to changing requirements, which often led to project delays and issues
Now, surely, in business, there are certain points in time, where one must put one's foot down and declare "a point of no return" - also in typical PM work called "A mile stone". Many a mile stone has in my view, due to application of such rigid structures become a mill stone around peoples neck rather than a mile stone which actually CAN be moved, as long as one also changes the inscription on it :-).
Therefore, I tend to think that maybe the word "roadmap" may have different meanings and connotations. I think, however, that your treatment of this entire topic is interesting, thought opening and it is pleasant that you have taken up this topic. I am quite sure that really many businesses would benefit from reading your writeup here. And I also think quite a lot of businesses would benefit from creating everything they do, to the largest extent possible, such that these can be changed, modelled, modified, fitted - to future developments, without leaving it all as a brand new building compound where nothing is being touched out of fear of not fitting to the future.
I love this, amazing job. This is also a good reset if things go out of control, too many priorities etc.
I finally want to say thank you for your step-wise approach, with pre-reading, sandbox, listening tour, reading the market, foundation pillars, inspection of repos (A bit agile...), Roadmap processing - now crafting the first roadmap draft, ...
I think your work here is very inspiring, and I have copied it into a document. In my opinion we need some sort of tool where we can collect links, content, documents, and everything in a searchable way for later use. All too often I find articles in links which I then try to access only few months or maybe a year or two later - only to then find them gone, deleted, or similar. There is a very high churn rate on good stuff, and once found something nice on the internet - it is oftenly extremely difficult to retain it in a workable way. And even if we can retain it, it is difficult to search it.
I like your entire approach, Aatir. I like for instance a bunch of your comments in your writeup, ie.:
"Companies that are uninitiated in the “ways of product” demand a roadmap as the first deliverable of a newly hired PM a few weeks into the job, affording them limited time for due diligence"
"A lot of PM content out there focuses on building a roadmap in more favorable conditions where the org affords the freedom to the PM to research, analyze, and deploy processes"
However, I would like to bring another perspective to it, or maybe dimension. It can also be that we are discussing culture here, and may even be we are discussing nomenclature.
Because, you also write: "Roadmaps are NOT the first step in product development."
So, here I typically take a different way, and here maybe I look into it all from an architectural point of view. Both technically and also a bit linked to the original meaning of architecture : I see the roads as connection points at a much larger scale, between infrastructural constructs, such as buildings. On the technical note, I see roads connecting entire projects, and I see projects as vehicles oftenly creating products or services.
So. When I have been hired to handle products, or projects, I have instead ASKED for the roadmap, connecting the other products or services or infrastructures in the companies I have worked for, and in lack of that, I have seeked to ensure that we in fact construct that strategic piece of work, prior to developing on products.
Furthermore I have avoided any closure on the roadmap, but instead - just as the engineer and architect would have done it - created provisions for other products, services and architectures and infrastructures - so - as indeed there is rarely time to "research, analyze and deploy processes" - but - many who take the hat of the "architect" on their head also think that they have to design the entire city of all buildings, sewage lines, electrical structures etc. upfront - very much prone to failure like its sibling the "Waterfall model", characterized by a linear and sequential process where each phase (analysis, design, programming, testing) had to be completed before moving on to the next. The Waterfall Model had its shortcomings, particularly in software development, because it didn't allow for much flexibility or adaptation to changing requirements, which often led to project delays and issues
Now, surely, in business, there are certain points in time, where one must put one's foot down and declare "a point of no return" - also in typical PM work called "A mile stone". Many a mile stone has in my view, due to application of such rigid structures become a mill stone around peoples neck rather than a mile stone which actually CAN be moved, as long as one also changes the inscription on it :-).
Therefore, I tend to think that maybe the word "roadmap" may have different meanings and connotations. I think, however, that your treatment of this entire topic is interesting, thought opening and it is pleasant that you have taken up this topic. I am quite sure that really many businesses would benefit from reading your writeup here. And I also think quite a lot of businesses would benefit from creating everything they do, to the largest extent possible, such that these can be changed, modelled, modified, fitted - to future developments, without leaving it all as a brand new building compound where nothing is being touched out of fear of not fitting to the future.
Thanks for your insights shared.
Sincerely
Rational Intuitive ltd. / SkYFi Energy Ltd.
David Svarrer
CEO / CTO
Amazing thanks!
Is a North Star metric not required to create the roadmap?