"We allocate 100% of our resources to the roadmap. We plan to use the other 100% of our resources for special projects." — Johnson's Roadmapping Conundrum.
The roadmap is one of the most common tools requested of product teams by executives, development and operations, sales and marketing teams, and key customers.
But here’s the rub: A roadmap is not a task list or project plan. A roadmap is a vision document showing where the product might be headed over the next few months or years. Yet, in a 2020 survey, 22% of product managers use the roadmap to communicate specific deliverables and release dates. That’s not a roadmap; that’s a release plan.
A roadmap is a prediction, like a weather forecast. And sure, execs and others want details but, like the weather, those details cannot be known with all the variable factors including changing team members and changing requirements. And changing market conditions! Who planned on completely re-thinking their office setup due to COVID-19? Productivity plummeted while workers set up remote offices and learned to collaborate using cloud-based tools.
So what do you know to be true? And what are your hopes?
While you hope a certain feature will be available by a certain date, the truth is you simply do not know—unless you've seen the feature working. You can be fairly specific only on deliverables that are near-term. The rest falls into the "hope" category.
The Public Roadmap
We emphasize the COMPLETED items in the roadmap. Many readers seem so focused about what’s next that they forget about all you’ve recently delivered. That's why it is tremendously important to remind stakeholders—executives, salespeople, customers—how much you’ve accomplished.
Stories in the SOON column are being worked on today as we speak. Unless something really bad happens, the stories will be completed in the next few iterations or sprints, typically within a quarter. The more working samples you've seen, the more confidence you'll have talking about them.
Stories in the LATER column are those you have ready for development but have not been started. That is, even though no one is actively working on it, it's ready when the team is ready. That means you've had your planning meeting and the product team has agreed with the stories and the acceptance criteria.
Everything else is science fiction—these are future deliverables with an indeterminate timeframe. All we know is that they're on the list. These stories haven't been researched, they don't have details, and they don't have acceptance criteria. Sure, put it on the list but future surely doesn't mean any time soon.
Here's the ultimate problem: most teams allocate 100% of their resources to the roadmap yet expect those same resources to be used for new ideas, requests from high-visibility customers, and "just one thing" to close a deal.
The Roadmapping worksheet
A Roadmapping worksheet is a working document designed for identifying all the issues that may impact your plans.
With the roadmapping worksheet, you can document markets and personas you want to target, major features or capabilities, and technology directions (such as moving from on-prem to cloud). The rows for industry and company events will guide your decisions on when to deliver new functionality. For example, Apple announces new software at their June developer’s conference and announces new hardware at their September event in time for Christmas sales.
If you’re using the worksheet as a status report, the row on “Surprises and Gotchas” can be helpful for showing big customer requests or industry announcements that impacted the plan.
Don't put too much detail on your public roadmap; put details in the Roadmapping worksheet or release plan. For a roadmap, use themes. Provide what you know to be true.
Or as Mark Twain said,
"Stick to the truth. It's easier to remember."