Ways to succeed with a product roadmap presentation

Question 1

Choose substance over buzzwords

Answer 1

Setting high-level themes is great for structuring the roadmap and context, but make sure you don’t stop there and have good answers for what is behind each high-level item. For example, if you’ve called a theme “intelligent services,” make sure to break this down into key initiatives and epics that are needed in order to deliver this theme.

Question 2

Set the right context

Answer 2

Technical teams need context for why you are building something on a roadmap. Let data speak, but also tell a powerful story from the perspective of your users. Use personas, and talk about some alternatives that you’ve excluded, and why. To help the entire team understand the roadmap the “why” matters as much as the “what.”

Question 3

Consider commitments carefully

Answer 3

If a feature doesn’t seem well thought through or realistic, yet it is still on the roadmap, this should scream red flag. You don’t want the technical team getting the impression that they have to build stuff just because you promised it to someone.

Even if you have a forcing function behind yourself that requires a particular change, make sure you understand and pass on the rationale to the team, and stand behind it yourself.

Question 4

Make realistic plans

Answer 4

The plan doesn’t need to be precise, but if the first thing your development manager sees when looking at a roadmap is a huge bottleneck then you’ll have he or she struggling with the roadmap throughout the rest of your presentation.

You need to have answers, a clear plan of action, and concise consideration about the “how it can be done” before asking for everyone’s commitment.

Question 5

Think big, start small

Answer 5

You need to be aware of where a product and team skills are today versus where you want them to be. It’s great to advance into new fields, which might require new skills in the team or moving away from existing technology, but don’t just write down dreams of where you’d like to be in a year. Instead, think about how to get there realistically.

Question 6

Build a business case

Answer 6

Technical teams care about businesses cases. Everyone has a vested interest in the business succeeding as a whole, and it can be great source of feedback or additional ideas.

Question 7

Balance mundane with motivating

Answer 7

Make sure you do research to confirm that your story is as innovative as you think. Aside from demotivated developers, the business impact of the lack of innovation is even worse.

With this said, even roadmaps will always be a balancing act between exciting new features, and technically not too interesting must-haves that just have to be done. Try to make sure that even the mundane is motivating on your roadmap.

Question 8

Think beyond MVP and v1

Answer 8

Creating a minimum viable product, and then a version 1 is one thing, but there’s also everything that happens post-launch: operations, maintenance, feature requests from users, continuous improvements, and new versions of other products and/or platforms that are integrated. A quick think on what the challenges and obstacles might be after a launch will bring these to light without much effort, and engineers will be thankful that you didn’t ignore these realities.

Question 9

Roll with the punches

Answer 9

Make sure you prepare and present the roadmap so that it’s flexible to changes.

Question 10

Be open and honest

Answer 10

A roadmap is there to provide guidance. It’s not a detailed plan for execution and everyone on a software team knows that. So if you don’t have all the details on a topic yet, be open about it.