Why date-based roadmaps are valuable for Agile product teams

Why date-based roadmaps are valuable for Agile product teams

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!

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). 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). That’s where planning objectives on a timeline roadmap is useful. 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.

Multi-team planning

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 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.

Granular features planning in time 

Now teams can use Productboard’s features timeline roadmaps to track progress against specific deadlines and milestones and align internally on concrete dates. Planning features and tracking progress with a timeline roadmap is ideal if you want to get a 1000-foot view of how work is progressing toward a deadline or time bound milestone. You can allocate resources when and where they’re needed, while communicating to internal teams (like sales, customer success, or marketing) when specific features are launching.

While Features timeline roadmaps are popular, they should be used with caution! Often, feature timeline roadmaps get too far into the weeds or overcommit your team to specific deadlines that can change.  

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 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.

A final note on 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 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.

.     .     .

Ready to get started with timeline roadmaps?

Productboard’s roadmaps are easier and more flexible than ever before, while remaining backed by customer feedback and connected to development tools. Product managers can quickly create and share easy-to-maintain roadmaps for every scenario and stakeholder and even manage complex product portfolios and multiple product teams. Using Productboard, product managers build cross-functional alignment, improve team productivity, and accelerate product planning cycles.

Access a free trial of Productboard today

Already using Productboard?

Features timeline and Releases timeline roadmaps are available on all plans. Objectives timeline roadmaps are available on the Scale plan and higher. Get started with timeline roadmaps today.

You might also like

The building blocks of excellent product roadmaps
Product Management

The building blocks of excellent product roadmaps

Productboard Editorial
Productboard Editorial
4 steps for building outcome-driven roadmaps
Product Excellence

4 steps for building outcome-driven roadmaps

Dottie Schrock
Dottie Schrock
7 examples of excellent product roadmaps
Product Management

7 examples of excellent product roadmaps

Cindy Berman
Cindy Berman