Shifting focus from the how to the why by properly using a product roadmap.
Got to Part 2 of Product Roadmaps.
Got to Part 3 of Product Roadmaps.
Part 1…
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:

* What is and is not a product roadmap.
* Who it is for.
* The inputs needed to properly construct a roadmap.
* How to organize a roadmap.
* Ways to prioritize product features.

Summary of some concepts discussed for product managers
[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.