3 Must-Have Roadmaps for Your New Product

When pulling together a roadmap, first ask yourself:

Why do I need a roadmap and what job am I hiring a roadmap to achieve?

Your answer might be “it depends”. This is a totally normal answer for a PM working with a variety of stakeholders at different levels of detail.

The role is so context and audience dependent that you should be changing your approach, tool, and delivery  as you engage with different types of stakeholders with different types of needs.

So, you might first want to ask yourself:

Who is requesting a roadmap and what are they trying to achieve?

Three pretty common stakeholder groups that you may consider as we talk this through are your:

1. Development & design squad: the team building the product with you
2. Ancillary stakeholders: those who have some incentive to be involved in the building or launch of your product
3. Senior leadership: those funding and sponsoring the work

Assuming each of these groups has different goals, we may need a different type of roadmap ready for each of them.

We will walk through three different types of roadmaps you might choose to employ with these stakeholders.

But, before we hop in to the specifics, remember that a Roadmap is just one tool you have in your belt and that it likely won’t be new content; in fact, it’s likely just a reframing of content you already have. Things like: a product vision, a market strategy, your own hunches, assumptions to test, and a stakeholder management plan.

Development & Design Squad

Let’s start with your Development & Design squad: What do they care about and what would a roadmap help them achieve?

In my experience, here are few things a development and design team cares about:

• Building things that matter the customers and the organization
• Doing high quality work
• Knowing what’s coming next so they can adequately prepare

One type of roadmap that I commonly share with these teams is a sprint-level roadmap.

A sprint level roadmap:

• Is a fairly specific low-level roadmap
• Outlines the features, epics, or other objectives you hope to achieve, broken out by sprint timing, which is usually two weeks
• Shows 3-4 sprints at a time, with more specificity included in the sprints that are coming up

In a sprint-level roadmap, you outline the dates of each sprint, assign each sprint a number, and then bullet out the main features or other pieces of work you aim to achieve within each sprint.

Snapshot: Sprint Level Roadmap

This should align with your regular planning methods and backlog grooming activities.

What is useful about this type of roadmap is that it allows your team to see what they’re focusing on in a given time period and allows them to think ahead. This is particularly useful in grooming or planning sessions, when the team can call out different dependencies or considerations based on what’s going to be built next.

Ancillary Stakeholders

In my experience, Ancillary Stakeholders (Marketing, Legal, IT Security, etc) care about:

• Understanding how your work may affect their teams’ work
• Knowing that you have received their feature request
• Knowing when you will be working on their request
• Knowing when they may need to get involved to help out

Many ancillary stakeholders might also benefit from a sprint-level roadmap, especially those who might be working closely with you or have dependencies on the work that you do. You might choose to bring different Ancillary Stakeholders into your regular Sprint Review meetings when their work is closely involved with yours.

There are other stakeholders, however, that are mostly curious to understand general timing expectations of certain features or outputs from your team.

For these stakeholders, I've found it useful to use a Now Next Later Roadmap.

It’s as simple as it sounds. You need three columns:

• Now: include what you’re currently working on
• Next: include what you think you’ll be working on next
• Later: include what you might work on someday

This can be a helpful - and easy - roadmap to always have handy. It helps stakeholders know that you have received their feature request, even if you won’t be working on it soon. It also helps different stakeholders know if they have to get ready to work with you, if their related work is coming up next.

You also might consider adding general timeframes to each of those columns. For example, Now might mean “this sprint”, Next might mean “in the next couple of sprints”, and Later might mean “this year or next year”.

Leadership

Finally, let’s discuss leadership. In my experience,  leadership likely cares about:

• Knowing what you’re working on at a high level
• Seeing how your work ties to the company’s strategic objectives & other work they see
• Understanding proposed timing in relation to planning increments

Of course what these stakeholders care about about will be specific to your organization and their goals.  I recommend that you do your own research here. Meet with your leadership and try to understand what they care about and why. This will help you formulate the most useful communication tools.

For leadership teams, it’s helpful to leverage a Strategic Objective Roadmap:

With this roadmap, you list out the strategic objectives or themes that your company or department leadership has laid out for you. Maybe it’s User Growth or Operational Efficiency.

Then, by quarter (or any other timing horizon your company uses), list out what you see your team working on by objective.

This is a helpful communication tool for leadership to know how team work bubbles up to company objectives. It also might be a helpful tool for you and your direct management to make sure that your backlog represents things that are important to the company. This increases the chance that you work will be successful, visible, and funded again.

Sometimes, teams are worried about writing down features associated with timelines and sharing this with senior management.

This is a very valid concern, especially if you are an early team or working on a nascent product. You may not know what you can build and by when.

In these situations, you might consider veering away from a feature-based roadmap, like these examples demonstrate.

Instead, you could consider experimenting with roadmaps based on:

1. Outcomes
2. Questions

An outcome-based roadmap may include “User can tell the world about our product” instead of writing all of the features that would roll up to a Referral program.

A question-based roadmap may include “How might we make it easy for users to get their friends involved?” instead of a feature or even an outcome listed. This is appropriate if you will be researching your way into your backlog.

Whichever roadmap you choose to employ, remember the following:

1. Roadmaps are just tools. Once you begin to focus too much on the tool, you may be losing sight of your customer and your mission.
2. Roadmaps are meant to be iterative. These are living artifacts that should evolve and change as your learnings, assumptions, and hypotheses do. Set that expectation with your stakeholders and be prepared to update them often.
3. Roadmaps can’t tell the whole story. Consider including other artifacts whenever you share your roadmap with someone. Have a one-pager of the product context and vision prepared.
4. Roadmaps won’t be "correct". You are working in a world of imperfect information with many moving parts. Things will rarely go as planned and there are many “correct” paths you can take.