When does it make sense to make your roadmap publically available, and what do you include (vs 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.

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. 

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.

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.

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.

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.

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.

I might have given you a very different answer to this question a year ago! I used to be paranoid about hiding my roadmap from my competitors, and would share broadly internally and with customers to maximize feedback, yet lock it down for everyone else.

GitLab is the most transparent company I've ever worked for, and for the most part our roadmap is on our public website available to anyone. I can't tell you how liberating it is to be talking to a customer who has an obscure question about an area of the product I don't know and to say "I don't know, let's find out" and proceed to pull up a public roadmap page in an unauthenticated session with them in real time.

So I guess I would err on the side of transparency these days, with obvious exceptions for the things that truly do need to remain confidential. I guess you CAN teach an old dog new tricks.

There are three high-level options: 

• Internal roadmap only

• Fully public: roadmap published externally for all customers and prospects 

• Customer-facing roadmap that your Sales, Customer success, Sales Engineering and field teams are trained on to share  
  

The choice of roadmap depends on your product category, type of customers you serve, and organization structure. For instance, developer-facing products typically prefer public roadmaps, while B2B has a stronger preference than B2C for external roadmaps. If you have customers doing long-term commitments 2-3+ years, they would typically want to see the product strategy and roadmap over that period of time.

If you choose to create an external roadmap, focus on: 

• Content creation and 

• Commitment to keeping your roadmap up to date
  

Curation can be done with high-level descriptions such as customer problem solved and feature summary vs. specifics on the implementation, quarter or halves of the year vs. specific dates. You can also provide personalized talk-track and messaging for your field teams to highlight different aspects of your roadmap based on the audience. Lastly, create rigor within your organization to keep the roadmap updated periodically.

Some companies do a great job in providing a public-facing roadmap. At one company I worked at, there used to be a Trello board where customers could add features, upvote, and see what was coming up. It was completely transparent. On the other hand I've worked at companies where we didn't publicly list anything. There are good reasons to do both.

At smaller companies being transparent can help build community, engagement, and enthusiasm for your product. You are also at low risk of having bad publicity if dates slip. You should strive to include details of the features, mockups, pricing, and anything else that might be relevant.

At larger companies, you'll need to work with your marketing, legal, and sales partners to coordinate what is published. For example, you don't want to list that something is being worked on when sales has communicated a different feature is the priority. It's also important to provide disclaimers so that customers don't use any dates/targets as a means to renegotiate their contract when something slips. Finally, you'll want to make sure that you aren't sharing too many details about a feature until they are confirmed. If there are companies relying on your product for their business then accuracy is critical.

My general rule is that you should only share projects with customers that you're at least 80% confident you're going to deliver in the timeframe you indicate. This could be even higher in an B2B SaaS company where customers might buy your product based on that roadmap.

I'd therefore be very conservative on what you share publicly. You can share goals or strategies which are higher level that don't promise particular features but indicate the direction that you're going in. I find that usually delivers the impact you're looking for, getting your customers to buy into the vision, without holding you to a set of features you might learn are not the right ones to achieve that vision

There are a few gradations of what public means in practice – i.e. 100% open (e.g. with rankings), partially open (narrative, but not prioritized), public to customers. I think it's always important to have a version that you can easily share with customers on demand, and most companies will want a partially open version unless they're in a hyper-competitive space, or stealth mode. For 100% open roadmaps, I think it depends on the stage of your product, how you acquire customers, and how competitive your space is. In early stage, PLG, not-very-competitive spaces, this can be super helpful to drive engagement. In more competitive spaces, this risks eroding your competitive advantage, obviously, and for SLG motions, it's probably more important to put energy into your customer-facing roadmap than an open one. An open roadmap will become another channel and set of feedback you need to manage, and that audience might not always align with the customers you're trying to acquire.

I think public roadmaps make sense once you are post product market fit but it's important to remember to only lookout 6 months or so (with safe harbor for future usage/ purchasing statements).

Once you are post GTM fit, then it makes sense to go further out to 12 months and provide dates for 6 month launches.

I typically suggest including major product changes that the team is fairly (> 90%) confident on delivering along with separate comms on other smaller changes that might be relevant for certain subset of customers.

Personally, I believe in having a very transparent roadmap. Not all companies are going to be able to communicate everything that is on their roadmap for legal and/or regulatory reasons, but, in my opinion, you should try to have as much of it public as possible. The main difference between an internal and external roadmap is that I would advise to never put exact dates on an external roadmap. If you have to put dates down, general timelines of this quarter, next quarter, this year, etc. are good enough to communicate what you are working on now, what you will be working on next, and where you'd like to go in then future. Also, always make sure to include a statement that things will change. Timelines, priorities, known vulnerabilities, and regulations can all change and impact your roadmap. Make sure that your customers know that you reserve the right to change things. Above all, be transparent when things change. Don't lead customers on if you know that the timeline has drifted and you won't be delivering the feature they want until next year.

On your external roadmap, I think that it is prudent to include the following information:

1. What the feature is and isn't.

   • Be clear about what it will do when it is released.

   • State what problems the feature will address and how it will help your customers.

2. If necessary, general timelines of when you expect features to ship.

3. Dependencies on other work, especially if it is dependent on other teams.

4. If possible, for the features you are currently working on, include designs or wireframes to show what it will look like and how it will be used.

5. Forward looking statements acknowledging that things can change.

   • Be clear that nothing in your roadmap is a commitment, whether it is the timeline, functionality, or specific design.

On an internal roadmap, I'd expect to see more details.

1. Work with engineering to determine an estimated timeline and work towards shipping the feature within that timeline.

2. Define engineering dependencies and capacity.

   • Externally, your customers don't care about who is working on the feature, but internally, you should be clear about who is critical path to releasing a feature, in case anything comes up that affects the capacity of those people.

3. Communicate the details when things change.

   • What caused the change? Technical dependencies? Bugs? Security issues? Marketing timelines? UX research?

4. Show how this feature contributes to the company's vision and goals.

Of course, when you publish a public roadmap, you are going to have pushback. You are never going to have a roadmap that makes all of your customers happy. Different customers need different things. You should embrace the fact that you will get negative feedback from specific customers when you haven't prioritized what they want. Hear them out, value their input, explain why you are prioritizing the features on the roadmap, and use their input to make future decisions. Maybe there's something that you hadn't understood when prioritizing your roadmap and their input is what you needed to unlock the realization that their issue has broader impact than you had originally thought. The more people you have providing input, the more data you have. The more data you have, the better decisions you can make.

I answered this partly in the earlier question “We’re pivoting our product, and it’s difficult to plan the roadmap too far out. How do we reset expectations on what product communicates?”

TLDR is “it really depends on your company values/priorities and your product and community.”

• There are risks to sharing too much detail too early (failed follow-through can erode user community support and/or business partner/channel support).

• I personally like to optimize for customers, not competitive intelligence, because if you have happy customers, you have a successful business.

• In terms of what to include, you can talk about your product team’s priorities, key problems you’ve identified and are working on, and even hard tradeoffs you’re thinking through with certain customer communities or research groups/advisory councils. But pre-announcing delivery of features by specific dates is probably too much detail and too high a likelihood of backfiring.

I am a BIG proponent of having a version of the roadmap that can be shared externally!

There are some tactical things you may need to do to ensure you can share and to make sure it is effective. These are my experience and yours will depend on your specific scenario including company size and industry, product, customer type, geography, etc.

1. Confirm with internal stakeholders like legal and your product leadership that you can share a roadmap externally and if it is only for customers or for prospects and if they need to have an NDA or some other agreement in place.

2. Prepare sales enablement training. One of the main benefits of having a roadmap artifact that can be shared is that it means product managers do not have to share the roadmap in person with every external party that wants to get the information. This only works if you prepare your field team on how to talk about the contents and keep them up to date when it changes. In the beginning it will often feel like more work than presenting it yourself but it will pay off.

3. Make the roadmap! My preferred format is a "Now, Next, Later" in which "Now" are big rock projects that we can share some early designs and the specific use cases being built for the first version from. Next contains the solutions we are validating, talking about the use cases we are validating or have validated in research. Later would be the high level strategic areas we want to explore. Each of these may represent a month, a quarter or a year, that timescale depends on your product and org. For a SaaS B2B company I like to keep it at Quarters for Now and Next and a year for the "Later".

This goes back to the earlier question about different formats for different stakeholders. With the use case of a public road map you have to remember not only the audience but who is presenting it, or not, so the right context is shared in the content. Good luck!

Making a roadmap publicly available can build transparency and trust with customers, stakeholders, and partners. However, it's essential to carefully decide when and what to share. Here’s when it makes sense and how to differentiate a public roadmap from an internal one:

When to Make a Roadmap Public

1. Customer-Centric Industries: If you're in an industry where customer feedback is essential for product success, sharing a roadmap can demonstrate commitment to user needs and align expectations.

2. Community Engagement: For products with active user communities (e.g., software as a service, developer tools), a public roadmap can inspire collaboration, solicit feedback, and help users plan their own roadmaps around your planned releases.

3. Competitive Advantage: In cases where transparency is a unique value proposition (such as open-source projects), sharing your roadmap can strengthen market differentiation.

4. Investor Relations: Public roadmaps are often helpful in cases where investors need visibility into the product vision and timeline.

5. Early-Stage or Beta Products: For beta versions or early-stage products, a public roadmap can help set realistic expectations about when features will be ready, especially when resources are limited, and iterative development is key.

What to Include in a Public Roadmap

A public roadmap typically focuses on high-level themes and goals, rather than specific dates or technical details. Here are the elements often included:

• Major Features and Goals: Broad categories like "improve security," "enhance user experience," or "expand integrations" without too much detail on technical specifics.

• Timelines in Quarters or Years: Avoid specific release dates, which can create pressure and expectations that are difficult to meet. Instead, use general time frames like "Q3 2024" or "Mid-2025."

• User-Centric Benefits: Frame items in terms of customer benefits rather than internal milestones. For example, "simplified onboarding process" instead of "UI revamp."

• Current Status Indicators: Some companies use labels like “Research,” “In Development,” and “Released” to give a sense of progress without specifying details.

What to Keep in an Internal Roadmap

The internal roadmap is generally more detailed, with specifics that aren’t ready for public release. It often includes:

• Specific Features and Technical Requirements: Full feature descriptions, technical specifications, and dependencies are better kept internal.

• Dates and Deadlines: Include precise dates and expected completion times to ensure accountability within the team.

• Risk Analysis and Contingency Plans: Internal roadmaps often contain risk assessments for certain initiatives, which help teams prepare for potential issues.

• Cross-Functional Dependencies: Details on resource allocation, team responsibilities, and cross-functional dependencies are essential for internal planning but may overwhelm or confuse external audiences.

• Strategic Initiatives and Experimentation: Include experimental or “nice-to-have” items in the internal roadmap but avoid creating external expectations for features that may be cut or changed.