9.5 Presenting roadmaps 🎯

note

This section includes an Activity 🎯

Learning objective

Through much hard work and stakeholder conversations, you've finally created a well-prioritized, great-looking roadmap. Now, it's time to communicate your vision to a wider audience than those who helped you put it together. Presenting your roadmap is part storytelling, part business pitch, and part discussion. Doing it well is key to your success as a PM.

Additionally, the process of presenting your roadmap doesn't end when your presentation does. Stakeholders will have comments, questions, and maybe even objections, and you must be prepared to answer their concerns. In this checkpoint, you will learn how to present your roadmaps and deal with these stakeholder reactions. You'll practice these skills in the assignment as well.

By the end of this checkpoint, you should be able to do the following:

• Effectively present a roadmap
• Practice handling the kinds of questions that may come up during roadmap presentations

Why present roadmaps?

Sharing roadmaps with your company and other stakeholders is something that you'll be asked to do on occasion, sometimes even monthly or quarterly. The main reason for this is to align your team around what's coming up next, for both their understanding and their sign-off.

If you work at a B2B company, you may be asked to share the roadmap externally to current or potential customers. Your current B2B users will want to know what's coming up so they can prepare for any changes that they'll need to make when those features launch. Potential customers will want to know what your roadmap is so that they can make a better decision about whether or not your product meets their current and future needs.

How to present a roadmap

As you prepare to present your roadmap, these are a few of the things you should consider.

The why

The most important part of presenting a roadmap is the explanation of the why behind the roadmap. It's not enough to simply tell someone what's happening next; you need to explain the rationale behind your decisions. Often the reason is that you're trying to accomplish your KPIs, but you should go deeper than that if you can.

For example, maybe you're launching some new features in your B2B product, and your goal is to achieve parity with a competitor's features and remove a competitive threat. Or perhaps you're trying to make your product appealing to new audiences. Or maybe you are focusing on a user problem, and you have compelling evidence that the proposals you're making in your roadmap will make a big difference for your conversion rates. Whatever the reason is, you need to be able to clearly communicate it so that your audience understands.

The best way to address the why in your presentation is to clearly articulate the goals and vision behind the roadmap before you get into presenting the detailed timelines. This can be as simple as a single sentence to explain the vision or a bullet point list of the goals and KPIs you're setting out to achieve. Make sure everyone understands and agrees on these before going further. If there's disagreement, then the rest of your roadmap could be in jeopardy.

Milestones and features

When you're reviewing your timeline of features, the best way to discuss it is to frame them as milestones—key points in time when specific outcomes will be achieved. For example, you could have a milestone for when the first version of the feature is available to beta testers and a further milestone for when it's released to everyone.

After presenting your milestones and timelines, you can review specific features as needed. Some of your stakeholders may want to hear about one or two features in particular, and you should be ready to explain them in detail. Otherwise, you should be able to explain each item in one or two sentences. If you have them, it can help to have mockups or prototypes to demonstrate what's coming up. As the saying goes, a picture is worth a thousand words—and a quick demo or interactive prototype is worth much more than your verbal description of it.

Risks and mitigation

If there are specific risks or problems that could derail the roadmap, you should describe them. In particular, explain what the risks are as well as the likelihood of these risks occurring. If you have a plan for preventing them, share that as well. Otherwise, share your plan for what you'll do if a problem occurs. Stakeholders may come up with scenarios that you haven't thought about, so be prepared to think through additional risks on the fly.

For more information about risk management, check out the video below by Mike Clayton.

Handling feedback

One of the most important parts of presenting a roadmap is dealing with the inevitable feedback you'll get about it. Your stakeholders will have many questions and comments about the roadmap, and you need to take them in stride. Here are the most common questions stakeholders may ask about your roadmap.

Is feature X really shipping on that date?

The best way to answer this question is to say that the dates and estimates reflect your best guess based on what you know right now. There's always the possibility that issues will arise and delay the features.

Why is X taking so long?

Sometimes you'll be asked about a feature that's already delayed, and your stakeholders are looking for updates to reassure them that things are back on track. Be honest about whether or not your issues were resolved and what your new estimates are.

Will you make sure that X does [specific functionality]?

If you've done your discovery and design well, your features should already reflect everything that your stakeholders want. Sometimes someone will throw a wrench in those plans and ask you about features you haven't considered or that you ignored.

If it's something you chose not to do, be clear about why you didn't do it. Make sure you have good evidence to support your decisions, explaining, for example, that it would take too long to build or that there wasn't enough customer demand. If it's something you were unaware of, you can have a brief conversation about it or take it offline for a 1-on-1 discussion to understand it on a deeper level. Don't let these demands hijack the entire meeting; you still have lots of other things to present about your roadmap.

Where is feature X? How much longer until we get feature Y?

You're going to get many questions about the features not on your roadmap. These will either be questions probing why you chose to prioritize those items so low (meaning the person asking wants them done sooner) or questions simply asking when those features are coming up (and the person asking is happy with everything else).

If you know the answer, let them know and move on. If it's urgent and that person is demanding it ASAP, then handle it similarly to the advice above—take it offline or discuss it briefly now. If it's not urgent, take it offline to discuss with the appropriate stakeholders at another time.

Activity 🎯

Go back to the roadmap you put together for the LinkedIn scenario two lessons back. Create a presentation to share your roadmap with internal stakeholders from across your company.

Limit your total presentation time to under 15 minutes. After about 10 minutes of presenting, turn to the "audience" for a Q&A, and answer the following questions from your stakeholders:

• A stakeholder angrily asks, "Why is most of the development effort going to the video server work?"
• You had a deadline you didn't include in the roadmap (this likely happened, as the deadlines you had in the original assignment were unrealistic), and a stakeholder asks, "Why was the feature not included?" "Why can't it be completed on time?" "What can be done to mitigate this?"
• A C-level stakeholder says, "Make sure that video call page has a way to send an SMS in case someone forgot about the call." You know this is not possible. Say no politely.

Evaluation criteria

Criteria	Exemplary	Proficient	Developing
Pitch	The student is concise and confident and does not mumble or fumble over words. The student knows the material and has rehearsed. The presentation is under 15 minutes.	The student is somewhat confident and seems nervous or agitated. The student's speech is, at times, unclear but is overall easy to understand. They have rehearsed but have some trouble conveying the message. The presentation is under 15 minutes.	The student is nervous and not easily understood. They fumble over various parts of the presentation, mumble, and are not always clear to understand. The student does not seem to have rehearsed. The presentation goes over 15 minutes.
Roadmap and questions	The choices are explained well and justified. The responses to the additional questions are reasonable.	The choices are explained fairly well, with one or two lacking justification. The student gives so-so responses to the additional questions.	The choices are not justified or explained. The student does not answer or gives poor answers to the additional questions.