[Knowledge Sharing] Adding value to your roadmap

Roadmaps are about communication. When the executives want to talk about money, the product managers want to talk about planning, and the software engineers want to talk about features, you need something to focus the discussion. A well-designed roadmap will shift the conversation to what matters: adding value.

Our valued eco-system partners Wouter Neyndorff and Wilco van Duinkerken have recently launched their new venture, Producthub. With Producthub, their vision is to productize the methodologies they have developed during the past years as product leaders. Below they outline one of these methodologies:

Continue reading if you want to have conversations around ROI that include the whole team.
Learn how to visualize your roadmap in such a way that it drives participation by your entire organization.

---

Roadmap Radar

When you talk about your product roadmap, you want to make decisions based on the value each project adds. A good picture shows all the relevant information at the right level of detail and allows you to move projects around while you’re discussing your options.

This visualization gives you great insight into your roadmap. Each circle represents a project in your product’s development cycle. The size of the circle tells you the estimated value of the project. The distance from the center shows where it is on the timeline. Arrows indicate dependencies between projects. And finally, projects are grouped based on their source.

Project value gives you a quick estimation of how much a project impacts the bottom line. It’s easy to lose track of this if you’re in the midst of a discussion about features versus deadlines, but you’d be surprised how much focus it’ll bring when projects have a number on them.

Of course, that number has to be based on something. Here’s our suggestion.

Expected returns – expected investments = project value

If that looks overly simplistic to you, then keep in mind that we’re not using the project value for accounting purposes. The goal is communication. A rough estimate is more than enough to get a sense of the relative value of each project.

A timeline can be based on quarters, sprints, days, or any measure of time you want. While that’s fine for planning, our purpose here isn’t planning. When it comes to communication, projects only come in three flavors.

• Now: we’re actively working on this project.
• Next: we’ll pick up this project when the current projects have been delivered.
• Later: other relevant projects, even if they’re far in the future.

Dependencies are important, not just because they determine when you can work on a project, but also because they bring hidden assumptions to the fore. When they are clearly visible on the roadmap, you’ll hear from team members, who don’t believe the dependency exists, and from others who will want to add dependencies. Those are the discussions you want to have.

The project source identifies where a project’s value comes from.

• Customer request: adds value now.
• Vision: adds value in the future.
• Operations & Maintenance: keeps your technology healthy and flexible.

Most members of your team will work in only one of these areas. Making them aware of the other areas prevents tunnel vision.

Try it out

If you want to give the roadmap radar a go, here’s an empty one. You can print it, paste it into PowerPoint, or import it into Miro.

Once you’re convinced of the usefulness of the roadmap radar, we invite you to come and have a look at ProductHub. Not only does our tool draw a roadmap radar for you, but it also helps with estimating project value, prioritizing projects, and keeping track of your ROI.

If you have ideas on adding value to your roadmap, we’d love to talk about it.