How to successfully deliver your product roadmap presentation to stakeholders

A well-made product roadmap is one of the most valuable resources for a SaaS company.

It informs and sets expectations for everyone in and around an organization. However, communicating product roadmaps and the information in them can be tricky.

Every company has many groups of “stakeholders”. These are people or organizations that care about how you’re doing. There are both internal and external stakeholders

Different stakeholders have different interests, values, and concerns, depending on their commitment to your business.

Presenting the same information to these different groups generalizes it to the point where it’s not useful. That’s why you should pick and choose the main points based on the stakeholder group.

You don’t necessarily need several physical versions of your roadmap. However, there are times when you have the power to choose which information to highlight. It could be in meetings, presentations, Q&A rounds, etc.

In these situations, you should focus on different aspects depending on who you’re talking to. This way, every group gets the most valuable information for them.

Personalizing roadmap presentations to different groups avoids a lot of miscommunication, confusion and unnecessary back and forth.

This post is going to dive into building your roadmap presentation. We’re also going to talk about the most common things different stakeholders care (and don’t care) about.

PS: the following points are generalizations to guide you in your presentations. There will always be exceptions when it comes to what someone cares about. Make sure to leave room for discussion and questions for these cases.

Elements of the presentation

Let’s start by looking at what goes into your presentation.

What you include in your presentation depends on a few things: the purpose, which stakeholder you’re presenting to, and how your team works. Your role might also influence how you present. Product managers will likely present very differently than a founder or a CEO.

Here are some common elements that a product manager can include in the presentation:

1. Introduction — give a brief overview of your product and the goal of your presentation
2. Product vision — explain the vision product management has and how this roadmap supports it
3. Market analysis — discuss market trends, what your competition is building, and any present opportunities 
4. Current status — look at the current status of your product development process
5. Priorities — list your product priorities and highlight important features that you will work on. You might also explore your prioritization formula.
6. Roadmap timeline — include a visual timeline showing when features will be worked on, completed, and how long they’ll take. A Gantt chart can be helpful here. 
7. Budget/resources — include a breakdown of the expected costs to fulfill this roadmap. That can include staff time and money. 
8. Risk assessment — identify any risks that could get in the way of completing the roadmap, and how you’ll prevent them.
9. Q&A — give your stakeholders a chance to learn more, provide feedback, and resolve concerns.

 Now that we know what you’ll want to include, let’s look at different stakeholders and how you can tailor your presentation for them.

Stakeholders

Let’s take a look at the most common types of stakeholders the product team would present to. 

Executives/Investors

Their main objective: to see whether the company is moving in the right direction in general, whether the company is focused on the right things.
What they care about: high level goals, plans and progress, validation of plans.
What they don’t care about: technical details, complicated data, detailed timelines.

How to present:

• Start with high level goals and when they are expected to be met
• Use simple data that validates why these goals exist (customer requests, etc)
• Explain the expected outcome of these goals (in simple words and numbers)
• Briefly describe the progress towards these goals

Investors and executives aren’t intensely involved in your company’s everyday operations. They probably have tons of other ventures on the side. This means that they can’t spend time on details that don’t matter to them.

Focus on the general direction and high-level goals—and keep it short and sweet.

Customers/users

Their main objective: making sure their business can operate or keep operating using the software, and seeking added value for their use case.
What they care about: when things will be done, exactly what will be done, and how it changes things for their business.
What they don’t care about: who’s responsible, technical details, detailed timelines.

How to present:

• Customers don’t care about details of a roadmap item; they want to know when they can start using it
• Speak about planned deadlines for product roadmap items, but remember to “under promise and over deliver”
• They also want to know what an item actually entails, so they know whether it’s valuable for them or not
• If you collect feedback in a public board and have requests or items you’re NOT going to put in your roadmap, make that very clear, too

Remember—customers are using your software to improve their own business. They care about the functionality of your product. Focus on changes in that functionality. If you’re adding features, explain how it can add value to their use case.

If you’re removing or not building certain features, be transparent about it.

Technical team members

Their main objective: getting their tasks done in a timely and efficient manner.
What they care about: technical details, detailed timeline, who’s responsible for what.
What they don’t care about: high-level information, excessive details about the reasoning behind a task (such as in-depth customer research).

How to present:

• Focus on timelines first—product and development teams need to be able to coordinate well to meet deadlines
• Then, go into the technical requirements of everything on the roadmap
• Ownership is also crucial—make sure everyone is crystal clear about which items on the product roadmap they are directly responsible for

Technical team members want to be efficient with making functionality happen. They need to know when, where, what, and who with they have to do in order to build something great. Coordination is key.

Non-technical team members

This group is pretty broad, but we’d consider customer success, human resources, marketing, and your sales team the main members. 

Their main objective: efficiently organizing their work, communication, and tasks around the product roadmap.
What they care about: general timelines, who’s responsible for what (for questions and information), details about big changes so they can prepare, benefits of items to communicate to third parties.
What they don’t care about: technical details.

Let’s look at what each of these groups’ members are interested in:

Customer success — wants to see if a feature customers are asking for is on the roadmap. This can help them communicate better with customers and set expectations.

Marketing — they need to know what features are coming so they can plan launch campaigns. They also want to know if new features change product strategy or positioning. Marketing is often interested in features that help them compete against competitors.

The sales team — they want to see if there are features planned that can help them close deals. They might have leads waiting on new features. Or, they might be able to upsell existing customers interested in a new feature. 

Human resources — usually want to know if internal tools they need are being worked on. They might also want to see if the company’s resources are being fully utilized. 

How to present:

• Focus on the timeline and what will be happening when—especially when it comes to big changes
• This gives marketing plenty of time to organize their work around external communication
• Big changes and deadlines should also be communicated to support so they can let (potential) customers know about what’s coming up
• Letting non-technical team members know who’s in the implementation team will also create a sense of security around needing extra information

Non-technical team members want to make sure their job aligns with the product goals.

These people are often left out of the loop when it comes to roadmaps and other “technical” discussions. Don’t make that mistake.

Product roadmap templates

There are several ways to build a product roadmap presentation.

You could opt to build a presentation in Powerpoint, Keynote, or Google Slides. This is a good option for more formal presentations. That could be better for executives, investors, and customers.

Pinterest is a great resource for finding a product roadmap Powerpoint template that works for you. You’ll likely want a visual roadmap, and you need a roadmap template that fits your brand. Pinterest lets you browse hundreds of visual roadmap templates quickly. You can then follow the link to download the one that works for you.

If you opt to go for a less formal presentation, you might not need a Powerpoint template at all.

Using a Public Roadmap

Your product roadmap tool likely includes a visual roadmap view that you can present. Canny’s roadmap tool can do this for you. 

Here’s a look at how we share our public roadmap:

We keep a backlog of ideas and feature requests on our Canny board. Using our roadmap prioritization feature, we score all these ideas and decide which ones to add to the roadmap.

Stakeholders can then just visit our public roadmap to see what features are coming. This is an easier way of communicating with stakeholders. It also lets them access the info whenever they want.

Check out these examples of public product roadmaps for some inspiration. 

If you want to present a public roadmap like this, all you need to do is screen share and walk through it. 

Focus on the right product roadmap items for the right people

Having a roadmap is great. However, discussing it is only valuable if you talk to the right people the right way.

There is no universal way of presenting a roadmap. Generalizing and assuming everyone is fine with the same information will cause confusion, unnecessary questions, and coordination issues.

Choosing what to focus on when communicating a roadmap to different stakeholders will ensure everyone will get optimal information for what they need.