Not having a roadmap is like off roading. You can certainly get somewhere but it may not be the most comfortable journey.
April 2017 update: my thoughts on roadmaps have changed – if you’re working in Agile, be sure to read Why Agile and roadmaps don’t mix.
Not every product needs a roadmap. They’re a lot of work to produce but are definitely appropriate for more mature products / organizations. Unless you’re pre-revenue and there entire company is sitting in the same room (as in, there’s no way you don’t know what the product team is working on), you probably need a roadmap to communicate:
Priorities
Your roadmap should be a reflection of the changes to your product that are most likely going to improve one (or more) of your KPIs, which define what success means for your product. (more on KPIs in this post). So the highest priority items on your roadmap are the ones that are expected to move the needle the furthest.
Timelines
When is that change gonna go live?! Timelines are also really important to your customers, whose businesses might depend on the timeline (maybe they need to integrate with your product and need to plan for that or are going to change a business process as a part of a change you are making).
Be careful in presenting these timelines. If you only did t-shirt sizing to estimate the timeline, your estimate might be off (especially towards the end of your roadmap). My recommendation is to remind the audience that these are estimates and that the accuracy of the roadmap should get better as epics come closer to starting. Also, as the timeline nears, don’t forget to be Agile and demo too customers often – wireframes, comps, half-built functionality, etc. That way you can get feedback and provide status updates on timing.
Even if you don’t have a roadmap, you should still have defined KPIs to measure the success of your product so that you can know whether your changes are meaningful.