While there should be one ultimate source of truth for product planning, there may be several versions (editions) of roadmaps -- especially if we're in an enterprise market or long-sales-cycle situation. For instance, we might have:
-- a development-facing roadmap with our best estimates of what will really get built if we don't run into technical surprises (in other words, a slightly optimistic work plan for this quarter that includes tech debt and bug-fixing work that we don't normally announce externally)
-- a sales-facing / customer-facing roadmap which focuses on the top 2-4 new capabilities / features for the next two quarters (i.e. higher level, shifted slightly later based on delivery experience, tied to broader release trains)
-- a high-concept multi-year roadmap for customers, analysts and press that emphasizes long-term themes and investments (i.e. big picture, few details, giving us room as we further investigate market needs and define product concepts)
Customers (especially enterprises with huge investments in incumbent software vendors) understand that roadmaps are not precise, and are subject to change. That said, we should supply the right level of detail and (un)certainty for these different consuming audiences.
I know that some product teams completely externalize their entire roadmaps to users/customers, and may also have direct feature upvoting from users. IMO, this is most appropriate for single-user or small-team products with an enthusiastic community. At my end of the enterprise space, buying cycles are too complex (the split between users and choosers big enough) that I'd hesitate to apply a fully published model everywhere.
Great roadmapping tools would let us choose the right level of detail/specificity, and perhaps allow some general padding of dates, to reduce rework. (And avoid endless PowerPointing.)
I will echo Rich & Andrea in saying that sharing your roadmap is a good idea. You just have to have different roadmaps for different audiences.
I typically use a tool like Aha! or ProductPlan or just plain old PowerPoint to communicate at different levels:
- A Vision Roadmap for Analysts & Investors
- A Sales Roadmap for Customers & CABs
- The Product Steering Roadmap
The project management tool handles the short term stuff for sprints, so I just use that for team planning.
Having a roadmap offers a great opportunity to engage with customers, validate your direction, and get feedback. I usually put it into Power Point with fuzzy arrows, no deadlines, and some high level quarterly guidance. That usually works well enough without getting anyone into trouble. If people want to lay a trap for you, they will anyway, so don't let that keep you from talking to valuable customers and partners in the market.
One good tip: I always make this available to my Sales team. They'll get it one way or another. To get around the usual issues of someone going off the reservation, I promote Roadmap Reviews as a service of Product Management. We get the word out that we *want* to attend PBRs, status meetings, etc and give the roadmap overview. I also embed this guidance on the front page of the PowerPoint so no matter who gets a copy, they know to invite the PM.
There are plenty of blogs and advice out there to the contrary, but I find this works best for me in the B2B SaaS space.
Also, just for ideas on what to share, there are plenty of types of roadmaps. 280 Group has a great overview on the types of roadmaps here:
Also, these guys have some nice PPTs:
At first it may sound like a terribly uncomfortable idea from the outside to have your roadmap be public. But relax! You’re not handing the game over to our competitors. You’re not hurting your business.
I hate to break it to you - but unless your Apple or Samsung or some huge company that relies on super secret product launches, you’re probably going to be just fine.
Sharing our roadmap is a reasonable move that has brought us some pretty outsized results. And all from a doc we spent a few minutes filtering for the public before we hit publish. Worth it.
Contrary to what you might think, this simple act has brought us so much growth and customer insights that we would never consider taking it down.
Our product roadmap has actually become a central part of the way we communicate our priorities with our customers – and I’d love to see more companies taking the leap.
Our roadmap has kicked off conversations that have gone on to directly influence our product decisions. It’s an opportunity for our customers to tell us what they’d like to see. More importantly, it’s an opportunity for them to see what we’re up to without getting caught by surprise.
Even more important: Customers love the transparency
We’ve found that as long as we’re open and honest about our priorities, customers are actually very forgiving. We hold onto the feedback we get and reach back into it to guide the way we approach their problems – and our customers know that.
These conversations have helped us understand what resonates with people, and that helps us position our launches down the line.
We don’t bow to the pressure to make false promises. We don’t have a problem telling customers that something they’ve requested isn’t going to get built. We stick to our priorities (although we do shuffle them around as needed).
Since we’re all looking at the same roadmap, we’re all on the same page.
Have you thought about going public with yours?
Yes, we use a set of PowerPoint roadmap templates in my organization. These are for project roadmaps but could also be used for a product release.
Product roadmaps are a valuable tool for having conversations with customers. I have historically shared a high-level roadmap of the next 18-24 months worth of development, where the next 3-6 months are pretty much locked down, while anything beyond is subject to being moved around (forward in time, or backward in time). The only recommendation that I would make is that it is best if you have a habit of delivering on your roadmap engagements before sharing the roadmap. Otherwise you can get called to the carpet later on by a customer who notices that nothing got done since the last time they saw the roadmap.
I’m in the enterprise space, where sales and implementation cycles are pretty long. Usually what our customers or account executives mean when they ask for a “roadmap” is mostly an update on our product since they were last engaged, sometimes years prior. I also use roadmap discussions to do the judo move, where I get the customer to tell me about their roadmap and then explain our roadmap specifically in that context. Admittedly, this is high-touch, but it usually results in better alignment and expectation setting than a self-service document or list.