The dos and don’ts of product roadmapping

Remember planning a roadtrip in the good old days before smartphones? We used to fire up the dial-up connection, connect to the internet at a snail’s pace, load up MapQuest, and print out the step-by-step instructions for our journey. Before that, we had an actual physical map—a giant, unwieldy piece of paper that we’d refer to periodically. (And if we were lucky, we might even occasionally figure out how to fold it up correctly when we were done.)

Why take this trip down memory lane? It’s a good reminder that over time, technology has evolved—and so has the way we think about maps.

It’s similar within the product world. While product roadmaps have been around since before the dial-up internet days, they’ve also evolved over time. The best roadmaps are adapted to the way product and engineering teams work right now. 

If you’re worried about where your own roadmapping practices fall on the paper-map-to-smartphone-GPS spectrum, we’ve got you. We partnered up with Mike Belsito of Product Collective to gather insights from several product leaders and practitioners to help you navigate the dos and don’ts of product roadmapping today. 

Do: Showcase your progress as well as your plans

“Great roadmaps don’t just show what’s to come. They show progress made as well.” Janna Bastow, Co-founder & CEO of ProdPad and originator of the now/next/later roadmap

We tend to associate roadmaps with the future—they show us the things we want to do. But Janna suggests also including a “completed” section so you can see what you’ve already accomplished and remind yourself of the big problem you’re trying to solve. 

Do: Focus on outcomes and business impact.

“Don’t focus on the features. Focus on the outcomes—and how you can enable the priorities of your business.” John Knific, Managing Director of Product, EAB

Yes, it’s helpful for roadmaps to include new features and products. But we want to avoid turning our roadmap into a giant to-do list. And this is why John suggests looking for ways to account for your business outcomes and objectives on your roadmap.

Mike puts it this way: “Roadmaps aren’t just meant to be a list of things to do, but to give us space to execute our company’s strategies.” Read more about aligning your roadmap to your business strategy here.

Do: Recognize the relationship between timeline and accuracy.

“The farther a roadmap goes out—the less precision it will have… and this should be communicated.” Kent McDonald, Founder KBP Media

A lot can change in a year when it comes to business, technology, and the world at large. Rather than ignoring this fact, it’s important to take it into account when creating your product roadmap. Your priorities, business objectives, and even the capabilities of your team are likely to change when you’re looking beyond the next few quarters. Make sure your roadmap reflects the fact that the items that are further out are much less precise and much more likely to change.

Do: Tell a story that aligns with your overall vision.

“Your roadmap shouldn’t just show what’s being done—it should help tell a story that aligns with your overall vision.” Quadri Oshibotu, Founder, Product Hall

While roadmaps are visual artifacts, it’s helpful to think of them as much more than that. Roadmaps are part of a narrative that describes what the world looks like now—the problems and pain points—and what it will look like once you’ve solved them.

“It creates an aspirational feeling that makes it easier for other people to buy in,” says Mike. 

Don’t: Have too many versions of your roadmap floating around.

“While well-intentioned, an internal and external roadmap just gets messy.” Alicia Dixon, Principal PM at Walmart

Some product teams create internal and external versions of their roadmaps. On the one hand, this makes sense: Different audiences need different levels of detail in their roadmap. But this can also create confusion. What happens if a customer accidentally gets access to an “internal” version of your roadmap?

“When you have multiple roadmaps floating around, you kind of have to expect that they might get out there to the audience they weren’t intended for. You can avoid this by maintaining one roadmap and assuming everybody will end up seeing it, including customers,” says Mike. 

Don’t: Put specific dates on your roadmap.

“Don’t put dates on a roadmap as dates give the impression that things are set in stone, and product roadmaps are almost never set in stone.” Danie Karaplis, Product Leader and Speaker

Rather than committing to specific dates on your roadmap, Mike recommends sharing broader timeframes like “now/next/later” or “summer season.” This provides some buffer and accounts for a lot of the unpredictability related to market forces, investors, competition, etc. “Unless you’re at that very end stage, a roadmap should be a fluid, living document,” says Mike.

Don’t: Expect all stakeholders to receive the roadmap the same way.

“Don’t expect all stakeholders (internal and external) to digest the roadmap the same way as each has different motivations.” Ben Foster, Former CPO of Whoop

Everyone brings their own perspective and priorities into their interactions with a roadmap. Customers care about which of their problems are being solved. Engineers are looking for granular detail of exactly what they’re expected to build when. Executives are looking for the impact you intend to have on the business.

“We should be mindful of the motivations and needs of different stakeholders and how to communicate in a way that meets their needs,” says Mike. Read more about how to present your roadmap to different audiences here.

Don’t: Treat your roadmap like a to-do list.

“A roadmap is not a list of things to do and not a release plan. So don’t treat it as such!” Andrea Saez, Senior Product Manager at Trint

As we’ve covered in some of the previous points, roadmaps have the power to rally your team around a shared goal. But that only works when you consider them as strategic documents rather than to-do lists. Consider how you can share the problems you’re going to solve and provide some indication of how you plan to solve them.

Mike reminds us, “If we need to solve the problems in a different way, that’s okay. The features are more likely to change. The problems we’re solving? Not so much.” 

Ready to take the next step in your product roadmap adventure? Check out our complete guide to roadmap mistakes and pro tips here.