The problem with roadmaps is that they look like plans. They have dates on them. They have features listed in order. They sit there on a board in a colour-coded timeline and everyone assumes you’re committed to delivering exactly that in exactly that sequence at exactly those times.
Roadmaps are not plans. A plan is a detailed document about how you’re going to execute something specific. A roadmap is a statement of intent. It’s saying “based on what we know right now, we intend to do these things in this order.” All of those assumptions can change, and if you’re building anything complex in the real world, they will.
But teams treat roadmaps like contracts. Features get built because they’re on the roadmap twelve months ago, not because they’re still the right thing to build. Customers get angry because you shipped something other than what was on the roadmap three months earlier. You get locked into decisions made during a planning cycle that’s ancient in product time.
The honest conversation is this: A roadmap is a communication tool, and what it’s actually communicating depends on the audience.
To your team, the roadmap is saying “here’s the direction we’re heading, here’s what matters to us right now, here’s where I think we should focus energy.” It’s giving engineering something to build. It’s giving design something to think about. It’s giving operations something to prepare for. It’s not saying “this is set in stone” or “we can’t change our minds.” It’s saying “unless something changes, this is what we’re betting on.”
To customers, the roadmap is partly communication and partly management of expectations. If you tell customers “we’re planning to build filters for instructor style,” you’re setting an expectation. If that changes — maybe you discover it’s not the right solution, maybe you find a different way to solve the underlying problem — you need to explain that. But “we’re planning” is different from “we’re committed.” The problem is that customers often hear commitment even if you say planning.
To investors or executives, the roadmap is partly vision and partly justification for resource allocation. It’s saying “we’re investing in this area because we think it matters.” It’s a way of saying we’ve thought about what’s important and why.
The mistake is when a team lets one of those conversations override the others. When you treat the roadmap as a binding contract to customers, you stop being able to respond to what you’re learning. When you treat it as flexible and vague, engineering doesn’t have enough clarity to build. When you treat it as a political statement to executives and then ignore the learning from users, you drift away from what actually matters.
I watched this play out badly in a learning system once. Senior leadership committed to a roadmap with “mobile app” in Q3 and Q4. This was supposed to be the huge differentiator, the thing we’d market heavily. Time came around, the mobile team reported that they’d learn during mobile app development that the mobile experience worked better as responsive web than native app. Built one way would take twice as long but would be more maintainable. Built the other way would ship faster but would feel a bit clunky.
Rather than have a conversation about which was right — what did users actually need, what was the actual constraint, what would we learn — the response was “it’s on the roadmap, build it.” So they built the mobile app version, it took twice as long, it wasn’t as good as the responsive web version would have been, and it was announced with fanfare and then almost nobody used it.
If the conversation had been “here’s what we learned, here are our options,” maybe they would have made a different choice. But the roadmap had become a commitment, not a direction.
The best roadmaps I’ve seen are the ones that are explicit about what changes. They don’t have dates; they have phases. “Now” is what we’re actively working on. “Next” is what we’re confident about and will start soon. “Later” is what we’re thinking about but haven’t committed to yet. Everything is subject to change, and the change isn’t hidden — it’s part of the process.
This only works if your team and your stakeholders trust that you’re making good calls about what changes and why. If you move something from “Next” to “Later,” people want to understand the reasoning. Did we learn something? Did a higher priority emerge? Did we try to build it and realise it’s more complex than we thought?
When you’re transparent about the reasoning, people can trust the process even if they’re disappointed about the change. When you’re not transparent, people assume you’re being arbitrary or political.
The other thing that helps is talking about roadmaps as a dialogue, not a broadcast. You share the roadmap and you invite questions. What’s driving the priority? Is that weighting correct from your perspective? What did we miss? You explain your thinking and you listen to theirs. The roadmap is a starting point for conversation, not the final answer.
This is particularly important with customers. You share the direction. You explain the thinking. You ask for input. And then you have some features or improvements that you’re working on that aren’t on the roadmap yet, because you’re still learning about what actually matters.
“Here’s what we’re planning based on what we know today. Here’s what we’re learning from users that might change this. Here’s what we’ve learned that’s changing this from last quarter.” That’s a roadmap conversation that people can work with.
The other honest thing: Roadmaps are partly about managing internal pressure. When there are seventeen things you could work on next and everyone has an opinion, the roadmap is the place where you make the judgment call. You need to be able to explain why you’re prioritising feature A over feature B. “Because the CEO wanted it” is not a good explanation. “Because 40% of our customers are asking for this and it solves a critical blocker in their workflow” is better. “Because we think this will unlock an entire new use case for the product” is solid.
But you also need to be honest that it’s a judgment call. Other people might weight the inputs differently. You might be wrong. The market might change. New information comes in and you adjust. The roadmap is the best guess you can make with the information you have right now.
If you build a roadmap and then stay married to it even as the world changes, you’re not being disciplined or strategic. You’re being stubborn. The best roadmaps are stable enough to give people direction but flexible enough to respond to reality.