What to include in a roadmap, and what not to include

A product roadmap is key to creating a shared understanding between your development team and the other departments in your business. But this shared understanding hinges on the quality of the roadmap laid out.

For instance, an overly vague roadmap can lead to customer-facing teams selling vapourware. An overly intricate roadmap, however, can lead to broken promises and broken timeframes.

So, what should comprise a good product roadmap? What goes into it, and what details are better omitted or only loosely outlined?

Here’s our guide on what to include in a roadmap.

What is a roadmap?

A roadmap is a plan that defines the goal(s) of the given product, and the strategies, steps, and milestones that your team will use and meet to achieve it. It’s also an essential communication tool. By outlining your plans in a r oadmap, you create an easy way to share an understanding of the direction and goals of the product.

In short, a product roadmap is essentially the overarching ‘what’, ‘how’, and ‘why’ of your product development. It:

  • Outlines what the product is hoped to be (i.e., the goals)
  • Lays out how the development of the product is likely to look (i.e., the strategy, resources, teams, and timing)
  • Explores why the initiatives and strategies align with the product vision and higher business goals

The roadmap is not a to-do list. (That’s the product backlog.) Rather, it’s a bird’s eye view of what’s happening in development/the company.

What to include in a roadmap?

So, what to include in a roadmap to ensure it is as useful as it should be?

·         Product vision

The product vision is a rough, overarching idea of what the product will achieve in the future. It’s the long-term mission of the product your roadmap is detailing.

·         Product goals

Product goals also detail the future of your product. However, rather than an overarching view, they offer measurable targets for the development team. They define features, functionality, or metric goals (i.e., a certain % churn rate), for instance.

These goals will come with ideal time frames and ways to measure progress. They’re a big part of any product roadmap, providing a solid idea of what your development teams need to get done.

N.B. Goals are not a to-do list — they don’t detail the exact minutia into achieving them.

·         Team dependencies

When deciding what to include in a roadmap, don’t forget to outline the teams/team members that need to be involved. For instance, which goals will require input from marketing, or UX, or sales, and so on.

Including employee roles enables those team members to understand when and where they’re needed, and why.

·         Resource allocation

How much is an outlined goal expected to cost? How many team members are allocated to work on it? Allocation of resources is another must for you to remember in your roadmap.

·         Rough time frames

Another item to add to the list of what to include in a roadmap is (rough) time frames. That is, each goal or milestone that you list in your roadmap should come with a rough estimate of how long it will take, or when completion is expected.

This time frame is not to prescribe a deadline for teams. Rather, it’s to help give an idea of prioritisation, and aid with resource management.

·         Markers and metrics

Finally, your roadmap should also include the markers and metrics that you will use to track progress. These are the things you will measure to ensure that goals are getting closer to being realised.

What not to include?

So, that is what to include in a roadmap to ensure maximum cross-company clarity. But creating a good roadmap is also knowing what not to include.

·         Strict time-frames/deadlines

Every developer hates the dreaded ‘how long will it take?’ question. (Namely because it’s so difficult to answer.) It’s like asking ‘how long is a piece of string’?

When developing software, it’s difficult to predict what will go smoothly and what will require extra time because of unforeseen challenges.

If a product roadmap, then, imposes strict deadlines on teams, it adds stress and can equate to reduced quality in the work completed. A roadmap needs to be a fluid guideline, not a prescriptive schedule.

·         Intricate details

Along the same vein, when deciding what to include in a roadmap, be sure to avoid extra details. Roadmaps need to have flexibility. Technology, after all, changes often and quickly. So, too many details can end up stifling your team and preventing a product from evolving with new tech and customer wants.

·         User stories and granular features

The better place for your user stories and low-level, minor features is in your product backlog. They’re too detailed/prescriptive to feature in your product roadmap. Remember: it’s supposed to be a general plan, not a play-by-play how-to guide.

Instead, stick to broad themes and initiatives. Roadmaps aren’t the place for granular detail, but for broad ideas that you want to achieve. Or, in other words, your initiatives.

Initiatives: objectives for the product that are made up of epics, which are made of user stories.

·         Fixed, long-term plans

Aside from your product vision, nothing on your roadmap should detail long-term plans. Long-term roadmaps are problematic because they rarely, if ever, prove true. They outline good intentions but don’t reflect the reality of the changeable tech landscape.

See also: The problem with long-term roadmaps

Additional advice: beautify it!

A product roadmap shouldn’t only be functional — it needs to be visually appealing too. You want people to be able to easily read and understand it, and that’s enabled by clear design, colour coding, and digestible presentation.

Your product roadmap

When looking at what to include in a roadmap, the important thing is to remember what it’s for: communicating an overarching plan for the product.

In short, include the big ideas and themes, the overall goals and visions, and an idea of the resource and time being used on those ideas. Anything else doesn’t need to feature in a good product roadmap.

Useful links

Definition of done in scrum

A four-point guide to product backlog refinement

The problem with long-term roadmaps