When does it make sense to make your roadmap publically available, and what do you include (vs your internal roadmap)

I'm a big fan of publicly available roadmaps. They provide current and prospective customers with insight into where you plan to focus and serve as a great resource for Sales and Customer Success teams. Compared to internal roadmaps, the publicly available ones tend to have:

• Less specificity about when a particular feature is shipping (e.g., 'second half of this year' vs. June/July)

• Less detail on how the feature will work or how you plan to measure success

• Fewer technical specifics, focusing more on what problems you're solving or what use cases you're enabling.

Making your roadmap publicly available can be a good idea when:

• Sharing your roadmap publicly can build trust with your customers to show that you value their input and are committed to delivering features that align with their needs.

• You can set clear expectations regarding the features, bugs and enhancements that are in progress or planned.

• It can be an attractive selling point for potential customers.

• Customers can provide feedback, suggest enhancements, and even participate in discussions about upcoming features. This engagement helps create a sense of community and strengthens the relationship between your organization and its users.

Always carefully consider the pros and cons of making your roadmap public.

Since I have joined GitLab, where our product roadmaps are publicly accessible (https://about.gitlab.com/direction/), I don't think I will ever go back to internal roadmaps. A public roadmap as a number of benefits: 

1. You keep everyone internal to the company aligned and up to date on what the product organization is building 

2. You can encourage contribution (if you use open source) from the community or customers to help build your roadmap - delivering on a dual fly wheel mechanism 

3. Reduces external and field team confusion on what the business is delivering. 

If you use disclaimers and set expectations that planning is ambitious and can change, then public roadmaps really have minimal negative consequences. 

Keep in mind, security fixes or issues that contain sensitive data are confidential and have regulatory/meaningful business risks, so these types of planned work should be discussed in general terms without compromising the safety of the company. 

I am a huge fan of public roadmaps! But, I think this is depends on: 

• Organizational cultural preference 
• Mission of the company / product (are you building a product to help companies provide public roadmaps, for instance?)
• What industry you work in 
• If your product is open source or build products for developers
• Whether you serve B2C or B2B - or if your sales motion relies on product led growth

While I my career has been almost exclusively B2B focused, I mostly see public roadmaps in B2B software for open source and developer-focused products. Two examples include:

• GitHub: https://github.com/github/roadmap
• Atlassian: https://www.atlassian.com/roadmap/cloud

This makes sense - developers like accessing information without talking to sales, and trying things out for themselves when they become available to determine if they want to use it. Why not make it as simple as possible for your target audience to adopt your new features? 

Other reasons to have a public roadmap include having a brand that relies on being perceived as transparent, or is directly tied to helping end users access information. If the product builds product roadmaps, for example (like Front Page: https://front.com/blog/why-we-made-our-roadmap-public-and-how-to-build-your-own), it's a great idea to showcase the product in action! 

However...

Highly competitive markets or organizations delivering products for regulated industries may not want to share IP in a public fashion.

B2B sales focused companies with direct sales motions rely on highly personalized customer relationships to deliver information, including setting up roadmap conversations. 

Company culture may operate with more secrecy by choice. A very famous "Fruit Company" relies on the element of surprise for its product announcements and intentionally limits information internally to avoid leaks.

Interesting question! From my experience, there are two key questions to answer when thinking about going public with your roadmap.

1) Do we have a predictable sprint velocity? 2) Do we have a predicate delivery rate? Once you have a predictable sprint velocity and predictable feature delivery, you have a high certainty that when you plan features, they will be delivered on time or close to when you expect. There is some degree of change and reprioritization that happens naturally with a roadmap so I’m not saying dates won’t ever change.

If you go public with your roadmap and keep changing your delivery targets, you will damage customer trust and then have to work hard to rebuild their trust in your execution and roadmap.

In terms of what to include in your public vs internal roadmap, it depends. Here are some ideas. 1) You can put your higher priority items on the public version so you negotiate less with those and reserve the lower priority items for your internal roadmap. 2) You can showcase more of the features that customers have requested on your public version. 3) Add items that are closer to delivery (12-18 months) on your public roadmap and keep the items that are further out on your internal roadmap.

A public roadmap can serve as a tool to attract potential customers and increase the retention of existing customers by demonstrating that you are continually investing in the product and addressing their queries and concerns.

There are Pros and Cons to having a public roadmap, and IMO the Pros needs to significantly outweigh the Cons, as the cost of maintaining this roadmap is not insignificant. Having an out of date roadmap could have an adverse impact so you can't afford to be misaligned in your communications.

Get all the stakeholders (especially customer facing roles) involved, to build this Pros/ Cons list up so you can compare.

Another way to look at this is when not to have a public roadmap. I would not commit to it if: 

• You can't afford to have someone own and maintain the Public roadmap
• There is no commitment from the Customer success and marketing teams to share it regularly with customers
• The sales team doues not have a process to capture the most common queries from prospects that feed into your backlog which in turn will be reflected in to the public roadmap.

This is an interesting question, because I think it highly depends on the leadership and culture of the company you work in. I've seen leadership figures have very strong opinions on how much they want to publicly share about the roadmap, and it's anyone's guess as to whether it's to their benefit or detriment.

Here's how I've thought about this before:

- Your customers benefit from knowing your priorities and what you're building towards. Therefore, being public about mission, vision (to an extent), and the priorities of product is valuable.

- I've been burned countless times by promising specific features in specific timeframes, so I no longer do this until either the feature is shipped, or (better yet), after we've learned about the impact of that feature and how effectively it's helping my users.

- If you work in a SaaS business, especially leaning more toward SMB and enterprise as your main customers, I do think there is value in communicating a rough sense of priorities or goals for the product on some recurring basis (usually quarterly). Given my last point, I think it's important to carefully decide how much you're willing to share - and that's usually based on your confidence in a given item. For instance, if you have something about to ship that you know will solve a major customer problem, that may be worth sharing - but things that have a lot of open questions or risks you may want to withhold specifics on.