From inception to development, there’s a lot that can go wrong in a project’s life cycle. (There’s a lot that can go right, too, especially when you use a product roadmap! But more on that later.) On paper, sales, development, and marketing are all on the same side, but it often doesn’t feel that way in practice. Miscommunication, delays, and other snags are practically a given. 

So how can you maintain a project’s momentum and avoid getting caught in the weeds? You need something to get you from point A (inception) to point B (product launch). You need a map—a product roadmap.

What is a product roadmap?

Let’s start with the obvious: A product roadmap, as the name suggests, is a map. And, like most maps, it lays out a route between point A and point B—in this case, the beginning and end of a project’s life cycle. Project managers use product roadmaps to visualize the development of a product or service over time. It acts as a single source of truth for stakeholders, documenting the product goals, priorities, milestones, and direction from beginning to end.

At their core, product roadmaps are a communication tool. Developing and launching a product takes the cooperation of engineering, marketing and sales teams. Getting them to work together can feel a bit like wrangling cattle. They’re all pulling in different directions. Sales wants to sell the product and might make promises engineering can’t keep up with. In turn, your developers might hit unexpected delays and forget to communicate them to other stakeholders. The result? Even more delays. Your cows are out of the corral and running amok. 

So, there’s a lot that can go wrong—you’ve probably gotten that much. Here’s how product roadmaps can help things go right. 

Project managers visualize product roadmaps to facilitate communication and cooperation. A product roadmap—circulated across teams—should answer three questions: 

1. What aspects of the project (features, marketing collateral and campaigns, etc.) need to be developed? 
2. When do they need to be finished? 
3. Who is responsible for them? 

This helps everyone stay on the same page and keep track of what work is getting done, who is doing it, and when.

What does a product roadmap visualization look like?

Product roadmaps are divided into vertical and horizontal swimlanes. Across the top, a product roadmap is broken into windows of time (months or quarters, for example). These are the columns. Each row represents a different team associated with the project. Features and tasks are placed in these rows and positioned from left to right according to their respective time frames. (Tasks to be completed in the first quarter would be placed in the first column, etc.)

The goal of product roadmapping is to break a long project—often at least a year—into smaller, more manageable deliverables. To achieve this, tasks are broken down into units of varying size and complexity. 

There are four standard units found in a product roadmap: stories, epics, initiatives, and themes. 

Stories

Stories are the smallest unit used in product roadmapping. A user story represents a single feature that will exist in the final product. The development team assigned to a story typically completes the task in a short sprint.  

Stories help keep development user-focused. As the smallest unit within a product roadmap, stories are the building blocks for the entire diagram—and because they focus on user functionality, the entire roadmap is built with the end user in mind. 

Epics

An epic is a group of related stories—these stories might be interdependent or just linked by a unifying objective. Epics extend through multiple sprints, typically lasting between three and four months. 

Initiatives

Initiatives are groups of—you guessed it!—epics. (You’re probably picking up on a pattern here.) Whereas epics and stories are specific to a single development team, initiatives are high-level and can include multiple teams across an organization. 

Themes

Themes are the broadest organizational unit in a product roadmap. Themes are goal-driven, general objectives. Say, for example, you are developing an e-commerce site. One goal might be to reduce cart abandonment. Cart abandonment would become a theme within your product roadmap. Any initiatives or epics related to cart functionality would fall under that theme. 

Though most of the tasks included in product roadmaps are geared towards developers, roadmaps should be shared across teams. Product roadmaps help keep the engineering team on track and user-focused, but they also keep stakeholders up-to-date and informed. A roadmap gives each team involved a set of actionable goals and dates to help move the project forward, and shows each team’s role within that plan. 

How to build a product roadmap

If you’re not already using product roadmaps as a project management tool, now’s the time to start! You’ve read up on the value of roadmaps and understand their constituent parts, so there’s just one thing left: creating your own product roadmap. 

Before you dive into diagramming, loop in the appropriate stakeholders. A project manager creating a product roadmap on their own is like a cartographer drawing up a map without surveying the land—the end product won’t help anyone get anywhere. 

As you build a product roadmap, consult engineering team leads and managers from your marketing and sales teams to break your project into tasks and set realistic deadlines. Together, you’ll visualize a roadmap that takes each team’s strengths and limitations into account. 

Now, back to roadmapping! While your finished roadmap will be specific to your project, these general guidelines will help you get started:

1. Determine your timeframe

As you decide on a timeframe for your roadmap visualization, consider two things: When do you want the project finished? And can the engineering team feasibly meet that deadline? (You’ll have to ask the engineering leads to answer that one for you.)

Once you’ve agreed on an appropriate duration for the project, determine whether you’d like to measure progress in quarters, months, etc. These units will be represented by the columns in your roadmap. 

2. List contributors and determine tasks

What teams will contribute to the project? List them on the left-hand side of your diagram, giving each team its own row. (For the most part you’ll want to assign tasks by team, not individual—otherwise you’ll end up with a cluttered roadmap.)

Once you’ve listed the contributors, begin to divide your project into themes, initiatives, and so on until you’ve listed individual stories. You may find it helpful to start with larger items—such as initiatives—and work your way down towards epics and stories. 

Take this list of tasks and begin to fit each item into your roadmap. Remember: Each item should correspond with a window of time (a column) and a team (a row). As you do this, don’t forget that this is a collaborative process—consult appropriate stakeholders to assign tasks and determine when they should be completed. 

3. Share your roadmap

Your product roadmap isn’t going to keep anyone on track tucked away in a drawer. Share your roadmap with every team involved in the project—it should be a single source of truth. Because roadmaps present your project as a series of clear, actionable goals with established deadlines, they can also help you secure buy-in from executives and investors. 

4. Maintain, maintain, maintain

A product roadmap is never really finished until your project is finished. If you view your first iteration of the roadmap as concrete, you’re going to be disappointed. 

While product roadmaps help keep teams on track and communicative, hiccups are inevitable. As these arise, you may need to adjust deadlines, reassign tasks, or make other changes to your roadmap. And that’s ok! Product roadmaps are meant to be flexible—it’s one of their strengths. If your roadmap is cloud-based, the teams involved will receive these edits in real-time, keeping everyone up-to-date and minimizing delays. 

Roadmap maintenance is not a one-person job. As your project progresses, teams should update your diagram with relevant links, files, and notes. This helps centralize information, making things easy to find and access.

Though roadmaps are typically considered a project management tool, they are most effective when built, maintained, and used collaboratively. A project manager doesn’t visualize a roadmap only to use it as a rigid timeline for a project. Roadmaps are created and shared to increase communication across teams. Certain delays are inevitable—a product roadmap helps determine how effectively your teams will respond to those delays.