How to Make Product Roadmaps not Dangerous

My 12-year old son recently got a belt sander from his Opa. Opa is a German name for grandfather.  My son is making a bookshelf and has a lot of sanding to do. The belt sander will do the work quickly. It is the right tool for the job, but only if it is used properly. The powerful motor and rapidly moving belt also makes it a beast. If it is not properly handled, it can do a lot of damage to the person using it and anything around it. I showed my son how to use it correctly and we discussed what can happen if he doesn’t use it the way he should. Thankfully, he has been careful with it and the sanding is going well.

That is the thing with powerful tools. Used properly they are a valuable aid. Used incorrectly, they can cause a lot of pain and turmoil.

The same applies to a frequent tool product managers use — the product roadmap. The traditional use of a roadmap nearly guarantees that product managers will get damaged in some way, like mishandling a belt sander. Think about it. A roadmap requires you to keep your promise even after you have learned that the planned features are no longer needed. Well, at least you kept your promise, but you built the wrong thing. Or, you do the right thing and not add features, breaking your promise you made by putting them on the roadmap.

While the roadmap is one of the most frequently used tools by product managers, it is also one of the most unsafe.

But, the traditional way of using roadmaps doesn’t have to continue. To discuss how they should be used, the author of “Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty,” Bruce McCarthy joins us.

The book has received high praise, including from Steve Blank, the grandfather of Lean Startup, who said, “It’s about time someone brought product roadmapping out of the dark ages of waterfall development and made it into the strategic communications tool it should be. McCarthy and team have cracked the code.”

In the discussion, you’ll learn:

1. What is and is not a product roadmap.
2. Who it is for.
3. The inputs needed to properly construct a roadmap.
4. How to organize a roadmap.
5. Ways to prioritize product features.

Here is a summary of the topics discussed and a link to the interview:

[3:06] What is a product roadmap?

It’s not a set of features and dates, which is what most people think, but that’s actually a release plan or a project plan. The product roadmap is really about the why — what’s the product vision and what’s the problem you’re trying to solve. It should inspire people to develop a release plan, but not include those details.

[5:28] Who is the product roadmap for?

It’s really for everyone in the organization, as well as customers and related partners. It’s the story you tell internally and externally of what the product is about and what you are trying to accomplish. It’s a great tool for customer conversations and validating what is or is not important to them. It should be developed collaboratively in addition to being shared across the organization. The more buy-in you receive early on, the more support you’ll have when it comes time to put that plan into action.

[10:47] What are the pitfalls of a traditional roadmap?

Traditional roadmaps overpromise on features and dates, so they’ve abandoned the practice entirely. As a result, thinking becomes very short-term. People only want to see out as far as they can promise, which is usually not more than a few weeks. We should be able to change our mind as we learn, which is why the old-fashioned roadmap doesn’t work anymore.  Shifting attention to focus on the higher-level vision moves you away from that cycle of shortsighted thinking.

[12:38] What information is needed to build a roadmap?

You need to start with a product vision. What value is our product bringing to the marketplace? How is it benefiting the consumer and the company? It also needs to include the business objectives — things like market share, engagement, or retention that you often see in OKRs. What indicators will help us make sure we are on the right track and have a viable business model? In order to have those inputs, you need to understand the marketplace, your customers, your stakeholders, and your business. The earlier you involve those groups, the more they’ll feel a sense of ownership over the results.

[20:33] How should a roadmap be organized?

There are three components to any roadmap: primary, secondary, and complimentary. Primary components are essential to the roadmap; things like a vision and the problem that needs to be solved. It’s stating a goal instead of a deliverable. This information is frequently left out and you often end up with a solution to a problem that’s been forgotten along the way. Timeframes are another primary component, even if they are at a broad level and not directly connected to releases. One way to think about this is breaking it down into “now, next, and later.” A disclaimer is another primary component. Your stakeholders need to realize that the roadmap is subject to change. The secondary components are features that add color. If you’re close to a release date and are confident in what you are producing, there’s no reason not to include them. Secondary components can be added, removed or changed based on the audience. You might also include tags about what part of the product you’re working on or what user groups you are considering.

[30:24] How should product managers prioritize features for a roadmap?

We outline five different ways to do this in the book including the Kano model, Mosco model, and the ROI scorecard. The ROI approach is my favorite and involves comparing the ROI for any given part of the project against the business goals. In other words, how will this idea impact the business goals compared to the effort involved to get there? You can do this for each feature and create a scoring model. Don’t worry about getting too detailed, you’re just trying to prioritize and determine which features need to be looked at more closely. Anyone looking at the scorecard should be able to tell what’s most important without having to do a lot of math. This approach also leads to valuable discussions about whether the goals are right if the features end up in a different order than you were expecting.

Listen to the interview with Bruce McCarthy on The Everyday Innovator Podcast for product managers and innovators.

Wait! Before you go…

Choose how you want the latest innovation content delivered to you:

• Daily — RSS Feed — Email — Twitter — Facebook — Linkedin Today
• Weekly — Email Newsletter — Free Magazine — Linkedin Group

Chad McAllister, PhD. is a product innovation guide, innovation management educator, and recovering engineer. He leads Product Innovation Educators, which trains product managers to create products customers love. He also hosts The Everyday Innovator weekly podcast, sharing knowledge from innovation thought leaders and practitioners. Follow @ChadMcAllister