4 Quick Game Changers for Your Product Roadmap
If you’re reading this article, you likely already know the purpose of a product roadmap and probably have a template (or twelve) that you’ve based yours on. You also probably have a love/hate relationship with yours: you know it’s necessary, but would rather not look at it most days.
With these four mindset elements, you can transform this one-dimensional document into a colorful and cogent vision that everyone is eager to explore and engage with.
Use it to tell a compelling story. The most effective product roadmaps are treated like storytelling mechanisms by their owners, filled with words and visuals that help communicate the “why,” “how,” and – gasp – “when” your product will evolve into the product vision you hope to build. Yes, you still need to include the traditional components of the plan, but operating from the standpoint that you’re building a narrative will ensure you communicate the larger ethos of what you and your team are trying to do. And don’t be subtle about it. You need your roadmap to be able to stand alone. That way, when it inevitably gets forwarded or shared out of context it will still capture your vision and paint a clear picture of the future.
Make it audience-specific. The story you tell is equally as important as who you tell it to. When you share your roadmap, the call-outs that may be compelling to an executive stakeholder will be different from the snapshots you summarize for the sales team. Think big-picture versus granular, or internally-focused versus externally focused, etc. The bones of the story remain the same, but the level of detail you highlight should be different and better suited to unique audiences so each team hears the information most pertinent to them (and to getting buy-in on your roadmap!).
You don’t need a timeline, but you do need timing. This is a hot take because many product managers I know are firm believers that dates don’t belong on a roadmap. I love the spirit behind that idea, but I live in the real world where, the minute you communicate your roadmap, a hand shoots up and that person asks, “When will feature X be released?” This can be scary because the last thing you want to do is overpromise and underdeliver. My solution? Employ Janna Bastow’s Now/Next/Later model. “Now” includes the work that needs to happen in the next few weeks. “Next” covers priorities ranging from next month to a few quarters out. “Later” is a bit more broad and captures the work that you know needs to happen, but you aren’t sure when. Why do this? Because people are going to want you to get more specific about timing. You can either be dragged into the conversation, or you can be proactive. And being proactive offers an excellent starting place for the team to see some semblance of relational timeblocks and discuss what is and isn’t realistic. Plus, you can always add a disclaimer at the top that clearly states these are not promised release dates.
Prioritize the work to be done. This is where you’ll align Now/Next/Later against the strategy and desired outcomes, prioritizing the sequence of work that needs to happen. Think of it as a grid where Now/Next/Later lives on the vertical axis, and high-level line items supporting priorities live on the horizontal axis. And remember, it can all shift! The point is to start a conversation about what work needs to happen and when it needs to happen to move things along, meet deadlines, hit goals, align teams, and beyond.
Still sound nebulous? Here’s an example of how I tackle Now/Next/Later roadmaps to align the work against timing. Feel free to adapt my format for your own use!
As a parting gift, I’ll briefly share what I believe a product roadmap should not include:
Hard release dates. They do nothing but set your team up for disappointment. That’s why the Now/Next/Later model is a nice compromise: you can start having the conversation about timing without assigning arbitrary deadlines.
Granular details. The last thing you want is to weigh people down with minutia to the point that they don’t understand the strategic functionality of your product. This isn’t the place to enumerate the user stories or acceptance criteria for features. Get comfortable with grouping and theming.
Six-point font. If you need to use a magnifying glass to read your roadmap, you’re trying to cover too much. Either ease up on the granularity (see #2), or break the roadmap up into more discrete units of value to show how you intend to make progress against the desired outcomes
Send me a message if you think you’d add anything to this list. I’d love to hear your ideas!