In a slightly revised version, roadmaps are also a great tool to communicate with customers and prospects. Often, this is referred to as a public roadmap — where public doesn’t mean Facebook or TikTok but instead refers to an audience that you have a business relationship with (say, with contracts or at least an NDA in place).
And there are a few pitfalls to observe:
You have to make sure that the objectives and expected timelines of that public roadmap are 100% consistent with the internal roadmap — everything else will bring you into deep trouble with over-commitments made to customers. We would argue that compared to the actual, internal roadmap, only 2 types of changes are allowed for the public roadmap:
You may need to rephrase the underlying objectives, to provide different arguments for the strategy than internally. Maybe you even have to come up with slightly different stories, say for customers in different industries or regions. Still, beware to talk about the same product outcomes that your team will be working on — just emphasize different benefits and use different language that is more appropriate for the audience.
Never add something just to please the customer, but in some cases, you may want to skip some aspects so as not to wake sleeping dogs. Maybe there is a technical challenge that you are working on that might frighten the customer away but you are confident to resolve it soon enough? Or some functional gap based on a silly RFP checklist that you are absolutely sure will never become effective? Then why worry the customer?
