TLDR: from my perspective as a CTO-doing-product-manager-stuff, the key part of building a roadmap is not what the document says, but what I learn and the connections I make through building it and maintaining it. If I just throw a bunch of features in a planner with no clear alignment to the org’s goals and user needs, that’s not a roadmap, that’s a wishlist. I get confidence in our roadmap when at any given point, I can direct people to it and explain how the future we imagine links to the things in the document. From an engineering perspective, I always appreciated roadmaps when it was clear why something was in there, because it told me there was a plan and not just a bunch of unconnected things in a Trello board.
Roadmaps can be intimidating, both to read and of course to create. If they are good, they can be useful in helping stakeholders and users understand where a product is going and gaining alignment as it gets updated with collected inputs, but they often deviate not into a tool for clarity but one of pressure.
With pressure to deliver on made up deadlines come stressful release cycles, and with stressful release cycles come low quality features that get shipped just to get it done before the made up deadline.
After a while, so many things deviate slightly from the plan that nothing makes any sense. It’s no longer a matter of pushing a schedule by 3 days but one where plans for an entire quarter are delayed and inconsistent. As a team grows, this becomes an ever bigger problem; executives expect results consistent with the growth of the team, and the teams are now demanding a cleanup of all the mess they had to create to reach the deadlines that someone else imposed.
Roadmaps should be a guideline that invites conversation. I am not even sure they should exist beyond a quarter, except in very loose terms.
Roadmaps aren’t a collection of deadlines. When we place a deadline, it should matter. It should mean that is the absolute latest date in which we can deliver safely, not just that someone in the C suite will have a tantrum if it’s not done.
Roadmaps should not every detail, but should bring clarity to how things connect to each other. Details are best left to the moment when the teams will work on implementation, since that’s when you have the most information available to make those decisions. Roadmaps, I believe, should not be detailed lists of tickets that someone will code as they are.
Roadmaps should enable creativity. Teams should be given the freedom to explore solutions to a problem rather than being presented with the complete solution; it’s the people closer to the work who are often able to draw the correct implementation and cut the scope to deliver as much value as possible within a constraint.
Roadmaps should be a tool for clarity, which in turns enables autonomy and better decision making.
Reasonable roadmaps cannot be built in 30 minutes meetings in a vacuum.
Analyzing customer usage, insights, feedback. Talking with users, with support, with stakeholders. Figuring out what the space looks like outside your org. Figuring out if the current state aligns with the organization’s vision for the future. Understanding in detail the why. Comparing what would not get done if this other thing gets scheduled. Understanding the trade-offs and being able to explain them. This is hard to do if your product manager doesn’t have time to think. Give product teams space to think deeply, rather than just react.
In the end, it’s not so much the formal roadmap that matters in a very small team, but the process and learning that got it done.
Roadmaps are not just the what, but the why, when, and for whom.
@rowasc! 