To me this is why OKRs work more effectively (so long as you take the metrics with a pinch of salt) than traditional roadmaps. You're focused on achieving a business state rather than chasing a set of arbitrary deadlines for "Feature X". Smart people suddenly have space to use their brains.
In fact typical product roadmaps end up a source of toxicity in most organisations I've worked in...
- Out-of-date the moment they are published.
- Tying down product managers with moving little boxes around PowerPoint; people who'd be better off getting out of the building and talking to customers or working with engineers
- Causing a blame culture around missed deadlines, sapping everyone's morale
- Needing multiple versions depending on the audience; low granularity for top level management, high granularity for engineers, carefully worded for customers and users e.g. "Add ad tracker" or "Fix bug causing data loss" may not be what you want sales people to present
- Always subject to (mis)interpretation
- Based on wild estimates of how long things will take 3 quarters ahead through the year
- Too focused on shiny deliverables and ignoring things like "We need to have to this quarter for re-writing a major component that blocks everything else"
- Often unread or poorly reviewed
- Bad at visualising dependencies between things being worked on
- A source of silliness like "Why are wasting time doing X when we know we need to be doing Y?" ... "Because it's on the roadmap"
... and probably loads more.
...otherwise - being a bit of a history nerd - I’ve run into the idea many times in discussion of how military units have evolved over time. Much of the thinking about ideal squad sizes began in WW2 - don’t have single thing I can point you at though