Creating roadmaps that rally teams around product work
A roadmap is a shared, dynamic tool that brings teams together around the current — and ever-changing — path ahead for your product.
The roadmap communicates priorities and how they were chosen to different groups, from leadership to customer-facing teams. Each of these groups will have its own unique view of the product roadmap, making upcoming work concrete and easy to visualize.
Priorities are always evolving — that’s why the roadmap is a living, constantly updated document. But even as plans change, it acts as a single source of truth for the product journey, sharing the current vision for which ideas will be put into action and when.
How to create a roadmap?
There isn’t a single right way to make a roadmap. One of the many challenges around roadmapping is that it’s a catch-all term, and can represent many different tasks across collaboration, communication, deciding on priorities, communicating these priorities, setting expectations, and so on.
Roadmapping involves many people inside your team and company, and sometimes external parties, like customers and partners. You’ll likely need a different format and approach, depending on who is involved.
However, there are still roadmapping best practices to rely on. In this section, we’ll share roadmapping techniques and strategies we’ve seen work, and ones that tend to fall short.
Ingredients for a good roadmap
We’ve seen many roadmaps since we started working on Jira Product Discovery.
The successful ones have a few attributes in common:
- They’re kept up-to-date: This is non-negotiable, because other people depend on the roadmap to guide their own work and make important decisions.
- They use terms everyone understands: All fields and values, like “business impact” or “risk level”, should have a clear definition. This keeps conversations focused and productive.
- They show the big picture: Effective roadmaps explain the “why” behind the priorities they share. They focus on the big picture, not the tasks and details of its execution.
- They are outcome and goal-based: By showing the end goal, successful roadmaps steer the conversation towards the big picture, not “when is X going to ship?”
- They set realistic expectations: Instead of over-promising, roadmaps are honest about the level of commitment to each idea.
- They are succinct: They fit on one page.
How to tell if a roadmap is working
When a roadmap is working, it becomes a self-serve, single source of truth for your future product plans.
- People don’t need to directly ask you what’s coming up and when, because the roadmap acts as a self-serve source of information
- Team members independently share fresh insights and ideas through dedicated channels
- Stakeholders stop requesting ad-hoc presentations to get visibility, instead referring to their dedicated roadmap view
You don’t need to spend time rehashing and repeating your priorities, because everyone can go directly to the roadmap to answer their questions.
Conversations become more strategic and productive. Your product team gains autonomy, and wins time back to focus on what you were hired for: making an impact!
How are Roadmaps different from Plans?
A roadmap in Jira Product Discovery, connected to Plans in Jira.
Roadmaps are created in the product backlog. They communicate how and why each idea was prioritized. They’re easily shared with customers, partners, and everyone within your company.
→ Roadmaps live in Jira Product Discovery.
Then, plan the execution of these ideas in Jira.
In Jira Plans, ideas appear as fields within an Epic or Initiative. Break each idea down into User Stories, Tasks, and Subtasks, and map out how everything fits together, taking into account dependencies, constraints, and estimations.
→ Delivery Plans live in Jira.
Idea field in Jira Plans.
Timing and dependencies in Jira Plans.
Dependencies in Jira Plans.
How Jira Product Discovery and Plans in Jira work together
Here's are a couple of Looms describing how Jira Product Discovery and Jira Plans work together:
Different roadmaps for different stakeholder groups
Every stakeholder group, from leadership to customers, will have different questions and concerns. To communicate with them effectively, product teams need multiple roadmaps.
Jira Product Discovery makes this easy. You can create many versions of your roadmap without starting from scratch each time, or updating all of them whenever you make a change.
Set custom views that slice and dice the data so it’s relevant to each of your stakeholder groups. The views will update dynamically, so when you change one idea, it’s automatically reflected in every version of the roadmap.
If you want to save yourself from constantly being asked “when X is going to ship?”, you’ll also need to make roadmaps self-service. Everyone should have a link to their own roadmap, that shares the information they need in an easily accessible way.
There are two ways to share roadmaps in Jira Product Discovery:
Invite internal stakeholders as contributors to the project. They will need a Jira account, but don’t need a paid licence if they only have access in the ‘Contributor’ role.
Publish a view and share it with anyone, like internal stakeholders, partners, customers, and end users. This view is read-only, easily shared inside and outside the company with a single link.
As you design views for each group, try to address questions you know will be important to them upfront. Depending on the audience, you might want to emphasize:
- The prioritization framework used, like insights, RICE score, impact vs. effort
- How you balanced investments across areas
- The level of commitment and certainty for each idea
- Information about the item’s status (on track, off track, at risk)
- Level of effort and indication of capacity
- A general idea of sequencing (without specific dates)
Roadmaps for leadership
Leadership and product teams typically have different core concerns, and look at situations with a different level of detail.
A different roadmap at different altitudes in the product team.
Leadership-level conversations typically center goals, areas of investment, and the capacity allocated to each idea based on available resources and strategic objectives.
Leadership roadmaps should also communicate your level of certainty. For example, if you’re going to try a radical idea and aren’t sure about the result, that roadmap item should be immediately distinguishable from a safe bet.
The roadmap you share with leadership should make all this information clear.
But my stakeholders just want to know when a feature will ship!
If you promise exact dates that features will ship, you are doomed to fail. Software engineering isn’t a predictable process. If you focus the roadmapping conversation on certain dates, you risk setting unreasonable expectations, missing those promised dates, and losing the trust of your leadership team.
This damage is hard to repair, and in the end, arbitrary dates don’t even matter all that much. What matters is the impact of your work, and how it supports your company’s success.
Instead of getting in the weeds about execution details, elevate leadership conversations to the big picture.
Explore questions like:
- Do you believe we are making the right bets?
- Based on what you know about the company goals, should we invest in other areas?
- Do these plans seem realistic based on our available resources and constraints?
Every time you create a new roadmap, it’s an opportunity to reset expectations and frame discussions in a way that makes them productive for everyone involved.
Every stakeholder group has different priorities. A good roadmap frames the conversation around what’s important for your stakeholders: what are their goals? What outcomes are they trying to accomplish?
Then, you can steer discussions towards where and how your team can help realize them.
Jira Product Discovery’s leadership roadmap
When we were creating Jira Product Discovery, here’s the roadmap we shared with the Atlassian leadership team in mid-2024.
Jira Product Discovery’s leadership roadmap.
One item on Jira Product Discovery’s leadership roadmap.
This roadmap highlights a few key concerns:
- Time horizon: We only make hard commitments in the next 6 months
- Expected impact: Our big bets and the reasoning behind why they were chosen
- Level of investment: How many resources teams will devote to each idea
Importantly, you’ll notice there’s no mention of dates for any of the ideas on this roadmap.
Roadmaps for product teams and squads
Product team roadmaps should make it clear what you’re saying “yes” and “no” to, and provide clarity on sequencing. Keep things high level, showing which problems the product team is working on and how they translate into features.
The purpose of this view is not to guide the team's daily work — that happens in Jira — but to keep them clear about their mission, and effective in solving specific problems.
Jira Product Discovery’s product team roadmap
This is the roadmap shared by one squad working on Jira Product Discovery:
A squad roadmap in Jira Product Discovery.
One item in a Jira Product Discovery squad roadmap.
As you can see, we use a roadmap with two levels at Jira Product Discovery. One roadmap, for the whole product, is shared with leadership. Then, a secondary roadmap shows what’s in scope for each squad.
Here are two videos showing how to create this two-level roadmap in Jira Product Discovery:
Creating a roadmap with 2 levels - Part 1.
Creating a roadmap with 2 levels - Part 2.
Roadmaps for customer facing teams
Customer facing teams need a roadmap that makes it immediately clear what they can share with customers. That means communicating:
- Which ideas are committed to
- What features and ideas are coming when
- Your level of certainty about meeting those commitments
You must spell out your commitments, alongside their level of certainty. Otherwise, customers might anticipate dates and deadlines that aren’t met, or be promised features that never eventually ship.
Jira Product Discovery roadmap for customer-facing teams.
Roadmaps for customers and end users
A public roadmap can improve customer trust, and strengthen relationships, by sharing your product's future plans and encouraging useful feedback.
Enterprise customers, in particular, expect this — when they buy your product, they know they’re embarking on a long term journey and need to know where it’s headed.
However, this openness has a downside: it exposes the product team to increased scrutiny and pressure. When the roadmap changes, customers might feel let down, seeing the changes as broken promises rather than shifting priorities or unforeseeable issues.
This can erode trust in the product and its development team. So, be sure to weigh the pros and cons for your scenario.
There are a few ways you can use Jira Product Discovery to share a roadmap with your customers and end users:
- Create a view that’s shared securely with a specific list of people, instead of making it fully public.
- Create a truly public roadmap view that you publish online where anyone can access it.
- Use a different tool to publish your roadmap, but keep track of publicly made commitments in your product backlog. This way, you know which initiatives were committed to when reworking priorities.
Atlassian Cloud’s public roadmap
At Atlassian, we publish have a highly curated public roadmap for our Cloud products:
Atlassian Cloud Public Roadmap (May 2024).
The Atlassian Cloud Security team contributes heavily to this roadmap. In their Jira Product Discovery project, they use a specific view to keep track of which commitments were made public.
Roadmap formats to consider
Rigidly linear roadmaps are misleading. The further you look into the future, the less certain your commitments are. Effective roadmaps should reflect that.
Instead, aim to make your roadmap both honest and strategic.
Misleading, honest, and strategic roadmaps. Source: @spavel.bsky.social🐀 on Twitter / X
You’ll design your own best roadmap format, using data to tell the story of what your team is iterating on and working towards.
But, there are a few go-to roadmap formats to take inspiration from. Here are a few that we often see working for Atlassian customers.
Outcome-based roadmap
Great roadmaps make clear which outcomes the product team is trying to achieve, and tell the story of how it’s trying to get there.
An example would be the Jira Product Discovery leadership roadmap, which spells out how we’re thinking about investments, across all squads, for the entire product.
While this format has worked well for us, there’s no single formula to getting it right. Experiment, see how the roadmap guides your conversations, and find what works for you.
Jira Product Discovery’s outcome-based leadership roadmap.
Now/Next/Later roadmap
Now/Next/Later roadmaps are an effective way to align everyone on what bets the team is making, the level of certainty around each initiative, and give an idea of sequencing.
This roadmap style has become very popular among product teams, because it focuses the conversation on outcomes, uncertainty and capacity. But unlike other common formats, like Gantt charts, Now/Next/Later roadmaps don’t get bogged down in delivery details and dates.
The Jira Product Discovery team uses this format for each squad-specific roadmap:
Jira Product Discovery’s Now/Next/Later squad roadmap.
A common pitfall with Now/Next/Later roadmaps is reading them as “we’ll do this first, that next, and this later.” This implies every item is a commitment that will eventually be shipped, which is an oversimplification.
Instead, think of it this way:
- Now: Validated opportunities, with the team actively validating solutions or implementing ones that have been validated already. Ideas at the Explore, Make, or Impact stages.
- These ideas may be shipped, pushed back to the “Next” column if a solution can’t be validated, or abandoned entirely based on learnings.
- Next: Validated opportunities for which the team has a good understanding of potential solutions. Ideas at the Explore stage.
- These ideas may move forward to the “Next” column, get pushed back to “Later” in favor of more promising solutions, or removed entirely based on learnings.
- Later: Validated opportunities for which the team is still assessing potential solutions. Ideas at the Wonder or Explore stages.
- These ideas may jump forward to “Now” or “Next,” remain in “Later,” or be removed from the roadmap based on learnings.
Time-based roadmap
Gantt charts are a big no-no for product roadmaps. They focus the conversation on the wrong things — outputs, or the dreaded “when is X going to ship,” instead of outcomes, or “why are we working on X in the first place?”
But that doesn’t mean you should disregard time-based roadmaps entirely. They can still be useful when other teams depend on your work, or when sharing information with marketing and customer-facing teams. You just need to ensure that everyone accessing the roadmap understands your level of confidence and commitment in each idea.
We don’t use time-based roadmaps on the Jira Product Discovery team, because we find that conversations around dates are the least productive ones to help product decisions. But if we did, they would look like this:
Example of a time-based roadmap.
Be careful when designing a time-based roadmap. It’s easy to project a sense of certainty far into the future, and set unreasonable expectations.
The following roadmap is most likely misleading, because it makes it seem as if the team has a clear idea of what will happen six months to a year into the future:
If your stakeholders demand a time-based roadmap, we recommend combining a Now/Next/Later roadmap with a timeline to tell a more honest story:
- The Now/Next/Later roadmap makes it clear what your team has enough certainty on to commit to
- Plot only ideas in the “Now” column on a timeline, to give a rough idea of which month or quarter they’ll land
- Ideas in the “Next” and “Now” columns are situated within your general plans, without making commitments that you cannot meet
Timeline view within a Now/Next/Later roadmap.
Avoid making your timeline view too granular. Focus on the important ideas, not specific dates and tasks. The goal is to give your stakeholders a high level overview of where you’re headed, not show them the details of day-to-day work.
Timeline views and dates in Jira Product Discovery
Here’s a demo for two ways to create roadmaps with different time horizons. The second view is our favorite.
The problem with setting dates is that they can easily change based on what you learn in delivery. In this view, you can configure the idea’s date fields to be automatically overridden by the epic/initiative’s date fields once the idea has corresponding delivery tickets.
This way, any changes that happen on an epic during work, will be immediately reflected back on the roadmap:
Dynamic timeline view within a roadmap in Jira Product Discovery .
One date field configured to get the date from the Jira epic in Jira Product Discovery.
Product initiative dashboard
This product-wide roadmap format offers a bird’s eye view of all product initiatives planned or in-flight. It is particularly useful when collaborating with engineering leadership.
It’s a good idea to always keep this roadmap in your product backlog. While discovery and delivery work are connected, some things are clearly in the realm of discovery (assessing potential solutions), some in the realm of delivery (running sprints), and others bridge the two (deciding how to prioritize technical debt vs. new features).
This roadmap format is a good way to visualize investment across these categories, as you prioritize your product backlog.
