#pm_library: “Product Roadmaps Relaunched”

Today in #pm_library about product roadmaps after reading “Product Roadmaps Relaunched” by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors.

Let’s start with the fact that I don’t like product roadmaps. In my opinion, they do more harm than good. Why?

• Remorse for the roadmap changes. It’s a matter of our psyche. Constantly changing a written-out arrangement is bad for the well-being of the team and the rest of the company. In theory, we all know that a roadmap is just a sequence of events that can change. Even if we are very assertive, such a written roadmap will push us to implement the things written there rather than those that are now most needed by users and businesses. The lack of a roadmap means you can focus on solving the most critical problems here and now without explaining your decisions to yourself and others.
• The addiction to features that don’t exist yet. The risk applies to b2b products. Sales teams treat the roadmap as a bargaining chip in negotiations with customers. Any changes in the roadmap spoil the relationship between the company’s departments and customers.
• Bureaucracy. The roadmap is another place that a product manager must remember and update.

Working without roadmaps in actual product-led growth organizations is possible and helps to achieve success. I experienced this while working in Docplanner.

However, working without roadmaps might be risky in some organizations. Let’s take as an example company where I’m currently working. In Displate, in addition to digital products, we also deal with (incredible) physical products, which have a much less agile development process. Also, we need to coordinate projects to prepare for the new season.

And because of starting work as a Product Manager at Displate, I reached for the book “Product relaunched.” I did this hoping to get to like roadmaps a bit more. What did I take away from this book?

• One valuable phrase I use when talking to other company departments: “Roadmap is not a release plan.” Thanks to it, you can explain that the dates entered in the roadmap are very conventional, fluid,
• Treat the roadmap as a communication tool to help you explain to other company departments (and stakeholders) your product vision.
• Shuttle diplomacy. Invite stakeholders, leadership, and your team to build a roadmap together. Listen carefully to their opinions and ideas. Such an approach will ensure better understanding and support for your initiatives.

That’s all I learned from this book. The book had more general product management advice than just a roadmap. So overall, I was disappointed. Even if the book didn’t provide exact techniques for managing roadmaps, it gave you a different perspective.

All in all, I still don’t love roadmaps and would prefer to work without them. Every day, however, I feel more comfortable with them, learn how to create them, and use them to communicate better with other teams.

Can you recommend any other books or podcasts on this topic? What is your attitude towards product roadmaps?