Are product roadmaps counterintuitive to agile?

Agile Product Roadmap

As the founder of a company that creates a tool specifically for roadmapping, I’m very familiar with the mixed opinions surrounding agile product roadmaps. As a methodology, agile says: forget about planning on timelines—they’re unhelpful and hard to meet. On the other hand, roadmaps help you visualize your plans, often on a timeline. So is the idea of an agile product roadmap counterintuitive?

Let’s take a look at the facts. Agile is used as a term to indicate that teams are very flexible and willing to change their plans on a daily or weekly basis. That means your project deadlines and dates are pretty insignificant. Yeah, you can add dates to your plans, but if you’re being truly agile (i.e. flexible) expect those dates to change.

Meanwhile, a roadmap usually asks: “Where the heck are we going to be in x amount of time?” As we’ve written about before, not everyone roadmaps along a timeline. But a roadmap almost always looks to the future beyond the day-to-day and week-to-week, even if you’re not visually presenting a timeline. A roadmap is a communication tool for aligning your teams, departments and company, so it will usually function on a longer-term view beyond short-term cycles.

A roadmap is a statement of intent. Not a literal roadmap.

So you’ve got one concept (agile) that sheds the constraints of time and another (roadmapping) that can often seem inherently time-based. Seems pretty counterintuitive. But I’m going to have to respectfully disagree. An agile product roadmap is a valuable tool and quite frankly, the concept of roadmapping fits rather nicely in an agile environment. Here are some reasons why a roadmap does work for agile—and why you should be creating one.

Why roadmaps are NOT counterintuitive to agile

If we look at the defining characteristics of both agile and roadmapping, as well as the realities of the real world, the concepts actually fit nicely together. Here’s why.

1. Roadmaps change as often as the agile world

While there’s this basic understanding of agile, at the end of the day, it’s an umbrella term. You’ve got your scrum shops, your extreme programming teams, your kanban processes and so on. They all fall under “agile.” Each of these methodologies have their own nuances and ways of operating, but ultimately they all share a few major themes:

  • You’re operating in short cycles.
  • Change comes quickly, so you always have to be prepared for it.
  • There is a ton of feedback because you’re operating in cycles that include checkpoints for evaluating your work.

These themes are all rooted in the core idea that when functioning in agile you must be flexible. Adaptability is the key to thriving in agile because you’re always being thrown something new, whether it’s a new cycle, fresh feedback, or the introduction of a competitor to the market.

Just as agile functions on transparency, roadmaps create transparency.

As we’ve stressed many, many times before a roadmap is a statement of intent. It’s not a literal roadmap. Your roadmap should not be an amalgamation of hard deadlines that must be met. It should be an incremental plan that openly embraces change. Nobody has ever created a roadmap that they’ve followed through-and-through. Plans can and will alter, and as a result so will your roadmap.

This flexibility of a roadmap (i.e. statement of intent) pairs extremely well with the very nature of agile methodologies. Roadmaps change frequently, allowing them to easily fit into agile settings—which also get reoriented often.

2. Roadmapping and agile both cut the bullshit

Agile is all about the hard truth—whether you like it or not. Agile methodologies provide realistic versions of how projects are going to play out. If that means a project is going off the rails, you’re told straight up it’s going off the rails. This transparency is part of the reason agile has picked up so much steam: it cuts the bullshit about what can or cannot be delivered.

Just as agile settings function on transparency, roadmaps create transparency. You build a roadmap to be clear with anyone interested in knowing where the hell you’re going. It’s a communication asset designed specifically to align various parties on the what, when and how of your project. And when that plan changes, you present a shiny, updated version.

A roadmap’s function (showing transparency) directly ties into one of the major motivations of adopting an agile methodology (operating with transparency). They’re not in conflict; they fit nicely together.

3. You can’t escape long-term planning

One of the things I’ve noticed when speaking to PMs from different companies is that many of those who claim to be operating in agile environments actually aren’t. Okay, they are operating in some form of agile, but there are still waterfall elements mixed in—so it’s not purely agile. The reason: as your company grows, the harder it gets to ignore long-term planning.

A lot of startups have successfully adopted an agile mentality that dismisses long-term timelines. But as these companies expand, their stakeholders increase, budgets change, sales targets differ and the need to communicate with more people arises. PMs start juggling way more variables which means there needs to be a deeper degree of planning.

As your company grows, it gets harder to ignore long-term planning.

Your dev and product teams may be operating in a super-speedy cyclic fashion, but the rest of the growing company is probably not. The rest of those stakeholders don’t give a damn about this day-to-day or week-to-week psychology. They want longer-term visions to plan out hiring, budgeting, resource allocation and more. A roadmap comes into play to address these long-term goals.

Like I mentioned, roadmaps often look beyond a short-term cycle even if they’re not plotted along a timeline. A roadmap is your opportunity to let stakeholders know how you plan on supporting your daily or weekly operations as the company evolves. You get to say, “Look, we have a plan for this company growth we’re experiencing. This is how we foresee the business evolving to support the daily/weekly tactics for building a better product.” A roadmap helps tackle the pressures of planning that inevitably creep up on your growing company.

What does an agile product roadmap look like?

There are many different ways to structure an agile product roadmap. But having spoken to countless product managers, I’ve noticed a few trends. Here are a few quick agile product roadmap examples. (They each have the same data pivoted on different parameters—and they’re all made in Roadmunk.)

Swimlane-style roadmaps are especially effective for agile PMs. For the teams operating in pure agile (i.e. the ones that aren’t concerned with any dates), it’s common to organize a roadmap by theme. This means the headers might relate to different areas of product development.

Theme-Based Roadmap

theme-based agile product roadmap

If you work in a more structured agile environment, another option is to structure your roadmap by cycle or sprint—and not link those sprints to specific dates.

Sprint Roadmap

spring agile product roadmap

Many agile teams also organize their roadmaps according to “fuzzy time.” This means that rather than stating explicit dates, their roadmap might include loose time buckets like In Progress, Future and Completed. (See here for an example that takes this structure one step further, inserting loose dates by month or quarter.)

Fuzzy Time Roadmap

fuzzy time agile product roadmap

And if you’re an agile-ish team that’s still incorporating waterfall elements, your roadmap tends to have dates with a caveat. Your dates closer to the present tend to be more granular, whereas the further along you go the more abstract (i.e. fuzzy) the time headers become. It wouldn’t be agile if the dates were the be-all-end-all.

Agile-ish Roadmap

quarterly agile product roadmap

Why you need a roadmap, especially for your agile environment

I’ve debunked the argument that roadmaps don’t belong in agile environments, but why do you actually need one? Some thoughts for the not-yet-convinced:

1. Align better with your “makers”

When you say you’re operating in agile, you’re most likely referring to your team of “makers.” These are your developers, product team and designers—the ones who put your product together piece-by-piece. Long-term plans are not a pressing priority for a maker. They’re dedicating big chunks of their workday to building, usually along short(er) delivery cycles. This means they’re more concerned with what they can accomplish in the next hour, day or week than long-term horizon.

An agile roadmap better aligns your makers with teams that are working along different timelines.

By presenting an agile product roadmap, you signal to your makers that you understand how they function. You’re committing to short-term priorities, but also pointing out that the future is “fuzzy.” It will be much easier to align with your makers if you position your roadmap as a living document that aligns short-term priorities and embraces the future’s unpredictability.

2. More cohesion across your company

While your makers are embodying agile principles, other departments and teams are probably not. Your sales team is working in lengthy sales cycles, your marketing team is concerned about your next release, your customer success team has quarterly goals to hit. You’ve got this mishmash of timeframes across the company. And guess who has to align these different psychologies of time? You got it—the PM! (Yay…)

An agile product roadmap better aligns your makers with teams that are working along different timelines. Teams working under more traditional time constraints may have a lot of questions for the teams that are operating in agile. “Why isn’t this done?” “When should we expect this?” “Where is my release?!” Having a roadmap adapted for the agile environment communicates realistic goals to internal stakeholders that may be prying for answers.   

3. Managing ALL the expectations

I think one of the main fears PMs have about roadmapping is that it’ll be a plan they’ll be held to—particularly by internal and external stakeholders. That’s why we constantly push the “statement of intent” definition for roadmaps. But even then, we understand some people will always choose to take things too literally.

That’s the beauty of the agile product roadmap—it gives a PM more flexibility. Not only does it encompass the intent of a typical roadmap, it also captures the flexibility of the agile methodology. A PM can whip out their roadmap and set expectations more easily. “This isn’t set in stone and it will probably change, but it’s what we’re proposing.”

The key is to treat your roadmap as a living document that can and will change.

With this baseline understanding established from the start, PMs’ lives are made a hell of a lot easier in the long run. When those unavoidable changes start to happen and the PM is forced to make a tough decision, people will cause less of a fuss because, well, their expectations were managed at the start. This reduces the amount of conflict that can come down the pipeline and prepares team members for periods of change.

Remember: Your agile product roadmap is still a statement of intent

Most companies nowadays are operating in some form of agile, whether it’s a purely agile structure or a hybrid of agile principles. Whatever your agile style, a roadmap has solid benefits that fit really nicely into any agile environment. The key is to treat your roadmap as a living document that can and will change. In short: a statement of intent.