The PMs' biggest leverage - Product Roadmaps

There as many roadmap variations as companies. What the most convenient way to think about it?

I recognise I’ve seen many many shades of roadmaps out there. Some of them where Gantt Charts disguised as roadmaps, but you can tell the difference.

Most of my experience has been in B2B (Large enterprise). You might ask, how is it related to the topic of roadmaps?

Well, think about the job you hire a roadmap for. One of them is communication. As a PM you might want to communicate the problems you will be tackling in the upcoming quarter. Therefore, what you want to communicate and how you want to communicate it changes upon the audience you are interacting with.

I would like to summarise a list of things I’ve learned throughout the years when it comes to build roadmaps in B2B for large enterprise.

1. Have a roadmap

The first weeks / months on the job, I learned that is very very very important to form an opinion on the main opportunities your team should be tackling. If not, someone else will fill the roadmap for you.

It seems counterintuitive, isn’t it? Why do I need to outline initiatives on a sequence when is likely they might change. Although it kind of true, that helps:

• developing your product intuition - although you may have an opinion, there are many inputs you can leverage, such as customer feedback, the business, on top of your strategy and vision for the product.

• to clarify short-term and needle-moving work - working in short-term problems is great, but what are the biggest rocks / bets that will help you grow 10x.

• to get leadership buy-in - if leadership is not onboard with the problems / initiatives you intend to accomplish, it’s going to be a drain of energy for your team and it’s likely you will end up changing things, and impacting what the team is doing.

• driving focused effort - in the moment you align behind a path that will drive you to a destination, you can channel the energy towards a particular destination and building momentum to achieve them.

2. Shades of grey

So far I’ve built, at least 10 different visualisations for the same roadmap. I want to clarify that there is a common thread among all of them, but the way to tell it, show it, share it, it will depend on your audience.

Leadership and other PMs: they do care about the business or customers problems / opportunities you will address in the upcoming quarters, and make sure it is aligned with the business priorities.
Pro Tip I: In this case you want to highlight the dependencies you may have to deliver the solution. You need to consider the impact on other initiatives, especially when platform teams are involved.

People on the field (Sales, Solution Consultant, Professional Services, Delivery Managers): they care about the thing you will deliver, so that they know how to assist the customers they are serving and plan their work accordingly.
Pro Tip I: Here it’s more important to highlight what you are not going to solve, than the other way around. These folks are about assisting the customer. They need to know what are the things they might develop themselves and solutions with the tools they have at their reach.

Customers and Service Providers: they care about the new shiny objects you will introduce, and how you plan to update some of the existing features.
Pro Tip I: Showing internal work required to deliver a specific functionality doesn’t add much value in this case.
Pro Tip II: Showing them a high-level timeline of when you expect to have that functionality available helps to align expectations.
Pro Tip III: Roadmaps with Now / Next / Later sometimes don’t seem to provide the level of precision these folks need. It’s better to be precise about the two upcoming quarters and less from the third quarter onwards.

3. What is in it?

Today at Nexthink we organise the work by different swim-lanes (one per each team) and we try to specify the expected outcome on each of the initiatives per releases.

But think about it, it’s very hard to predict if you will product the customer outcome you expect on a particular release. Sometimes you need more than one release to reach the outcome and having the same title for over three months can get someone nervous.

We changing now to reflect on each card of our roadmap, a 1-Pager with the problem, solution, risks, expected outcome, success metrics, for that initiative to see the light of production.

Sometimes this format doesn’t give you the right level of detail, because within a particular problem you may want to deliver two initiatives, but that’s fine. That is why you can adjust to the audience you have.

If your product leadership prefers to see the initiatives you’re going to deliver to solve a particular problem that’s fine, as long as you can easily articulate how those initiatives will help the customer and the business.

4. But, this is a Gantt Chart!!!

For those people who have suffered the time when Gantt Charts were asked to be build, think about this. Why am I visualising things as a Gantt Chart? Is it because I’m driving a project forward?

I was coaching one of our PMs the other day, and she was complaining about it. “Fede, look at this. It’s a Gatt Chart”. I could see her frustration, and after a couple of questions she realises this particular initiative was not a product per-se. It was a deliverable that has a clear deadline, with tons of dependencies to manage, and she has a clear representation of how it should be delivered to deliver the project on time.

Sometimes, it makes sense to have a Gantt Chart. Just make sure you have it for the right type of work.

Conclusion

Adjust the roadmap that you're presenting to your audience, but keep the coherence across all of them. Changing the visualisation doesn’t change the content, but what level of detail you wan to show and how you present it.