Foreword
“No roadmap survives contact with reality.”
It’s a saying that has flourished in product management circles for years—for all the wrong reasons.
Roadmaps get a lot of flak. They are often blamed for unrealistic deadlines and death marches. For missing market opportunities, and for building features that are out-of-date before any code is even written.
When I began my career as a product manager, a roadmap was commonly known as a feature-by-feature wish list, outlining releases and delivery dates stretching as far out into the future as the spreadsheet could handle. My own roadmap was a work of art—an all-singing, all-dancing dynamic spreadsheet that certainly pleased the bosses...but terrified the developers and let me down every quarter when it had to be tediously updated to match with all the things we weren’t able to deliver.
I even went so far as to neatly package up this spreadsheet and release it into the wild for others to download. At the time, I thought I was being helpful, but it just fueled the trend for beautiful, but ultimately treacherous, roadmap formats.
And these old artifacts are still everywhere: do a Google image search for Product Roadmap and you’ll see what I mean.
But an old-school roadmap doesn’t fit with modern software development. And a modern roadmap isn’t meant to survive contact with reality.
Just as your first prototypes and MVPs are likely to get trashed in feedback sessions with your early customers, your roadmap is meant to change and adapt as ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access