A product roadmap is not just a chronological list of things that your team needs to do. According to Paul Adams at Intercom, it actually consists of a range of new work that needs to be prioritized according to data, user conversations, and intuition of the company.
There’s nothing like a competitor announcing a ground-breaking new product to scupper your own product roadmap. With executives getting antsy, it’s easy to be distracted and possibly even pushed in directions where you had no intention of going. Mike Belsito believes there are ways to keep on track and to maintain ownership of your roadmap by better knowing your customer and how you are positioned in relation to them. By being confident of your competitive advantage you’ll be less likely to make knee-jerk reactions and instead hold a steady course.
We know that there’s power in data. It’s our greatest weapon against random subjectivity from multiple stakeholders in a project. But where do you get this data? Michael Peach describes several places from where data can be sourced, including iterative experiments, user behavior, and business goals.
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.
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.
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 andnot just a list of specific features with dates in your 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 were used. From this, you can explore the why behind these questions and ultimately decide whether the features should be improved, ignored or even killed.