In my experience, public sharing of roadmaps usually hurts more than it helps. Here’s a few reasons why:

• When (not if!) you change the roadmap it will annoy customers. Humans are more upset by unexpected losses than unexpected gains. Even if the feature list and priorities stay constant (which they won’t — see below), the dates inevitably change because it’s hard to perfectly predict timing. So instead of customers being happy with great new functionality, they’re annoyed that you’re late or because you cancelled a feature they wanted.
• Journalism. Nothing is an easier story for a tech journalist to write than “Company X slips product Y by 12 months”. The story almost writes itself. Just add quotes from customers who are annoyed (see above) and hit publish. And then when you finally launch, the headlines go like this: “Long-Delayed Product Y Finally Ships”. The press has a way of turning good things (transparency, agility) into bad (delays, broken promises). Don’t make it easy for them.
• Limits your flexibility to tweak roadmap to maximize revenue. We often tweak the roadmap in response to market conditions (e.g. beat a competitor to market), internal constraints (e.g. important employee quits), or tactical sales concerns (e.g. accelerating a feature to close a big deal; preventing churn by throwing a bone to a customer). Having a public roadmap makes these changes harder. (see above)
• Sometimes you cancel features or proposed products. It’s very common that, as you learn more about a feature it will cost more or have less value for customers than you expected when you first put it on the roadmap. Having the flexibility to silently cancel a planned feature is very helpful. Nothing sucks worse than having to ship a feature for one customer you promised it to when you already know that your other customers won’t use it or if it costs 3x what you expected.
• Your competitors will use it against you. Your competition will study your roadmap. They will have months of head-start in marketing messaging, sales tactics, etc. so that when you finally ship the features the competition has been trashing them among your prospective customers. Also, they’ll tweak their own (private) roadmap to try to beat you to market, to beef up areas of the product where you’re challenging, and to hone in on customer segments that your roadmap is neglecting.

None of these concerns mean that you can’t share your roadmap with trusted, friendly customers who understand that roadmaps change and who can help you adjust priorities and refine your roadmap.

But a better approach that works better, even with trusted customers, is to share a coarse-grained prioritized product backlog and ask your customer for feedback about the features and priorities. I often say something like “Here’s a list of features that our team is considering building.” and then I ask for feedback: “Are these the right features for your business?” “Are there things we should be working on sooner vs. later?” “What’s missing from this list that matters a lot for your business?” “Are there things on here that you think aren’t helpful for you?”

This backlog/feedback approach has a lot of the benefits of roadmap sharing without most of the downsides because you’re not actually committing to specific features nor dates.

Of course there are always exceptions. You can use a public roadmap to scare a competitor away from a space or to mislead competitors into a false sense of security. You can publicize a roadmap to generate buzz or to generate sales interest. And so on. But these are exceptions, not the rule.