Question Page

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

Krishna Panicker
Krishna Panicker
Airbase VP ProductMarch 8

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.
Jacqueline Porter
Jacqueline Porter
GitLab Director of Product ManagementApril 13

Since I have joined GitLab, where our product roadmaps are publicly accessible (, 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. 

Brandon Green
Brandon Green
Buffer Staff Product ManagerAugust 16

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.

Marvin Green
Marvin Green
Splunk Director, Product ManagementSeptember 13

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.

Kara Gillis
Kara Gillis
Splunk Sr. Director of Product Management, ObservabilityOctober 31

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:
  • Atlassian:

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:, it's a great idea to showcase the product in action! 


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.

Paresh Vakhariya
Paresh Vakhariya
Atlassian Director of Product Management (Confluence)June 22

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.

Lukas Pleva
Lukas Pleva
HubSpot Group Product ManagerJune 8

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.

Mike Flouton
Mike Flouton
GitLab VP, ProductOctober 25

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.

Preethy Vaidyanathan
Preethy Vaidyanathan
Matterport VP of ProductOctober 25

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.

Abhiroop Basu
Abhiroop Basu
Square Product ManagerOctober 24

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.

Tom Alterman
Tom Alterman
Notable Head of ProductOctober 26

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

Rodrigo Davies
Rodrigo Davies
Asana Director of Product Management, AIOctober 25

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.

Poorvi Shrivastav
Poorvi Shrivastav
Meta Senior Director of Product ManagementOctober 24

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.

Derek Ferguson
Derek Ferguson
GitLab Group Manager, ProductNovember 29

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.

Mike Arcuri
Mike Arcuri
Meta Director of Product - Horizon Worlds PlatformApril 25

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.

Top Product Management Mentors
Shahid Hussain
Shahid Hussain
Google Group Product Manager, Wear OS
Natalia Baryshnikova
Natalia Baryshnikova
Atlassian Head of Product, Enterprise Agility
Julian Dunn
Julian Dunn
Chainguard Senior Director of Product Management
Anton Kravchenko
Anton Kravchenko
Carta Sr. Director of Product Management
Patrick Davis
Patrick Davis
Google Group Product Manager
Nicolas Liatti
Nicolas Liatti
Adobe Senior Director of Product Management, 3D Category
Paresh Vakhariya
Paresh Vakhariya
Atlassian Director of Product Management (Confluence)
Preethy Vaidyanathan
Preethy Vaidyanathan
Matterport VP of Product
Jacqueline Porter
Jacqueline Porter
GitLab Director of Product Management
Puja Hait
Puja Hait
Google Group Product Manager