Before you plan your product roadmap. Do a feature audit. This process, as described by Des Traynor, is crucial before you decide what you are going to work on. You need to know which of your existing features are being used, how they are being used and how often they being used. From this, you can explore the why behind these questions and ultimately decide whether the features should be improved, ignored or even killed.
10 tips for creating an agile product roadmap. There is a bevy of tools and frameworks out there that you can use to structure a roadmap. Roman Pichler has provided one he calls the Go Product Roadmap. Whether you use it or not, his 10 tips are valid, including focusing on themes and not just a list of specific features with dates in your roadmap.
How to build a product roadmap that everyone understands. Andrea Saez agrees with Roman (and many others by the way) that roadmaps should be theme-based. Along with giving you a look at what their roadmap looks like, Andrea underlines how a roadmap should be easy to consume and be able to communicate high-level priorities to everyone from the CEO to intern.
Don’t publish a product roadmap. Another question is whether it is wise or not to publish your roadmap publicly. Or even if you should talk specifically with your customers about items that your team is intending to work on. Colin Rand warns you not to do that. If you are late in delivering it’s going to be a disappointment for your customer. But there is a worse outcome — your solution will be underwhelming compared to the one your customer daydreamed about — the best possible solution for their situation.
