Often the most fiercely debated issue on a company’s product roadmap isn’t related to the product’s functionality or user experience—it’s the roadmap timeline. Specifically, the product team debates whether to include a roadmap timeline, how granular that timeline should be, and which audiences should be allowed to see those date-related details.
Some on the team might want to err on the side of transparency, even when making the roadmap publicly available, while others prefer to manage expectations and avoid setting time-based commitments they might not be able to meet.
Is there a single correct answer to the question of whether or not to include a roadmap timeline?
We would argue the answer is no. These decisions—whether to include a roadmap timeline, how granular the deadlines and time estimates should be, or whether to present a roadmap with no dates at all—will be based on several factors unique to your company and your roadmap goals. But here are a few general guidelines to help with your decision.
Roadmap Timeline Rules of Thumb
- As the strategic, high-level focus of the roadmap increases, your emphasis on deadlines and timeframes will decrease.
- As the tactical focus of your roadmap goes up, your emphasis on deadlines and timeframes should go up as well.
- The more your roadmap’s audience will be focused on tactical details (e.g., your development team), the greater an emphasis you’ll place on timeframes and dates.
- The more you want to manage expectations (e.g., with your sales team or your customer base), the less of an emphasis you’ll place on timeframes and dates.
- The more public your roadmap, the more likely you will be to exclude timeframes from view, and to keep them high-level if you show them at all—e.g., “Estimated availability: Second half of 2018,” and not “Available October 20, 2018.”
What Excluding a Roadmap Timeline Does NOT Mean
Keep in mind we are discussing only whether or not you will display and discuss your roadmap timeline when you present it, and under what circumstances and for which audiences you will want to do so. We are not exploring whether or not you will actually want to think through and develop a timeframe for the major epics, themes, and other strategic items on your roadmap. You will, because timing is always an integral part of a product’s development strategy.
So, regardless of whether or not you plan to present your roadmap showing dates, you’ll still want to develop that roadmap in the context of a well-thought-out timeframe in which you expect the work to be completed.
With that in mind, you have several choices for how to present your roadmap.
Roadmap Style Options: Some with Roadmap Timelines, Some Without
1. Timeline-based Roadmaps
As we noted above, there will be times you review your roadmap with certain internal audiences—your development team, for example, or your executive stakeholders—where the timeframe will be one of the issues you’ll need to discuss.
In these situations, you will obviously want your estimated timelines front and center on your roadmap.
But even here, in internal meetings to discuss product development strategy, we would still caution against using dates that are too specific. We would recommend keeping your timeframes higher level, perhaps estimating an epic or user story to be completed in a given quarter, rather than by a specific date.
Tweet This:
“Keep your roadmap timeframes high level, perhaps estimating an epic or user story to be completed in a given quarter, rather than by a specific date.”
You will of course likely want your teams working toward specific deadlines, but the place to capture and discuss those dates will be in your project management meetings—not while you’re presenting the strategic product roadmap.
2. Roadmaps Without Dates
There are many circumstances under which you will want to show your product’s strategic plan by sharing your roadmap—but without including any time-based estimates.
You might, for example, want a roadmap without dates to share with your existing user base, prospective customers, industry analysts, or other external audiences—because you want these audiences learning about what’s next for your product but without setting them up for disappointment if your team were to miss a promised milestone or release date.
Another example would be presenting your roadmap to your sales teams, so they have an idea of what value propositions and new functionality they should be planning to emphasize with customers. Here, too, you might not want to discuss estimated release dates—even informally—to protect against eager sales reps making promises to customers that your team might not be able to keep.
3. Kanban-based Roadmaps
Another style of roadmap that de-emphasizes dates is a roadmap based on the Kanban-style of project management.
When your team works using the Kanban method, they focus on their current Work in Progress (WIP), the tasks they have on their agenda for the day ahead, and their goal is to continuously complete and deliver work, rather than working toward a specific deadline. This roadmapping method aligns well with agile product management.
For these roadmaps, you will obviously want to focus more on the overall strategic plan and not the timeframe for executing that plan.
What This All Means About How to Build Your Roadmap
As we’ve shown here, throughout your product’s development you will be presenting your roadmap both in situations where you want to share your estimated or desired timeframes and in situations where you’ll find it strategically advantageous to keep those time-based details out of the conversation.
Assuming you want to develop your product roadmap only once, rather than having to create multiple versions with varying views and levels of detail, we believe this is one of the strongest arguments in favor of using native roadmap software—and not trying to build (and rebuild, and rebuild again) your product roadmap is a tool designed for other purposes like creating presentations or spreadsheets.
With purpose-built roadmap software, one of the many benefits is the ability to simply “turn off dates” when sharing the roadmap with an audience you don’t want peeking into your internal timeline plans.
Indeed, best-in-class roadmap tools will allow you to craft your roadmap once (whether it’s for a product, a marketing plan, an organizational initiative, or other types of roadmaps) and then adjust the granularity or focus with just a few clicks. This can save you countless hours of having to build your “roadmap-internal-only” version and then create separate versions for “roadmap-public-view,” “roadmap-development-only,” “roadmap-sales-marketing,” etc.
Bottom line: If you build your roadmap in the most strategic way possible, using purpose-built roadmap software, you will have no trouble at all quickly adjusting your roadmap presentation to any audience—even if that means hiding your estimated timeframes for one meeting, then displaying them for the next meeting, and hiding them again for the meeting after that.
