Roadmaps are cool and useful. But a bit tricky to get right. Some folks confuse a roadmap with a high level project plan. It’s not. Others use roadmaps as a way to keep a schedule, not ideal.

The main use I found for roadmaps are to help you clarify what you’re trying to accomplish. And to help your stakeholders understand that too (including your team). It helps you see the forest fore the trees.

Think of roadmaps as flavoured towards users and product marketing and less towards engineering. For engineering it’s probably better to have a high level project plan. In a sense, a roadmap is somewhat aspirational and focused on user value. It shows the North Star of where you are driving.

Roadmaps vs. Project Plan

You would expect stakeholders like CEOs or CFOs to “get” your roadmap quickly. It should be in a language that they understand (user and business value). If this isn’t happening, and you find yourself having to explain each item on the roadmap, then you are working on a project plan not a roadmap.

Maybe this is a distinction between a product roadmap and an engineering roadmap. Or between a product roadmap and a technical product roadmap. Either way, bending your roadmap towards a piece that CEO/CFO understand and can talk around will create lots of value. You can involve them more, get good feedback, and get buy in.

Solving the Right Problem

You might end up having two “roadmaps”. One which is aspirational / oriented to stakeholders / user and business value oriented. And one which is a high level project plan, oriented towards engineering, more delivery oriented. It’s useful to know which one you’re building.

Part of the problem here is what is the problem you’re trying to solve. If you’re trying to solve delivery problems then the more technical roadmap is the answer. If the problem you have is that your stakeholders and broader organisation don’t know what you’re doing / no buy in, then you need to develop a better value oriented roadmap.

Most people don’t know where the term use cases came from. It was originally work that was done outside of the UML work groups. I think it was Nordic researchers but I forget whom or where. They wanted to design a framework for capturing user value. And they landed on actors, use cases, etc. Afterwards, this was merged with the UML framework which is very engineer-y (Unified Modeling Language).

Balancing Act

But there’s always a tension between them. As use cases are built in the language of a user and what they value. And the implementation of use cases is built in the language of technical components (systems and such). The same holds true of roadmap. It’s useful to know why that tension happens when you’re putting the roadmap together.