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.
Thank you, David. I like the additional perspectives you shared.
I agree that roadmaps have different meanings to different people. Some product experts term what I've shared in the post as a plan and not a roadmap. In this scenario, it pertains to a deliverable that leadership wants to see how the engineers will be kept busy in the next 3-6 months. But I agree that roadmaps need to be far more strategic than that.
I also think roadmaps have to remain malleable so that you can adapt as further context reveals itself. It's not a singular transaction like a Product One Page or a locked PRD. It's a living conversation.
I would - but I see roadmaps much more on a higher perspective - think that the North star metric would apply after the roadmaps have been laid. Just like a city planner would create provisions for larger roads later in the city's life (and thereby provide for the initial and coarse road map from there, and then the various projects could now begin to engage their stake holders and create their North Star metrics), so would I think that there is some much more overall planning to be done, not into any details, but at very large strategic scale.
It is my take that very very few projects actually do take off based on a large scale strategic view. I see many projects dealing with petty things, such as "Make a thing which does A, B, C and which can sell". Very rarely I see visionaries who see their products in a much larger scale and really work to fit their product or service into that very much larger picture.
Those majorities who do not do that, in my view, are letting go of suitability of their products or services on a 10 or 100-fold larger scale. And they fail to fit in their products into the environment. (Many do not want to see these scales, as their products or services are directly detrimental or harmful to environment, climate, freedom of people etc. etc.)
Many things which could be taken into consideration without much more than just the idea and then tweaking a part of the service or product accordingly - will be impossible to turn around or tweak, later, when a product is being produced or a service organisation has been constructred.
Therefore, I think the strategic view is key to establish, after which roadmaps would apply, after which the various teams would look into the sky to find each their North Star.
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
Thank you, David. I like the additional perspectives you shared.
I agree that roadmaps have different meanings to different people. Some product experts term what I've shared in the post as a plan and not a roadmap. In this scenario, it pertains to a deliverable that leadership wants to see how the engineers will be kept busy in the next 3-6 months. But I agree that roadmaps need to be far more strategic than that.
I also think roadmaps have to remain malleable so that you can adapt as further context reveals itself. It's not a singular transaction like a Product One Page or a locked PRD. It's a living conversation.
Thank you for sharing.
Amazing thanks!
Is a North Star metric not required to create the roadmap?
I've mentioned it under priority goals.
I would - but I see roadmaps much more on a higher perspective - think that the North star metric would apply after the roadmaps have been laid. Just like a city planner would create provisions for larger roads later in the city's life (and thereby provide for the initial and coarse road map from there, and then the various projects could now begin to engage their stake holders and create their North Star metrics), so would I think that there is some much more overall planning to be done, not into any details, but at very large strategic scale.
It is my take that very very few projects actually do take off based on a large scale strategic view. I see many projects dealing with petty things, such as "Make a thing which does A, B, C and which can sell". Very rarely I see visionaries who see their products in a much larger scale and really work to fit their product or service into that very much larger picture.
Those majorities who do not do that, in my view, are letting go of suitability of their products or services on a 10 or 100-fold larger scale. And they fail to fit in their products into the environment. (Many do not want to see these scales, as their products or services are directly detrimental or harmful to environment, climate, freedom of people etc. etc.)
Many things which could be taken into consideration without much more than just the idea and then tweaking a part of the service or product accordingly - will be impossible to turn around or tweak, later, when a product is being produced or a service organisation has been constructred.
Therefore, I think the strategic view is key to establish, after which roadmaps would apply, after which the various teams would look into the sky to find each their North Star.
Or ?