Why date-based timeline roadmaps are valuable for Agile product teams

Date-based or “timeline” 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 these forthcoming solutions will take, they often haven’t even uncovered the real user 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 have 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 Agile product teams! They help your product team carry out internal planning toward upcoming date-based milestones. They can help you see exactly what teams are working on, and identify cross-team dependencies early to avoid costly delays. And in the short run, they provide a more detailed view of what’s getting delivered when, which helps for coordinating launches and preparing customer-facing teams for product updates. You can even abstract the specific dates on your timeline roadmaps to make them suitable for sharing with all your stakeholders! Later we’ll take a look at how Productboard’s time horizons functionality can help you do just that.

Let’s explore each of these scenarios, starting with the more detailed planning permitted by date-based timeline roadmaps.

Backward-planning from milestones

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 high-level buckets to communicate what gets worked on when with an emphasis on the near-term. 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). This is how many smaller organizations begin using roadmaps in Productboard, 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 plan at a higher-level — prioritizing not which features to build, but which objectives they should tackle. 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.) That’s where planning objectives on a timeline roadmap is useful. When we decide which objectives to tackle next, we plan backwards from these time-based milestones and consider what would be most important to accomplish by then.

Multi-team planning & dependency tracking

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). You can create custom swimlanes to organize your roadmap by team or theme. 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 within 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.

Release planning for the near future

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 work on and release together, and when exactly that will be. Unless it's preliminary pie-in-the-sky thinking, you can expect this type of planning to come later on in the planning process — once features themselves are thoroughly discovered, scoped, and groomed.

Agile teams might want to avoid planning releases much more than 4–8 weeks in advance for the reasons cited earlier. Though if you focus on just the next several releases and the features they contain, release timeline roadmaps can be useful for your own tactical planning and for helping stakeholders understand what's about to be released.

How you can adapt timeline roadmaps to share with stakeholders

We've often wondered what it would be like to have the best of all possible worlds — a timeline roadmap where we can carry out more detailed planning within the product organization, and for sharing with executives, but one that could also be easily adapated for sharing with all our other stakeholders. It would save us from having to have one timeline roadmap, and another high-level now-next-later style roadmap we manage in parallel — all to avoid committing to specific dates that may be subject to change.

The team at Productboard developed an innovative solution for this problem in the form of time horizons. Enabling time horizons on your timeline roadmaps allow you to abstract away the specific dates, rolling everything up to the level of weeks, months, or quarters — whichever time granularity you prefer. After you enable time horizons, save as the roadmap and share it with a broader audience. Both roadmaps — your more detailed timeline-based plans, and your high-level timeline roadmap — will automatically stay up-to-date as plans evolve!

Here's how time horizons help you instantly optimize your timeline roadmaps for sharing with stakeholders:

Using timeline roadmaps when the future is uncertain

We've seen how timeline roadmaps can be useful resources for planning (and even communicating the plan, thanks to time horizons!). 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 colleagues appreciate the rigorous discovery process that features go through between feature discovery, definition, and delivery, 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 timeline roadmaps are invaluable for honing your plans, and even communicating the plan — when abstracted to broader time horizons.

 

.     .     .

Ready to get started with timeline roadmaps?

Productboard’s roadmaps are easier to create and automatically stay up-to-date as your plans evolve! They're backed by real customer feedback to share valuable context that help colleagues appreciate where your product is headed, and why. And thanks to a number of two-way integrations, Productboard's roadmaps are connected to the development tools you already use.

Start your free trial of Productboard today

Already using Productboard?

Timeline roadmaps for features and releases are are available on all plans. Objectives timeline roadmaps are available on the Scale plan and higher. Get started with timeline roadmaps today.