How do you think about communicating your roadmap to other teams? What level of detail do people need?
The level of detail that people on other teams need depends on what they are using the roadmap for. Our roadmap planning tool enables us to create multiple views of the roadmap - we tailor each view to the use cases of the consumers. For example, we have the following views:
- A view for our quarterly planning process - this view is primarily used to communicate to execs so it focuses on the high level business goals that each roadmap item supports and doesn’t contain many implementation details.
- An internal view that go-to-market team members can use to understand estimated delivery dates for items in active development or beta - this view contains much more detail - for example the user needs that the release addresses and how to sign up for betas.
- A public view that is available to our customers - this view contains customer facing explanations of each project and information on how our customers can help us develop it. For example, an item might have a few questions about the customer’s use case and interested customers can send us answers to those questions.
Identify who wants and needs visibility of the Roadmap. Ask each group why and what they will do with the information. Then tailor the experience for them.
For example sales may want to demonstrate to customers that the company is continually investing in product, or share the vision for you are headed. If that's the case using a Now / Next Later format maybe sufficient.
Whereas support may need to consider the spikes in calls and plan their work around the release of a new feature. If so then knowing spefiic GTM dates for the next 3 months may suffice.
It's also worth testing formats with each audience before spending the time to put the roadmap together.
I love this question - the audience is everything! I typically have 3 pre-prepared altitudes for my product roadmap which correspond to a specific persona and time horizon
1. Annual Thematic Roadmap with Big Boulder Features - Executives and Buyers of Product: This roadmap has a conceptual, initiative-based view. So, it features connected narratives of multiple features for what the themes of the roadmap will deliver for a buyer or an executive interested in the ROI of the roadmap.
2. Quarterly Feature Review - Field Teams/End users: For internal teams that sell the solution and are working with technical personas, I have a quarter by a quarter snapshot of the features that are most relevant for the day-to-day work of the end-user. So, I like to think of these as Rocks - smaller more tangible features that can be used.
3. Community contributor monthly roadmap - Internal technical teams/Community members that will contribute to the roadmap: This is the most granular and technically informed roadmap that shows what the team is working on in the current month and how users can potentially contribute to the roadmap. This is what typically is considered a sprint review and has minor, iterative deliverables to enable adjacent product teams to the core features being delivered that month.
I will use a community page, release notes, and internal handbooks to publish these different POVs for the organization and others to consume readily.
I've found that there are basically 2 levels of detail that matter, with the goal of each being somewhat different:
- Executive summary (Director/VP/C-suite audience) - which focuses much more on the problem areas to focus on, why, and a high level outlook on the features or impact you aim to ship in that quarter/half/year. Goal is to provide guidance to the exec team on where your product domain is going, make clear where you need support or have cross-functional dependencies or risks.
- Stakeholder-facing roadmap - higher level of detail than the exec summary, with more focus on a sequence of features/initiatives to ship but still with a heavy focus on the why and goals. Goal is to ensure (a) shared understanding of the goals of Product in the given quarter/half/year and (b) coordination with partner and stakeholder teams, calling out dependencies and risks.
There is likely a 3rd roadmap that makes sense in most cases, which is much more in the weeds and meant for your immediate squad - but for me, that has over time become more of the focus of an engineering lead/manager partner (ie. that person owns this 3rd document and it's focused on execution of the stakeholder-facing roadmap).
Thanks for the question! Earlier in my PM career, I used to keep my roadmap a “secret”. As I gain more experience, I realized that it’s valuable to share the roadmap openly with sales, marketing and key stakeholders to build a solid partnership. How I communicate the roadmap and the level of detail I share is based on what each team needs. For example, the sales leadership team may want to know about the big rocks and themes. Your sales engineers will need to go into the weeds of the roadmap and even how you are thinking about building out the features. The best thing to do is to ask the teams/stakeholders what level of info they need and then provide that detail.
I tailor the product roadmap to the person / group with whom I'm communicating. I often will use Google Slides for a customer or sales facing presentation. With engineering, I'll often use a spreadsheet that lists roadmap initiatives in the order of priority and effort.
Communicating with customers: Is this the first time we're speaking? How much time do we have? If it's the first time we're giving a roadmap presentation to the customer, I provide more context upfront to help the customer understand how the roadmap impacts them directly. I will include some slides on the pain points and market trends that I'm solving for, map those pain points to high level overview of the roadmap themes, and then highlight our most applicable major features (and the customer benefits of the feature) in a little more detail, typically one per slide. I also make sure to provide a rrough timeline (3 months, 6 months, 12 months) for any feature I cover. If it's not the first time I've spoken with the customer, I focus on what's changed / newly delivered in the product since the last time we spoke, specific updates to the roadmap that would be applicable to this particular customer, focusing on one major feature area per slide (and including the benefits of the feature!). I will sometimes include success stories of existing customers to demonstrate real world examples. I then welcome questions after major sections of the presentation, for example after each feature or after pain points to make sure we're aligned on the same premise before diving into features.
Communicating with non-technical sales: Almost exactly like the customer version, but I spend more time on how the roadmap items impact pricing, packaging, integration with existing products, and updated timelines. I also spend a lot of time on how to communicate the benefits of each major roadmap item in concise and clear language, so it's easier to convey to the customer.
Communicating with technical sales: Very similar to non-technical sales, but maybe a little bit more about specific capabilities, scale limits, compliance, or backend updates/updated tech debt that fix internally-known product issues. Technical enablement on new features and roadmap items will also focus on HOW to implement the feature.
Communicating with engineering: Usually done as part of planning, it's important for engineers to understand the "why" behind anything they will be decide "how" to implement, and the more context they have about the "why now" reasons behind a feature, and the requirements about "when" - the more likely you'll deliver an accurate roadmap! Engineers care about many things regarding the roadmap, but understanding your priorities and required timelines are paramount to help determine the scope of the work and any dependencies you may have in implementation.
A product roadmap is a tool that communicates strategy, goals, metrics, features, initiatives, and timelines to the organization. It is key to achieving alignment and buy-in from leadership and ensuring that teams are on the same page. Regular communication with stakeholders, especially when changes occur, is essential. Below are some key stakeholders and their expectations from a roadmap.
- Sales and customer success need to understand feature timelines and the value they add to customers
- Marketing needs to understand the initiatives, features, and value to different segments to prepare a go-to-market strategy
- Engineering needs to understand the overall vision, outcomes as well as feature details and complexity for execution
- Customer support needs to know about enhancements and timelines to keep customers happy
Note that depending on the organization, Finance, Legal, Operations and others may also need to be in the loop on the roadmap. By getting a complete picture of stakeholders in your company and understanding each team's needs and communicating effectively, PMs can drive product success and meet customer needs.
It depends on who the other team is and what I expect them to do with the information.
If it's another team that I depend on to execute my goals, I'll share more details. It's important for them to have a good understanding of what exactly my team's building, why, when it's shipping (estimated), and what I need from them.
By contrast, if I don't have a dependency on the other team, I'll keep it more high-level and focus more on the business and customer impact than the nitty-gritty details.
That said, regardless of the target audience, remember that "clear is kind." We're all busy professionals. Even in the scenario where I share a more detailed roadmap, I put the most crucial information at the top to make it easy to scan.
What is your objective, who is your audience and what are their needs. An effective presentation of your roadmap addresses all three questions. The communication style you deploy is starting with the audience's needs and weaving in what you hope to achieve. For example:
Your audience: prospective customer, Your goal: inspire to close the deal
Understand prospective customer main pain points. Highlight the main product features existing and in your roadmap that addresses the pain points and solves them effectively
To address your goal, weave in visuals, other customer testimonials, case studies to drive inspiration and show what success would look like if they adopted your product offering
Your audience: Sales, marketing, field teams, Your goal: drive adoption of upcoming features
Present roadmap themes, features that solve customer/market problem and how they help drive customer goals
To drive your goal to pitch the new launch and drive adoption, connect the launch to what your GTM will care about. Is it part of top asks from existing customers, does it help unlock new customer segment or vertical and how this can help your cross-functional team in-turn be successful to hit their quarterly goals
Depending on the team in question the level of detail and approach will differ on how you communicate your roadmap. Here are some of the key teams you'll partner with and approaches you can take to communicate your roadmap:
Core team: For your design, engineering, and data science partners you want to get into the weeds. Typically you want to share every element of the roadmap and more specifically the requirements for each and every feature. After all your core team are responsible for building the features. No detail is too small! Communicate early and often.
Partner product teams: For most larger companies, it's likely you will be working with other teams. For these teams you need to identify which features those teams will care about. You don't need to tell each team about all the features you're building. Highlight the important ones and explain why they need to know about it.
Product marketing: You'll want to share everything customer facing with your product marketing partners and work with them to craft the benefit/value statement for each feature. Your PMM partner is responsible for marketing the features to customers, so it's important they understand the why, what, and how of the feature. They need to know everything, minus the technical implementation.
Sales: Sales will typically work with Product Marketing, so you don't necessarily need to create something separate for these teams.
Customer success/support: Success and support will need to know what to do when things go wrong. So you should have a clear FAQ or table that highlights potential issues with each feature and ways to diagnose it.
It depends a lot on the team, of course. There should always be a one-page version that any interested stakeholder can consume, but that won't answer all the questions some teams will have. I've found doing live Q&As with teams or groups of teams during roadmapping can be super helpful, to find out what people care most about. From there I can decide whether additional artifacts would be useful, and what shape they need to be. Making lots of shareable artifacts ahead of time (beyond one-pagers) can sometimes be wasted effort.
How you communicate your roadmaps depends on who you are communicating it to plus the existing processes in your organization. Here are some examples
Executive Staff: I have had success in creating decks for E-staff members highlighting the specific items that they are interested in. I have presented these decks in a meeting setting to gather feedback and also setup clear expectations on the Anti Roadmap (What we are not going to do)
Stakeholder Teams outside of your group: My favorite is a readout deck that contains your roadmap and details about specific initiatives. This can be sent out in a product-all/company-wide slack channel
Your own team: This should be the most detailed version of your roadmap. Usually most teams prefer their roadmap to be directly reported out of their primary product dev tool eg: Jira. This version usually has a look ahead view/backlog, current execution progress eg gantt charts
Roadmap communication is often just as critical as developing it in the first place. Our team has a number of internal stakeholders that are directly impacted by the decisions we make. When we consider the level of detail, we try to anchor Goals and Plays.
Goals ensure that we are focused on the right thematic areas, and our goals are prioritized before the start of the year. We socialize our goals and their priority level to help teams understand where we will be focusing, and why. Plays are a level deeper, tying to actions that we will take, features that we will build, and tangible deliverables that will help move the needle on our goals.
Plays offer us the ability to understand effort, timing, and dependencies, which can then be socialized for everyone else to see. This empowers our teams to understand who is doing what, and when, for a quarter or half-year at a time.
Communication of roadmap with internal teams is important to ensure alignment of the vision and priorities. On an annual basis, Product org should share the strategy and high level roadmap. On a quarterly basis, product teams should share updates to roadmap based on what has been delivered and what is planned for upcoming quarters.
Based on the type of stakeholders you are communicating your roadmap, the level of detail will differ. Here are the different examples and scenarios:
Upper Management and Secondary Stakeholders - High level of the what and why and when
Teams involved directly to build features and/or direct consumers of the feature - Detailed requirements and dependency management
You can use different delivery mechanisms for the roadmap. Async email/slack communication and/or Inception meetings
Start with a good understanding each one of your audience.
For executive leadership, emphasise high-level goals and how key initiatives align with the company’s strategic objectives.
For sales and marketing, focus on the features, differentiators, and timelines that help set customer expectations.
Customer support and success teams benefit from knowing specific capabilities, potential customer impact, and key training dates.
Tailor detail levels based on each group’s role. High-level themes are ideal for those not involved in development, while teams closer to the work (like Customer Success) need more specifics on features, timing, and value.
Engineering teams require technical depth to manage dependencies.
Monthly syncs keep everyone informed, while a centralised, accessible roadmap document on a platform like Confluence or SharePoint helps provide a reliable source for updates.
Top Product Management Mentors
