Roadmunk has their own guide to building roadmaps
Project Roadmaps help teams keep track of a project’s progress and overall catalogue of features. It also helps stakeholders and clients understand the order of feature delivery, including what features are worked on simultaneously.
Roadmaps are generally visualized as Gantt Charts - horizontal charts with features/teams/goals on the Y axis, with time on the X axis. There may be milestones along the timeline that usually signal feature releases or major milestones.
It’s true that Product Roadmaps are usually left to the Product Manager.
However, UX Design is all about taking a larger problem and approaching it from new, informed angles. Product Roadmaps are no different! While you may not be tasked with creating this yourself, it’s important to understand what goes into building one, as the process itself is very UX oriented.
Not only that, but understanding the holistic picture of the project at hand is an important facet of UX Design.
For this walkthrough, we’ll make the assumption that the overall product vision has been established, and simply needs to get documented. But before you can jump right into visualization, we’ll want to think about who you’re tailoring this roadmap for. The level of intricacy will vary depending on the audience.
Internal Roadmap
The most detailed of all roadmaps. Will likely be a complex breakdown of all epics and features, including feature details. Specific teams or team members might be assigned, including various notes on tasks. More jargon will probably be mixed in.
Stakeholder Roadmap
A higher level, top-down visualization of the roadmap. Not every stakeholder needs to understand each blade of grass in the field. Might only include timeline, epics (with perhaps some breakdown of features), and sprint releases.
There are a couple things roadmaps cover:
When building roadmaps, it’s ideal to use a tool that will allow you to make plenty of changes over time. Nearly all products stumble a little through the process, so you’ll need to be able to update the roadmap as you go.
Some popular roadmap tools are Craft.io, Roadmunk, Airtable, Jira, or Trello - but today I’ll be using Aha!. If you want, you can even do everything in a spreadsheet.
The tool isn’t so much the important part as the documentation, ability to update, and ease of access is. Of course, fancier tools will have fancier features, but it’s not a necessity.
Today, I’ll be focused more on the larger components of the roadmap, rather than how to use Aha!.
Now, take a look at this overall roadmap. From here, we’ll zoom into each part to break down the most important facets, so that you can go ahead and create your own.
This is a product roadmap that focuses on the MVP release of a product, and the planning that goes into it.
On the left hand side, you’ve got your major tasks/features that need to be done. On the right, you’ve got your timeline! The bars represent when in the timeline these features are going to happen. The long, gray bar represents the entire length of this portion of the roadmap.
Roadmaps are from start to finish - so you can see that the last row says Implementation Phase 1. That’s because that entire phase will have its OWN set of features/tasks, that pick up on the timeline where MVP phase ends.
This is the true meat of a roadmap - cataloguing every major finish from beginning to end.
Phases are the overarching umbrellas to epics and features. They consist of a larger timeline (say, the first engagement of your project, whether that be months or weeks) and every epic and their respective feature that falls under them during that timeline.
Each phase will tack on to the end of the next (or become intertwined, however you work). The long, gray bars in this image are representative of each entire phase.
With each additional phase, your chart will become long and detailed, including multiple phases under one product umbrella.
Keeping track of everything might become overwhelming, but it’s important to see how everything falls together over time. This kind of data can be beneficial to your team in future engagements, to see what went right and what could use some improvement in your workflow.
Each larger bucket (epics) can be broken down into individual features that fall under the same category. This is where things drill down to the nitty gritty, so you can actually keep track of every feature that gets worked on.
UI Prototyping is the larger bucket (epic), while the three design artifact tasks below it all fit within the timeline. At the end of it all, a milestone called UAT Session is placed, which is the green circle.
The red arrow lines are Dependencies. Depending on what tool you use this may be represented differently, but the gist is that linked items NEED each other to be completed, however that is defined by you. Showing these in the larger roadmap can help track those pesky tasks that are blocked from moving forward by other tasks.
Hopefully, this gets you thinking about how you want to categorize the items within your larger engagement timeline.
Let’s drill down further! For internal roadmaps, there is a lot more to consider than just what the features are. You may also want to document who is assigned, what goals or milestones exist for just that feature, and any linked resources or documents.
Additionally, some tools let you keep track of the status of each feature - whether they’re pending, in development, or potentially blocked. This is why having a living, breathing document is so important.
In the midst of all the features you’ll inevitably have milestone dates for when you’ll release those features out into the wild for testing. We call these Releases, and your chart should absolutely catalogue these dates.
In this tool, releases are represented by Green dots - but you may also see them as flags or other symbols. What’s most important is that they’re set up, so that everyone knows what they need to do by the time it rolls around.
Now, many of the steps above will apply to a Stakeholder roadmap, sans some minor details. Make sure you consult with your stakeholder on just how much they would like to see with the roadmap. There may be times where you need to keep 2 separate roadmaps, due simply to the internal tasks that might want to be kept private.
In this section, instead of the style of roadmap above, I want to offer a more stylized, baked in roadmap you might show to stakeholders in a meeting deck. This kind of roadmap is tailored more towards presentation than active upkeep, because sometimes you just need to represent your timeline in a straightforward, elegant way.
For stakeholders, it’s very likely the information you will share will be whittled down to the bare essentials.
This type of diagram would ideally work in presentation-type scenarios, that want to get the overall gist of the project down.
You’ll notice there are only large milestone dates, and no description of features. That’s what your supplementary documentation comes in, or your internal project roadmap.
To show more phases, you can duplicate this diagram or
Building roadmaps is time consuming, especially keeping them updated - but it’s critical you know how much work has been done, who has done it, and where you are now (and every dependency in between). Your client and team will be thankful, and you can reduce errors and fires that are bound to occur.
What methods do you use to build roadmaps? How do you track your project? Let us know below!
