Your roadmap is one of the most important things you’ll produce as a SaaS company. It provides a glimpse into the future of your product and aligns everyone around the same goals.

But it can also prompt a lot of questions that need answering, and discussions that have to take place.

How much detail should you go into? Should you commit to specific dates and timeframes? Who will you share the roadmap with: Just employees, or customers too?

And then there’s perhaps the biggest question of all:

“How do we decide what makes it on to our roadmap?”

I wrote this guide to answer all of those questions, and tell you everything you need to know about roadmapping at a SaaS company.

This is based on research we’ve conducted, conversations we’ve had with other SaaS companies, and our own experiences.

I’m going to assume no knowledge on your part whatsoever, so if you feel like I’m stating the obvious at times, feel free to skip ahead to the bits most relevant to you.

The Basics

Put simply, a roadmap is a living document that shows how you plan to develop your product.

The most common form is a graphical roadmap (see below) that essentially forms a timeline of new features and improvements that you’ll roll out in the future.

I call it a living document because it should always be updated with the most recent information. It’s safe to say that in the SaaS world, plans change. They change a lot. And your roadmap should change with them.

The reason a roadmap is so useful is that it provides a clear picture of where you’re heading, much like an actual map.

Much like you wouldn’t attempt to trek through the Amazon without a map, you shouldn’t attempt to navigate through the rainforests of SaaS without consulting your roadmap.

Who Should See the Roadmap?

This is a common question we get asked at Receptive, and the answer isn’t always obvious, and it isn’t always the same for each company.

Our roadmapping feature lets you choose how visible your roadmap is. You can keep it so only your employees see it, make it visible to customers, or simply set it to public and allow anyone to see it.

Each of these options have their pros and cons, and the right one for you depends on your values and stance as a company.

For what it’s worth, we conducted some research into this topic and we found that 33% of SaaS companies we surveyed reported that the whole company used the roadmap.

Only 18% said that customers accessed their roadmap, and even fewer companies (8%) told us that prospects can access their roadmap.

So it seems the vast majority of SaaS companies only allow team members to view the roadmap, even if most employees don’t actually use it.

Having said that, it’s essential that you produce a roadmap for those team members that will use it.

The graph below shows the most common teams that are granted access to the roadmap:

Generally, your Product and Dev teams will use it the most, to keep everyone aligned and aware of what is coming next. However, Sales teams can use it to tell prospects what you have planned, and Leadership can use it to keep track of where their product is headed.

Enabling your internal teams to access and use the roadmap should be the minimum.

You might also want to share your roadmap with customers. This way they can see what you’re working on and get an idea of the great new features they’ll be able to enjoy. It also reassures them that you’re actually developing the product.

The downsides are that you may inadvertently lock yourself into deadlines (see “Should I include time frames?”) or confuse customers if your plans and priorities suddenly change.

If you want to take it even further, and open up your roadmap to anyone, then you can do so. A public roadmap means that your prospects can also see where the product is heading, which may help them to make a decision and potentially impress them.

It does, however, also mean competitors can see what you’re working on, and also carries the same downsides as opening it up to customers.

The approach you choose here really depends on how much you value transparency. If you do open up your roadmap to customers or the public, then it’s important to set expectations and ensure they know that a roadmap isn’t set in stone.

Here’s what one of our customers, Emeric from Agorapulse, has to say on the matter:

“Not having any idea of where a company is heading forces customers out the door, while transparency keeps the right customers in. If a customer is considering leaving, but you have some important features on your roadmap, that may change their mind.”

Another option is to create multiple roadmaps, and have one aimed internally, one for customers, etc. This is a great way to ensuring everyone is covered but that you don’t have to give away information you don’t want to.

Should I Include Time Frames?

This is a major debate among those involved with roadmapping.

A roadmap with no time frames at all is really just a list of features that doesn’t help anyone. A roadmap with excessively detailed time frames, however, can tie you into unwanted and unneeded deadlines.

So, let’s explore the options you have available to you…

You could have no time frames at all. Instead, you would have a list of new features and improvements with a general order in which you’ll aim to release them, but no concrete dates.

The benefit of this is that you aren’t tied in to time frames and can work at your own pace.

The downside is that having no time frames at all doesn’t really tell people much, and sometimes having deadlines (even vague ones) helps you to focus and get stuff done.

Okay, so the opposite end of the spectrum would be to set specific dates for each and every upcoming release. Not only is this practically impossible to plan for, due to constantly changing priorities and resources, but it’s also not that useful.

Knowing the exact date and time is a little superfluous to requirements. Your customer doesn’t care whether that shiny new feature is released on a Monday or Tuesday, they care about rough time frames. Which bring us nicely to what I think is the best approach…

Going somewhere down the middle is often a good rule of thumb, and it’s no different here. Providing rough time frames, such as quarters or even “now/next/later”, provides enough detail to let people know when to expect features but doesn’t mean you’re committing to precise dates.

The best of both worlds.

How Much Detail Should I Include on the Roadmap?

Again, this is always up for debate. There are those who cram their roadmaps full of all the information they have, and there are those who are as succinct and minimal as possible.

So let’s start with the bare minimum, the least amount of information and detail that your roadmap has to have.

The whole point of the roadmap is to show people what you have planned for the product, so it obviously stands to reason that you should at least include the names of any features or improvements.

This can be really simple. For example, if you are planning to release an improved version of commenting in your app, then you could simply put: “Improved Commenting”. Then if someone is wondering when you’re going to improve your commenting, they can see that and know instantly.

The good thing about simplicity is that it makes your roadmap clean and easy to decipher.

The bad thing is that sometimes people require more information.

At the other end of the spectrum, you could pack as much information about new features and improvements as possible. To continue with the above example, you might include detailed notes on what the improvement will entail, aim to sell the benefits of it, and write a small essay.

The good thing about this option is that people can see the items on the roadmap and know exactly what it means. There’s no scope for confusion and misunderstanding.

The bad thing is that people generally don’t want to read that much when they look at a roadmap, and besides, how would you even fit it all on?

At Receptive, we like to keep our roadmap simple. We don’t want to overwhelm people with too much information. We want them to be able to glance at our roadmap and understand what’s coming next.

If somebody hovers over an item on our roadmap, however, then a box pops up containing more information about that particular feature or improvement. This is a clean way of providing extra detail, and is perhaps something you could consider.

Deciding What Goes on the Roadmap

This is the big one. The questions I covered above are important to nail down before you start, but they’re nothing compared to this.

How do you decide what to put on your roadmap?

If I had a dollar for every time somebody asks us that, I wouldn’t be working at Receptive, and I definitely wouldn’t be writing this.

If there’s a definitive answer to this question, then nobody has found it yet. But I think here at Receptive we’ve given it a pretty good go, and I think our answer is more than good enough.

The fact is, plotting your roadmap is a balancing act. You have to balance your product strategy, demand from customers, demand from internal teams, demand from stakeholders, and somehow translate all of that into a roadmap that makes sense.

It’s not easy, but there is a process that will help.

Start by ascertaining your goal (yes, just one) for the next quarter. What is the one thing you want to achieve with your product?

Let’s say, for example, that you’ve decided to improve the UX of your product. Great, there’s your goal.

Now, you need to figure out how you’re going to do that. This is where product feedback comes in to play. Your customers, prospects, employees, and stakeholders will all want different things from a UX. But you can’t put everything on the roadmap. In fact, you really shouldn’t.

Instead, look at the priorities. Which aspects of your UX do people dislike the most? Which areas are easy, quick wins, and which are more complex projects?

Delve into the data and you’ll find the answers. The data will tell you which areas you need to improve, and then it’s just a case of sticking them on the roadmap and getting on with it.

But remember… Your roadmap is a living document, so don’t be scared of updating it and rearranging things if priorities change.

Conclusions

If you’ve read this from start to finish, then you’re probably thinking that it’s a lot to take in. I thought I’d finish with a little to-do list to help you get up and running with your roadmap.

1. Decide what your roadmap will look like:

• Which time frames will you use?
• How much detail will you put on?
• Who will be able to see it?

2. Collect your data:

• Collect feedback from customers, internal teams, and prospects.
• Settle on a product strategy and figure out your goal.
• Segment your data in line with your goal and find your priorities.

3. Build your roadmap:

• Figure out the best order in which to approach the improvements.
• Construct your roadmap.
• Share with the relevant people, making sure to set expectations.

I hope this guide has helped you when it comes to roadmapping your SaaS product.

Thanks for reading!

Receptive helps B2B SaaS businesses to manage their user feedback efficiently, and to make the right product decisions. Find out more…