Most Product Roadmaps are Rubbish
Several years ago I was working as the VP of Product at an early-stage startup. When I joined we had a relatively mature product and several new ones in development. One of my first tasks was to review and update the product roadmap. This was a daunting task, given the complexity of the product and the vision of the founder. I remember the process of pouring through technical documentation and the product backlog. I spent hours talking with stakeholders and sales people trying to figure out what commitments had been made and when they were expected. The revised roadmap was a compromise that had to balance previously set expectations with the current market reality.
I remember how disappointed I was by that roadmap. Ultimately my hands were tied because the product vision (and how we planned on getting there) had been miscommunicated many times over. Once the information is out there, it can be very difficult to take back. Over my career I have seen and created more product roadmaps than I care to remember. Below are a few things I've learned about roadmaps and how you might be able to avoid these common mistakes.
Roadmaps are for long term vision, not short-term priorities
Roadmaps are not product backlogs. A roadmap should clearly communicate the long term vision of the product, not just provide a list of prioritized feature ideas. Having a clear vision of your product is helpful in aligning team members towards a common goal. Even in an agile environment, sprints should be linked to a clear objective, which keeps teams focused on the bigger picture. Sometimes short-term priorities require project work that doesn't quite align with product vision. This happens all the time, and in my experience, it's best to leave these off the roadmap as not to muddy the waters and create confusion.
Roadmapping is a process, not a deliverable
Roadmaps should be living documents, always changing to account for current market conditions. Most roadmaps that plan longer than six months should be written in pencil. The Internet moves too fast to think more than a few months ahead when it comes to required features and competitor/market analysis. The long term vision for your product may stay the same, but how you get to that vision will almost certainly need to change as you iterate. Which leads to the problem that...
Roadmaps create arbitrary promises for unproven features
Feature planning too far into the future generally assumes two things: you already know what your users want AND every feature you build will be successful. YOU may not assume these things, but stakeholders most likely will. Even if you've done customer interviews and prototyped features with user groups, something will need to change. If you subscribe to the lean startup methodology and are practicing validated learning, then you should be testing features and making tweaks based on customer feedback. So what happens when you learn that Feature X isn't providing the value you thought it would? Or Feature Y no longer makes sense to build? Has the CEO already promised these features to investors and the board? Have salespeople promised it to customers and prospects? You might be completely justified in your decision, but the optics aren't good when you start breaking promises.
Roadmaps are a necessary tool for most software product companies. Without them, it would be difficult to articulate the product vision, align team priorities, and set proper milestones. However, for as much good as they can bring, poorly written roadmaps that over promise and ignore market feedback will ultimately set your entire team up for failure.