Many years ago, when I was going off to start grad school, BW (at the time, she wasn’t BW, just B) and I rented a big yellow truck to haul all of our prized personal belongings to our new home (at least for the next two years). It was a long trip (2 days worth of driving), so we did the prudent traveler thing and went to AAA and got a bunch of maps to plan our route. The maps were not only for us, but others, too. Since this was the age before cell phone ubiquity, for safety reasons, we gave a copy to BW’s parents so that they would know what route we were following in case we didn’t show up at our destination or check in periodically.
Fortunately, we made it to our destination safe and sound, but the route we traveled was not nearly as straight and seamless as our map had portrayed. There were junctions that were a bit more complex than the little dot on the map where the two roads crossed. There were single-lane highways where freeways were listed. And don’t get me started on the exit numbering and seemingly endless number of construction (and some bio) detours that took place during our drive.
What we had to do was adapt our plan. We made decisions based on the best information we had. We tried some things that ended up not working. We asked for help from other travelers and some locals. Product Managers need to follow the same process with their Product Roadmap.
The Product Roadmap is a key tool for Product Managers to identify and manage their product’s growth, but don’t fool yourself into thinking that once you have your product mapped out for the next 6-60 months and rubber-stamped by the executive team that it’s all going to proceed according to plan. In fact, I can guarantee you that it won’t.
Now that’s not a bad thing. You have to view the Product Roadmap as a fluid plan that guides you along a path, but there are no fences or guardrails. You can veer off of the path, take a turn at a crossroad, or turn around. You may even find that you abandon the Product Roadmap for an entirely new one.
Many Product Managers view their Product Roadmap as highly confidential, even within their own companies and organizations. While some discretion needs to be used when discussing product plans and strategy, it is a mistake to not share details from the Product Roadmap both internally and externally. The Product Manager has to be the evangelist for their product and part fulfilling that role is to let people know where you are AND where you are going. I try to give a Product Roadmap update internally every 4-5 months to keep everyone up-to-date on our strategy and progress. I will also discuss the Product Roadmap when I do new hire training, but since they are typically being overloaded with data, I keep it at the 50k foot view.
Most software companies where I have worked maintain at least a 12 month Product Roadmap, with 3-6 months locked down either through commitments or by being in development. It is relatively easy to talk about the part that is locked down (at lease internally or with an NDA in place). It gets more complicated when you are talking to a customer or prospect (or reporter or analyst) about features or new products that are still in the idea phase or which have not been fully committed to. And while these may be the exact reasons that you are disclosing the Product Roadmap to them, you have to be careful about what level of detail you are disclosing.
Whether I am talking to customers and prospects or a general audience at my company, I usually don’t show them the same level of detail that I use when doing my product planning. There are several reasons for that:
-
Too much detail clouds the view
-
Some of the information is customer-specific
-
Some of the information is strategically sensitive
-
Less detail provides the opportunity for the audience to ask questions, which provides insight into what is important to them
-
If for some reason the information is released into the wild, it doesn’t pose as much of a trade secrets/strategy issue
When talking about future products and features, make sure that you set the expectations of the audience appropriately. Identify the difference between what is scheduled and what is planned. Also illustrate where dates are specific (“Our GA date for that release is XX-XX-20XX.”) and where they are guidelines. I usually communicate an exact date or sometimes a month when I am committing to a date, but only quarterly or seasonal windows (3Q2010 or Summer 2008). This gives the audience a sense of when something is prioritized, but gives you the flexibility to modify both the scale, scope and timing of release.
Product Roadmaps are a great tool for the Product Manager, but it’s also useful for those outside of Product Management. Just be careful about what you show and how you present it. Otherwise, you may find yourself having unpleasant conversations with internal and external stakeholders who saw something on the Product Roadmap and considered it gospel.