If an engineer really goes and thinks they should evaluate a roadmap like this, that's toxic.
If the answer is "very few" then that might be an early warning sign you're working for a product or org that is headed for serious problems. As a technical IC who can't hope to solve those large scale management problems, this can be useful a red flag. Don't wait for shit to hit the fan to leave.
I have seen a large scale failure of this kind and the items listed here line up very well with some of the root causes I observed.
- Is the roadmap flexible or iterative? The roadmap was hard, aggressive business targets.
- Are the roadmap initiatives scoped and prioritized based on evidence? The roadmap initiatives were derived by working backwards from business targets and then evidence was found after the fact.
- Does the roadmap identify major dependencies or risks? Many risks were identified much later because techincal teams were not part of input to initial planning.
- Does the roadmap feel aggressive but achievable? Aggressive but not physically possible.
- Does the roadmap take on appropriate risk? No, there was multiple possible independent points of failure.
Anyways, if you ever see this kind of product culture I suggest running for the hills unless you like having your time wasted. And if you are a technical manager I hope you push back like hell when presented with this situation.
The thing that I don't expect is that the roadmap would stay static. Reality changes over time, you encounter new customers and opportunities, learn what's harder or easier than you thought, etc. So I would say "this is what we have today" and if that evolves somewhat even a few months down the line as we learn more, great. But at any given point, you should be able to articulate your best understanding in something that does hit against these checkpoints.
But if it's say in the next few months we better have a good stab at what the MVP or the next iteration and the initial market could look like.
I also agree that low-level teams might be very far removed from strategy, especially in large orgs. However, that team should have a clearly defined goal or mandate instead. So much of the product is context-driven, and the first few drafts were 3-4x longer to account for these differences between organizations, hierarchy, teams etc. I removed most of that to focus more on basic principles because this guide was starting to look like it was written by Charlie Kelly chasing Pepe Silvia accounting for all the edge cases :)
One piece of advice I’ve learned the hard way, however, is if the road map doesn’t make sense, it’s unlikely that making noise is going to make your life better.
I was reminded by this article of the time when my role as a PM was stymied by a lack of clear corporate strategy - I was told to make a road map without the support of any kind of goal or vision, told even that having a strategy would take “11 weeks” (yeah, an oddly specific number). Of course, I pushed back - but the outcome of doing so was very poor for me.
A road map doesn’t need to perfectly align with the very good points in your article, but there is a point at which it’s probably just better to cut and run.