{"id":81112,"date":"2023-09-28T16:30:02","date_gmt":"2023-09-28T15:30:02","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=81112"},"modified":"2025-01-13T16:25:03","modified_gmt":"2025-01-13T16:25:03","slug":"customer-facing-roadmap-no-nos","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/customer-facing-roadmap-no-nos\/","title":{"rendered":"7 Customer-Facing Roadmap No-Nos"},"content":{"rendered":"\n

So, you\u2019re thinking of publishing a customer-facing roadmap? OK, that\u2019s a good plan. But, beware – it can go horribly wrong if you don\u2019t do it right.\u00a0

Don\u2019t get me wrong, I\u2019m not suggesting you DON\u2019T have a customer-facing roadmap. Far from it! In fact, I\u2019ve already written about the numerous benefits of having a customer-facing roadmap<\/a> – so you can see, I\u2019m all for them.\u00a0

Here at ProdPad, we\u2019ve published our roadmap<\/a> on our website from day one, for our customers (and anyone else for that matter) to see and give feedback on. And it\u2019s always been great for us.\u00a0

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.<\/p>\n\n\n\n

\"Free<\/a><\/figure>\n\n\n\n

What could go wrong?<\/h2>\n\n\n\n

If you don\u2019t do this right, there are a number of risks. You could end up with:<\/p>\n\n\n\n

Disappointed customers<\/h3>\n\n\n\n

We all know the disappointment that comes with unmet expectations<\/a>. 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\u2019t deliver exactly what you\u2019ve declared when you said you would, disappointment will reign. <\/p>\n\n\n\n

Unhappy team<\/h3>\n\n\n\n

That level of customer disappointment could bum out the team, as instead of positive feedback from customers and nice reviews and comments, you\u2019ll all be getting grumbles and complaints. That\u2019s 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\u2019t just be the product team who aren\u2019t happy. Your customer-facing teams won\u2019t be having a great time either, fielding all these complaints from customers, and having to apologize and placate. Not fun. <\/p>\n\n\n\n

Looking stale and slow-moving <\/strong><\/h3>\n\n\n\n

You don\u2019t 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\u2019t get to it, you\u2019re going to have a customer-facing roadmap out in the world that hasn\u2019t changed for months. That\u2019s not a good look. <\/p>\n\n\n\n

Competitors pinching your ideas<\/h3>\n\n\n\n

There\u2019s 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\u2019t 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\u2019s easy enough to make sure these problems don\u2019t arise. 

Which brings us to our 7 no-nos. <\/p>\n\n\n\n

The 7 common customer-facing roadmap mistakes to avoid<\/h2>\n\n\n\n

The customer-facing roadmap mistakes you want to avoid are:<\/p>\n\n\n\n

1. Don\u2019t include dates<\/h3>\n\n\n\n

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

We\u2019ve written extensively on the general pitfalls of having exact dates and deadlines on your product roadmap<\/a>, but this is particularly true for your customer-facing roadmap.\u00a0

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

Let\u2019s face it, if you are ever asked for a date, it\u2019ll always be based on best guesses and rough estimates. You cannot predict the future and you don\u2019t know what won\u2019t 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.\u00a0

So, don\u2019t give your customers dates that you\u2019re going to struggle to meet. Either you won\u2019t make that date and you\u2019ll disappoint them, looking unreliable. Or, you will meet the deadline, but you\u2019ll have shipped something that\u2019s of a poorer quality because of the pressures of the deadline and the fear of annoying your customers.\u00a0

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.<\/p>\n\n\n\n

2. Don\u2019t talk about specific features or designs<\/h3>\n\n\n\n

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\u2019ll work, and what it will do for you. So that\u2019s what you are expecting. You might start to think about how you\u2019d use that feature and plan for its arrival.\u00a0

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

The moral of this story is simple: Do not describe specific features on your customer-facing roadmap. You don\u2019t need to! It\u2019s enough to tell your customers that you\u2019re 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.\u00a0

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.\u00a0<\/p>\n\n\n\n

3. Don\u2019t give too much detail<\/h3>\n\n\n\n

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\u2019t just have a single roadmap view for all – you\u2019ll end up with a jack of all trades that is a master of no one’s needs and doesn\u2019t serve anyone particularly well.\u00a0

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\u2019ve listed out what each type of stakeholder is interested in<\/a>, so you can go check that out.\u00a0\u00a0

What is important for your customer-facing roadmap, is to keep it high level. I\u2019ve already said it\u2019s a mistake to talk about specific features, but I\u2019d also suggest you leave out the list of different ideas you\u2019re going to explore for each roadmap initiative.\u00a0

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\u2019re going to tackle them.\u00a0

There\u2019s also the risk of giving your competitors too much insight into what you\u2019re 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\u2019re exploring, you\u2019ll 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\u2019ve seen on your roadmap is pretty slim. If something is on your roadmap you\u2019ll likely have a decent head start on the competition. But, if they\u2019re already looking at that same problem to solve then they could well take your learnings and discovery and adapt what they\u2019re doing to be more in line with your solution.\u00a0<\/p>\n\n\n\n

4. Don\u2019t include internally focused initiatives\u00a0<\/h3>\n\n\n\n

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

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

Don\u2019t bury what will really excite your customers in a load of stuff that won\u2019t.\u00a0

Some examples of internally focused initiatives that shouldn\u2019t go on a customer-facing roadmap:<\/p>\n\n\n\n