Eye-opening insights from 700+ product managers & leaders.
Date-based product roadmapping has become a boogieman for modern product teams, and for good reason. All too often, they’re treated as public commitments to ship future capabilities by unrealistic dates. At their worst, they are arbitrary mappings of the feature backlog onto a timeline, with no basis in any reliable estimation of effort. Arbitrary, because not only are teams unclear on what form the solutions for these upcoming features may take, they often haven’t even uncovered the underlying need they should be solving.
No one should be surprised, then, when date-based roadmaps lead to broken promises and false expectations — disappointed customers, lost deals, and distrusting colleagues who’ve been burned by the product team more times than they can count. Even when features are shipped on time, it may only be due to the premium placed on timely shipping. That comes with a steep cost: early convergence on a poorly-researched, non-optimal solution that won’t adequately address any real user need or business objective.
And yet, date-based roadmaps are entirely useful for modern product teams in several scenarios.
We’ll explore each of these below and outline how, contrary to popular belief, date-based or “timeline” roadmaps can be highly valuable for Agile product teams!
When given the option, many modern product teams have cast off dates entirely. After all, they run empowered product teams, not feature factories! They’re striving to bring about real-world outcomes and will happily continue iterating rather than ship the wrong thing on-time.
These teams have often adopted a Now-Next-Later approach to roadmapping, using broad buckets to communicate what gets worked on when. Or they’ve planned discrete releases loosely associated with time that only extend a short way into the future (January release, February release, March release, Short term, Long term). These approaches summarize how many have used roadmaps in productboard to-date, and to great effect. They provide the right level of granularity when communicating the plan to stakeholders and provide plenty of room for the team to adapt the plan as they go.
But for larger organizations and those working in more complex environments, there comes a time when product leaders must abstract a level higher and prioritize not which features to build, but which objectives they should tackle (which later will inform which features get prioritized). And often, time becomes a key input in these decisions. There are Gartner analyst briefings to consider, industry conferences, multi-pronged marketing launches, and the occasional commitment to a strategic partner or major customer. (Note: We still recommend only making such commitments with extreme caution, and only when the commitment aligns closely with your product vision.) When we decide which objectives to tackle next, we backward-plan from these milestones in time and consider what would be most important to accomplish by then.
Of course, what can get accomplished in any time period depends on team capacity. Typically, teams focus on one product objective at a time. As the top-priority objectives become clear you can assign them to teams and consider what might be tackled in parallel (or by the same team sequentially in time). That opens the question of dependencies. Is there work that one team must tackle before other work can get started? Only timeline roadmaps can offer sufficient granularity to carry out what-if style planning amid complex variables like team capacity and dependencies.
Only timeline roadmaps can offer sufficient granularity to carry out what-if style planning amid complex variables like team capacity and dependencies.
And yet even in these cases, precise dates may matter little. It is really an exercise of considering the sequence in which you’ll need to tackle major objectives, as much from a strategic standpoint as a technical one. Here the duration of each objective is like a stand-in for an effort estimate. It’s the first indication of how complex you think an objective might be to tackle.
That leads us to the ultimate goal of much multi-team planning. Once you’ve clarified your plans amongst the product team, you’ll need to communicate those plans to executives. With an objective-based timeline roadmap, you can share the product objectives you’ll be working on (and how they support company goals). You can show what each team will be working on, over various time horizons, and in relation to key milestones. And you can indicate the cost of various objectives in terms of time/duration. It’s the ideal roadmap for making the case for more engineering resources, or to illustrate the tradeoffs that must be made to reach some milestone in time.
When you’re planning objectives along a timeline, you have the advantage of remaining high-level. But as you prepare to plan sprints and launch activities you’ll want to decide which features to release together, and when. You can expect this to come later on in the planning process, once features themselves are thoroughly discovered, scoped, and groomed.
If you’re working in an Agile environment, you may resist planning releases much more than 4-6 weeks in advance for the reasons cited earlier. Though if you focus on just the next several releases and the features they contain, timeline roadmaps can be useful for tactical planning.
We’ve seen how timeline roadmaps can be useful resources for planning and even communicating the plan to select audiences. But how does this square with the uncertainty we face in Agile environments, where time horizons may fluctuate wildly as we progressively learn more about the problems we’re solving?
Well, Agile product teams working in complex environments have no choice but to plan. Those plans may be subject to change, but the very act of planning helps clarify the strategy, think through dependencies, quantify risks, and loop in potential collaborators. Plans get the ball rolling.
“No battle was ever won according to plan, but no battle was ever won without one… Plans are useless, but planning is indispensable.”
— Dwight Eisenhower
The roadmaps you use for planning may differ from those you use for communicating the plan. This depends largely on the audience and the expectations you set. More important than expectations (“hey folks, please realize these dates are subject to change”) is culture. Are sales, marketing, and customer success bought into Product Excellence? Do they appreciate the rigorous discovery process that features go through between the time strategic roadmaps are defined and features are delivered, and how this can impact timelines? Have they seen firsthand how learnings (perhaps based on insights they may have contributed!) have spurred the product team to adapt the roadmap to ensure the right features are getting delivered?
It’s a process to shift organizational mindsets, and until then it’s best to share date-based roadmaps with care. But in the meantime, there’s no doubt they can be invaluable for defining your plans.
. . .
productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence methodology, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next.