One of the biggest debates I see internally in product management teams is whether or not they should have a customer-facing roadmap. There are a lot of fears around potentially having one, and I’d like to take a bit of time today to go over them.

Should you take a plunge and share your roadmap externally?

Absolutely! It’s time to dispel some myths and break down barriers.

Let’s dig in, friends.

What is a roadmap, anyway?

Before we get started with the how I want to take a step back and talk about what a roadmap is and what it is not.

Above all, a roadmap is a communication document that outlines your product’s direction, intention, and problems you are interested in solving.

A roadmap is not:

• A to-do list
• A list of features
• A list of promises
• A backlog of items to work on
• A timeline

I’m sure you’re asking yourself, but if I’m not showing what features I’m working on, what’s the point?

The point is to provide a general direction of where the ship is heading, without tying yourself down to a storm.

It’s also important to remember that a roadmap is not the only document you should have handy to provide information to both your team and customers.

You should have a product vision, a roadmap (public and internal), a release plan (internal), and release notes (external). All of these things in conjunction show both the direction you’re headed and your team’s progress.

Building your customer-facing roadmap

Now that we’ve defined a baseline for what a roadmap is, let’s start looking into how to put one together.

1. Defining the audience for your roadmap

The first thing you need to do is define your audience. It is 100% acceptable to have a difference in wording and presentation depending on who it is that you’re presenting your roadmap to.

For your internal teams, you might have details on specific ideas.

For your board members, you might present OKRs or potential goals and results you want to hit.

For your customers, none of these might be relevant, and you might want to focus instead on what outcomes will provide them with value.

2. Presenting your customer-facing roadmap

I like to work with the Now, Next, Later column format. This layout presents a clean blueprint that is easy to navigate, read, and understand.

Here’s how I define each column in my customer-facing roadmap:

Customer-facing roadmap: Now

This is for all the stuff you have committed resources to at this time. This means these things are ongoing and will likely have continuous updates through your release notes.

While I generally stay from writing features on a roadmap, at this point it is actually ok for you to specify what it is you’re doing.

Am I saying it’s ok for you to put features on a roadmap?

Well, no. But also, yes. I know, I know. What I really wanted to say was – it depends.

Putting a feature on a roadmap on the “now” column is ok because *you should know what you are working on*. However, try not to frame the presentation itself as a feature, but rather as an outcome.

Example:

Title: Slack integration

Description: Slack integration to ease syncing messages and threads between our [ACME] app and conversations in Slack.

Without giving too much away, I’ve defined that:

A) I am working on a Slack integration and
B) its purpose is to provide easy syncing between my product and Slack

Customer-facing roadmap: Next

This column represents all of the items that are either in discovery or going into discovery next.

While the “now” column has a very defined description, I like to frame items on this column as a question:

• Can we achieve outcome x, in order to provide benefit y?
• Can we solve problem x, in order to provide benefit y?

Whichever format you prefer, the purpose here is to say we know there is a problem, we know there’s a potential benefit for it, but we still need to do our homework as to what a potential solution(s) might look like.

Taking the previous feature of building Slack integration as an example, instead of focusing on the output (Slack), this is where we take a step back and instead ask:

Title: Better integrations with comms systems

Description: Can we build better integrations with team communication systems in order to provide better syncing of conversations?

At this level, you’re still discovering what the problem might be with more detail and not specifically defining what the output will be with a particular product such as Slack.

For your team, it will give you enough leeway to understand if Slack is even something you should be focusing on, or if there are other opportunities for integrations with other systems. If indeed Slack is the preferred output, then you can prioritize building that integration and potentially following it up with others.

For your customers, it’ll provide guidance that you are focusing on solving a problem, without promising specifics on features or solutions. It also removes bias from an expectation they might have.

Customer-facing roadmap: Later

The last column on the roadmap represents items that are within the set of problems you might want to solve but don’t quite understand or even have the bandwidth to look at them with more depth right now.

In other words – it’s something you know you want to tackle at some point, but are committing to no solutions, outputs, or formal discovery *yet*.

Whereas with the “next” column the question revolves around whether or not you can do something, the question I like to pose here is, how might we be able to solve a problem?

Once again, let’s take this communication app integration item and repurpose its framing:

Title: Support for third-party communication systems

Description: How might we be able to support customers that use third-party communication apps?

For your team, this opens you up to understanding the problem thoroughly. It’ll give you space to run discovery based on the outcome, not discovery based on a pre-defined output (eg, let’s see how we might build a Slack integration vs do we know if Slack is even something people want?).

For your customers, it sets the expectation that while this is something you may look into in the future, you need to set the foundations first.

The final outcome

Taking all of the above, the progression of your roadmap will look like this:

*Solution* <- *Can we do this, in order to x?* <- *How might we solve this problem we know nothing about yet?*

For the intended audience, this provides a progression of the thought process. It shows what product thinking looks like, it shows that you’re moving towards a potential outcome, and with all the other items in your roadmap, it provides context.

Context is incredibly important for the conversations your business-facing teams will have with customers. It’s very difficult to answer yes or no to a question about a feature without a direction of where your team is going.

With a Now, Next, Later customer-facing roadmap that shows progression in your team’s product thinking process, you’re able to facilitate those conversations further.

Once again, remember that this is not the only document your team should have at hand!

Make sure your team is armed with a roadmap as well as your product vision and release updates. This will create trust with your customers that you’re not just pretending like you’re asking questions, but you’re coming up with real solutions and showing progress.

Additional information for your customer roadmap

I’ve given you the basics for how to frame your roadmap, but wait… there’s more!

There are other things you can and should include on your customer-facing roadmap in order to truly make it useful.

Product area

If you’re managing a larger portfolio or a complex product, you might want to highlight product areas.

This can be done by either creating a portfolio roadmap (a rolled-up set of roadmaps to a single high-level view), or you can highlight these areas with tags.

Objectives and goals

You might think that customers aren’t interested in your objectives and goals as a business. And while that may be true in some cases, I still recommend including them.

Building trust with customers is part of the relationship you want to develop with them.

Be transparent about what your goals are and how you aim to get there, both through the outcomes and value you want to provide them with, as well as the business impact this will have in the future – both for you and for them!

Notion publishes a Founder’s notes for transparency.

Completed and potential problems

There are two other columns I haven’t spoken about: your completed column, and your potential problems to solve column.

These two sit on either side of the core roadmap, which means you’d be displaying:

Completed, Now, Next, Later, Potential Problems

Breaking this down further, each column represents the following:

• Completed: What you have achieved
• Now: What you are working on (supported by your release notes)
• Next: What you’re looking to understand further
• Later: What you might look at in the future
• Problems to solve: Things that you might be interested in, but haven’t made it to the roadmap just yet

Conclusion

With the full context that a customer-facing roadmap provides, your customers have a full blueprint of the general direction you’re moving towards.

You are moving beyond a solution/timeline roadmap that pigeon-holes you and them into thinking something will be done (when we all know it might not), to providing full, transparent visibility over the things that are tangible, in discovery, and still in question mode.

When this is set in motion, all you need to worry about is how are you going to keep users updated on all the new releases. Userpilot can help with that with contextual in-app communication. Get a demo to see how!