7 Customer-Facing Roadmap No-Nos

So, you’re thinking of publishing a customer-facing roadmap? OK, that’s a good plan. But, beware – it can go horribly wrong if you don’t do it right. 

Don’t get me wrong, I’m not suggesting you DON’T have a customer-facing roadmap. Far from it! In fact, I’ve already written about the numerous benefits of having a customer-facing roadmap – so you can see, I’m all for them. 

Here at ProdPad, we’ve published our roadmap on our website from day one, for our customers (and anyone else for that matter) to see and give feedback on. And it’s always been great for us. 

Yes, it most definitely is a good idea to have a customer-facing roadmap. You just need to be aware of the risks and how to avoid them.

What could go wrong?

If you don’t do this right, there are a number of risks. You could end up with:

Disappointed customers

We all know the disappointment that comes with unmet expectations. If you put the wrong level of detail on your customer-facing roadmap, or structure it in the wrong way, you could be creating a whole bunch of very specific expectations across your customer base.

After all, if it’s on your customer-facing roadmap, they’re going to expect to see it. If you don’t deliver exactly what you’ve declared when you said you would, disappointment will reign.

Unhappy team

That level of customer disappointment could bum out the team, as instead of positive feedback from customers and nice reviews and comments, you’ll all be getting grumbles and complaints. That’s not going to help your product team feel good about their work. 

That will then lead to an unhappy team, and possibly talent leaving the business. And it won’t just be the product team who aren’t happy. Your customer-facing teams won’t be having a great time either, fielding all these complaints from customers, and having to apologize and placate. Not fun. 

Looking stale and slow-moving 

You don’t need me to tell you that product managers are super busy – spinning a lot of plates. Depending on the tool you use to publish your customer-facing roadmap, you might be left with the overhead of manually updating it.

If that slips down the to-do list and you don’t get to it, you’re going to have a customer-facing roadmap out in the world that hasn’t changed for months. That’s not a good look. 

Competitors pinching your ideas

There’s also a risk that you give away too much detail and pour your secret sauce right into the laps of your competitors. 

Having said that, you shouldn’t let the fear of competitors learning your plans put you off publishing a customer-facing roadmap. This risk is easily mitigated if you follow our simple advice and avoid making these common mistakes. 

That goes for all of the above risks. This is what COULD go wrong, but it’s easy enough to make sure these problems don’t arise. 

Which brings us to our 7 no-nos. 

The 7 common customer-facing roadmap mistakes to avoid

The customer-facing roadmap mistakes you want to avoid are:

1. Don’t include dates

If you’re familiar with our ethos here at ProdPad, and know the teachings of our fine leader Janna Bastow, you’ll know that we are the home of the Now-Next-Later roadmap (our co-founders actually invented it). This is a lean roadmap format structured around broad time horizons, rather than exact dates (as you’d find on a Gantt chart-style timeline roadmap). 

We’ve written extensively on the general pitfalls of having exact dates and deadlines on your product roadmap, but this is particularly true for your customer-facing roadmap. 

If you have actual dates against the things on your roadmap, you’re setting yourself up for a fall. You’ll be left with no flexibility to work on what you’re building for longer (to make it the best it can be), or respond to unforeseen issues, problems, or opportunities.  

Let’s face it, if you are ever asked for a date, it’ll always be based on best guesses and rough estimates. You cannot predict the future and you don’t know what won’t work as you thought it would, or who on the team will be struck down sick, or what hidden problems you might uncover that will take time to figure out. In short, it is very hard to hit a deadline that was based on an estimate way back before you seriously started building. 

So, don’t give your customers dates that you’re going to struggle to meet. Either you won’t make that date and you’ll disappoint them, looking unreliable. Or, you will meet the deadline, but you’ll have shipped something that’s of a poorer quality because of the pressures of the deadline and the fear of annoying your customers. 

Here at ProdPad, our advice is always to follow modern product management best practice and use broad time horizons like now, next, and later, that give everyone a feel for your priorities and timescales, without restricting your ability to learn, adapt, and improve.

2. Don’t talk about specific features or designs

You might have seen some customer-facing roadmaps like this for the products you use – roadmap items that are specific features. You read the details and get a fairly thorough picture of exactly what this feature is, how it’ll work, and what it will do for you. So that’s what you are expecting. You might start to think about how you’d use that feature and plan for its arrival. 

But then, when the feature actually ships and lands in the interface, it works a bit differently and doesn’t look the same. It doesn’t do exactly what they said it would, it doesn’t apply to the areas of the product you expected, and it’s not even available on your price plan. Instead of being impressed by the new feature that is there, you’re annoyed that it’s not what was described and what you were waiting for. 

The moral of this story is simple: Do not describe specific features on your customer-facing roadmap. You don’t need to! It’s enough to tell your customers that you’re going to build something that will solve a particular problem for them, answer a need, or bring a certain benefit. How that is achieved is yet to be seen. But they can be rest assured that their problem will be solved, and that will create happy anticipation rather than exact expectations. 

You then have the space to run proper discovery and explore all the possible ways in which you can solve this customer problem. You have the flexibility to test, learn, and iterate in order to improve what you finally ship at the end. 

3. Don’t give too much detail

You need to consider your audience here. This is your customer-facing roadmap – for your customers. These folks should see a version of your roadmap that is tailored to them. Don’t just have a single roadmap view for all – you’ll end up with a jack of all trades that is a master of no one’s needs and doesn’t serve anyone particularly well. 

I would urge you to think about all the different stakeholders who need to see your roadmap and create a tailored view with the right level of detail for each. In fact, we’ve listed out what each type of stakeholder is interested in, so you can go check that out.  

What is important for your customer-facing roadmap, is to keep it high level. I’ve already said it’s a mistake to talk about specific features, but I’d also suggest you leave out the list of different ideas you’re going to explore for each roadmap initiative. 

You will be clouding the important message if you include the kind of detail that your internal teams need to know. Your customers only really need to understand what problems you are going to solve for them, and the order in which you’re going to tackle them. 

There’s also the risk of giving your competitors too much insight into what you’re doing, if you have a lot of detail on your customer-facing roadmap. As soon as you start attaching designs, including specs or even outlining the feature ideas you’re exploring, you’ll be running the risk of competitors using that intel.

Sure, the chances of them getting ahead of you and building a solution first off the back of what they’ve seen on your roadmap is pretty slim. If something is on your roadmap you’ll likely have a decent head start on the competition. But, if they’re already looking at that same problem to solve then they could well take your learnings and discovery and adapt what they’re doing to be more in line with your solution. 

4. Don’t include internally focused initiatives 

Remember, this customer-facing roadmap should be a version of your roadmap – not the complete and unedited roadmap to rule all roadmaps. 

You don’t need to include every initiative that’s on your internal roadmap, on your customer-facing one. You’ll just be filling up space with stuff they won’t care about. Which might make it less likely that they spot the stuff they will care about. 

Don’t bury what will really excite your customers in a load of stuff that won’t. 

Some examples of internally focused initiatives that shouldn’t go on a customer-facing roadmap:

• Bring down hosting costs
• Improve IT infrastructure
• Attract top developer talent 
• Optimize the signup flow

5. Don’t give your initiatives really commercial-sounding titles  

As well as not including roadmap initiatives that your customers won’t care about, also think about the angle you’re coming from with the title and description of each roadmap item. Think about how your customers will respond to the way you’ve positioned the ‘problem to solve’. 

Let me illustrate this with an example. Let’s say you have a B2B SaaS product that is charged on a per-seat basis. As a business, you are looking to grow revenue (I mean, who isn’t?). You have identified that one way of doing this is to grow the average number of seats per customer account. So you create an initiative on your roadmap and call it something like ‘How can we increase the number of seats each customer has purchased?’.

Imagine you’re a customer reading that on a customer-facing roadmap. There’s no benefit there for you – why should you care about that roadmap initiative? You shouldn’t. That is all about them making money, not you having problems solved. 

But what if that same roadmap initiative was titled something like ‘How can we help customers painlessly onboard their teammates?’ or ‘How can we make it easy for customers to train their teammates to share the workload?’. The goal will still be the same – get more paying users, but the benefit is now positioned to be more about the customer needs and less about your bottom line. 

So, consider those commercial-focused roadmap initiatives. Do you remove them from your customer-facing roadmap altogether, or reposition them to highlight the benefit to the customer over the benefit to your business?

6. Don’t make it hard to find!

The next mistake people make is to put their customer-facing roadmap somewhere relatively inaccessible. Don’t make your customers work to find it! Because they won’t and you’ll have missed the chance of building confidence and trust with your customers. 

Don’t have your customer-facing roadmap as a subtle link deep in a help center article – get it up loud and proud on your website. Otherwise, what’s the point? 

If you’re reluctant to make it fully public for all to see, then at least make sure it’s clearly signposted on your customer portal. 

Your customer-facing roadmap can be a very useful tool for your customer and sales teams. It can help them talk to the future plans for the product and explain how your product will solve their problems. This can be a very powerful resource to help drive retention and grow customer acquisition.

Therefore, make sure these teams can easily point users and prospects to your customer-facing roadmap, and have them navigate back to it whenever they need to.

7. Don’t have a static document

Now, I don’t want to be sensationalist here, or cause anyone too much alarm…. But I have to tell you, that some people create their roadmaps in slide decks 😱. 

I know. I know. 

Or, worst still, spreadsheets 🤢. 

I’ve even seen some PDFs knocking about. 

Having your roadmap in a static document like this is a straight path to versioning headaches, access issues, and extra work. 

You can never be confident that everyone is looking at the most recent version. You always run the risk of the latest version being overwritten. You’ll definitely need to recruit some sort of design help if you stand a chance of making a roadmap look engaging in these formats. Or, even worse, you don’t get design help and have a roadmap that looks like s#*t.   

And king among the disadvantages of keeping a roadmap in a static file is the overhead you will be faced with when it comes to keeping it up-to-date. You’ll have to maintain this customer-facing version of your roadmap, alongside your main roadmap (and indeed any other versions you may have). Every time you update something on your main roadmap, you’ll have to scoot over to the customer-facing file and update that too. Groan. 

As I’ve already said, that’s likely to be forgotten from time to time, or get pushed down your to-do list as more pressing tasks take priority. And then you’re left with a stagnant roadmap out in the world, giving off the impression that you aren’t improving the product or delivering new value. 

Luckily, it doesn’t have to be this way. By building and managing your product roadmap in a tool like ProdPad, you can easily maintain one central roadmap that automatically feeds your published customer-facing roadmap based on the filters you’ve set and the selections you’ve made. 

I wish you the best of luck with your endeavors into customer-facing roadmaps. Once you’re ready to build and publish your public roadmap, be sure to start a free trial of ProdPad and see how easy it is to do it there!