I just hear him talking "be credible" "make sure there is evidence..." but not a single time how to actually achieve this. And that is the hard part. Of course a roadmap is only valuable when there is enough confidence that the thing is not utter bullshit. With some things that were mentioned, like prototyping, feasability analysis, they can make some projects take twice the time. So is getting started early and learn on the journey more important or research and analyze before to make more accurate roadmaps?
If you do the right thing and it takes longed (it should not take anywhere near 2x!) but you don't waste your time doing the wrong things you will end up making more progress in less time. The urge to just build it is seductive. Often a feasibility prototype is hours (or at most days) of work. It's just a form of discovery. That allows you to take out risk and drive up confidence quickly and cheaply. You phrase it as an either or, do a lot of up front work or get started. We'd argue it is both. Get started. Write down what you think is the right direction of travel, include the uncertainty and discovery in the roadmap. Then do the discovery and refine. After a few short iterations that initial uncertainty is driven down in the short term stuff and you are showing the areas you are understanding further out. Hint: if you put the customer problems on the roadmap they also tend to be pretty stable - the discovery tends to just help you better understand them and through that refine the solution you will deliver to address them.
@@TalkingRoadmaps That's surely an explanation that makes sense on paper or for some teams. I'm working for a company where we develop one huge product with almost 20 teams. There is so many dependencies (yes we are also in the process of untangling them) that every discovery/prototype won't show very clear results quickly. You could argue that this is our fault with having still many remains of a big monolyth but probably the truth for many other "older" companies out there. So there is no way we can proof the concept good enough in a few days to give a seemingly accurate roadmap for a year or two year long project :(
@@highopay you somewhat answer your own questions. The only real way to scale product work is to descale the work, striving to minimise the dependencies. But you also hint at a key point at the end, a roadmap is not a project plan. It's job is not to provide delivery certainty in a proJEct context. Its job is to communicate and align direction of travel in a proDUct context. By asking a roadmap to do too many jobs we make it do them all badly. In a product context our goal is to ship little and often. But that said we also have to consider the domain. In some domains they are complex - which means that the only sensible way to have certainty is to use methods like agile and lean (aka discovery) - most software fits in this. On the other hand some domains are complicated - which means that planning and analysis are the best approach to take - most physical products fall here. The hard part comes when you have a mixture. Neither mean you can't do discovery to rerisk and increase certainty - the question is how far you want to go with that. You likely can't eliminate risk in a couple of days but you can probably take 50+% of it out. I work with old and new companies alike helping them with this sort of thing.
Satnav is just a digital roadmap with guidance. The risk is you end up on auto-pilot and paying attention so you take the wrong term. The same thing can happen if you treat your product roadmap that way ;)
I don't think it is that simple. It's all about risk. There are times (business reality) that you need to give a date, so you invest in feasibility discovery there. Similalry if feasibility is the biggest risk you should invest in that. Like everything in product "it depends".
What company has enough people or enough time NOT to do feasibility prototypes for every new thing they work on? I mean, unless you're working on things for which feasibility isn't a risk at all - but then you wouldn't really have a problem to solve, because you'd be able to predict dates reliably in the first place. Are predicted dates reliable? If so, you don't have feasibility risks, so probably won't get much value from feasibility prototypes. If the predicted dates are unreliable, do the dates matter? If not, your feasibility risks aren't material and so it's not worth having dates or feasibility prototypes - just go ahead and start working and finish when you're done. I hope your business and customers are OK with that! If the predicted dates are unreliable, and this matters, then .... invest in the feasibility prototypes, because you can't afford not to. Which is it?
@@TalkingRoadmaps I'll take "it depends". Just like, "when will that new feature be done?" It depends on how many other things I have to work on at the same time and how many quality, experienced people I have to work on them.
Would it be possible to add some visual examples?
Visual examples of roadmaps? If so we have a bunch of visual guides in the works so that sort of thing is coming.
Awesome as always. Thanks for the insightful conversation.
I just hear him talking "be credible" "make sure there is evidence..." but not a single time how to actually achieve this. And that is the hard part. Of course a roadmap is only valuable when there is enough confidence that the thing is not utter bullshit. With some things that were mentioned, like prototyping, feasability analysis, they can make some projects take twice the time.
So is getting started early and learn on the journey more important or research and analyze before to make more accurate roadmaps?
If you do the right thing and it takes longed (it should not take anywhere near 2x!) but you don't waste your time doing the wrong things you will end up making more progress in less time. The urge to just build it is seductive. Often a feasibility prototype is hours (or at most days) of work. It's just a form of discovery. That allows you to take out risk and drive up confidence quickly and cheaply.
You phrase it as an either or, do a lot of up front work or get started. We'd argue it is both. Get started. Write down what you think is the right direction of travel, include the uncertainty and discovery in the roadmap. Then do the discovery and refine. After a few short iterations that initial uncertainty is driven down in the short term stuff and you are showing the areas you are understanding further out.
Hint: if you put the customer problems on the roadmap they also tend to be pretty stable - the discovery tends to just help you better understand them and through that refine the solution you will deliver to address them.
@@TalkingRoadmaps That's surely an explanation that makes sense on paper or for some teams. I'm working for a company where we develop one huge product with almost 20 teams. There is so many dependencies (yes we are also in the process of untangling them) that every discovery/prototype won't show very clear results quickly.
You could argue that this is our fault with having still many remains of a big monolyth but probably the truth for many other "older" companies out there. So there is no way we can proof the concept good enough in a few days to give a seemingly accurate roadmap for a year or two year long project :(
@@highopay you somewhat answer your own questions. The only real way to scale product work is to descale the work, striving to minimise the dependencies. But you also hint at a key point at the end, a roadmap is not a project plan. It's job is not to provide delivery certainty in a proJEct context. Its job is to communicate and align direction of travel in a proDUct context. By asking a roadmap to do too many jobs we make it do them all badly. In a product context our goal is to ship little and often. But that said we also have to consider the domain. In some domains they are complex - which means that the only sensible way to have certainty is to use methods like agile and lean (aka discovery) - most software fits in this. On the other hand some domains are complicated - which means that planning and analysis are the best approach to take - most physical products fall here. The hard part comes when you have a mixture. Neither mean you can't do discovery to rerisk and increase certainty - the question is how far you want to go with that. You likely can't eliminate risk in a couple of days but you can probably take 50+% of it out. I work with old and new companies alike helping them with this sort of thing.
No, I just use nav on my phone. I had an "road atlas" once, with lots of road maps (/sarc)
Satnav is just a digital roadmap with guidance. The risk is you end up on auto-pilot and paying attention so you take the wrong term. The same thing can happen if you treat your product roadmap that way ;)
Just say "never give a date".
What company has enough people or enough time to do feasibility prototypes for every new thing they work on?
I don't think it is that simple. It's all about risk. There are times (business reality) that you need to give a date, so you invest in feasibility discovery there. Similalry if feasibility is the biggest risk you should invest in that. Like everything in product "it depends".
What company has enough people or enough time NOT to do feasibility prototypes for every new thing they work on?
I mean, unless you're working on things for which feasibility isn't a risk at all - but then you wouldn't really have a problem to solve, because you'd be able to predict dates reliably in the first place.
Are predicted dates reliable? If so, you don't have feasibility risks, so probably won't get much value from feasibility prototypes.
If the predicted dates are unreliable, do the dates matter? If not, your feasibility risks aren't material and so it's not worth having dates or feasibility prototypes - just go ahead and start working and finish when you're done. I hope your business and customers are OK with that!
If the predicted dates are unreliable, and this matters, then .... invest in the feasibility prototypes, because you can't afford not to.
Which is it?
@@TalkingRoadmaps I'll take "it depends". Just like, "when will that new feature be done?" It depends on how many other things I have to work on at the same time and how many quality, experienced people I have to work on them.
Young William Robinson Kevin Harris Lisa