The Most Truthful Roadmaps Lack Detail
A good roadmap doesn't predict the future; it communicates direction, exposes uncertainty, and helps a team learn whether its outputs are actually producing the outcomes it wants.
A lot of roadmap conversations go wrong before anyone opens the roadmap.
Someone asks what the team is working on. Someone else answers with a feature, a platform, an API, a migration, a website, a dashboard, or a batch job. They want to the answer to sounds concrete. Detail gives people confidence. Someone else puts the answer on a slide. It gives leadership something to track. It gives the team something to estimate.
But there is a problem hiding inside that concreteness: None of those things tell you whether the work will matter.
An API might reduce integration time. Or it might become another dependency no one wants to use. Another add-to-cart button earlier in the funnel might increase conversion, or it might double the same friction in two places.
Outputs are necessary. Teams have to build things. But outputs do not guarantee effect.
People have a lot of trouble operating by this. It’s literally easier said than done.
Years ago, I gave a talk called “Outcome Roadmaps, MVPs, Oh My.” The argument was simple enough to fit on slides: outcomes are the effects we want our work to have; outputs are the things we produce. Increased conversion is an outcome. Decreased production cost is an outcome. Better user experience, faster time to market, higher uptime, lower support burden: those are outcomes. APIs, websites, platforms, features, services, and batch jobs are outputs.
Most organizations know this distinction intellectually. Most companies have some version of outcomes over outputs. The trouble starts when planning pressure shows up because under pressure, outputs always win. Outputs are easier to name, easier to sequence, easier to assign, and easier to report. “Profile pages in Q2” sounds more responsible than “increase credible professional connections by reducing first-session uncertainty.” The first sounds like a commitment. The second sounds like a belief that still has to be tested.
But product work is mostly made of beliefs that still have to be tested.
The common response is to make the roadmap more detailed. Add dates. Add milestones. Add feature names. Add dependencies. Add confidence by increasing specificity. That can be useful when the work is close, understood, and mostly execution risk. A team needs a backlog. Engineers need stories. Designers need constraints. Product managers need sequencing. Detailed outputs have their place.
The mistake is treating every time horizon like backlog work. A useful product planning stack has different levels of certainty. Vision explains why the work exists and may last for decades. Strategy explains how we believe we can realize that vision and may last for years. A roadmap describes the tactics and bets we believe will move the strategy forward over months. A backlog contains the near-term details needed to create outputs over weeks.
Those layers are not just a hierarchy of documents. They are a hierarchy of uncertainty. The further away the work is, the less truthful detail you have. If your roadmap looks equally precise six months out as it does two weeks out, something is probably being hidden. Either the team is pretending uncertainty is lower than it is, or the roadmap has become a list of desired outputs instead of a map of intended outcomes.
How do we know we are going to build the right thing?
We don’t.
That is why the most truthful roadmaps often look incomplete to people who want certainty from them. They show direction without pretending the future is known. They communicate what the team currently believes will matter. They name outcomes, metrics, and risks. They make uncertainty visible instead of burying it under feature detail. They create a feedback loop between what we build and what effect it has.
This is where MVPs fit, and where they are often misunderstood.
An MVP is not the smallest thing the team can ship while still satisfying the stakeholders. It is not a reduced-scope version of the original feature list. It is not the ugly first release everyone apologizes for. At its best, an MVP is a learning tool. It helps answer the question underneath the roadmap: how do we know we are going to build the right thing?
The honest answer is that we don’t.
We can have research, data, taste, experience, strong opinions, customer interviews, analytics, and a strategy that makes sense. We should use all of that. But none of it removes uncertainty. Product work is not made correct by confidence. It becomes more correct through feedback.
That feedback only works if the roadmap leaves room for learning.
When organizations skip the outcome layer, planning collapses into a strange shape. There is a vision at the top, a pile of features in the middle, and a backlog at the bottom. It looks practical because everyone can see work. But the connective tissue is missing. People do not share an understanding of the outcomes they are trying to create. They do not share an understanding of which problems matter, for whom, or why now. Communication gets expensive because every decision has to be re-litigated. Teams get lost in implementation detail. Duplicate efforts appear because groups are solving adjacent problems without realizing it. Worst of all, progress becomes harder to judge because the organization can see shipping but cannot see effect.
That is the feature factory trap, but it rarely feels like a trap from the inside. It feels like being responsible. It feels like honoring commitments. It feels like giving the business what it asked for.
A thoughtful person can object here. They might say, “The business needs dates. Sales needs to know what is coming. Customers need commitments. Finance needs planning inputs. Teams cannot operate on vibes and learning language.”
That objection is fair. Outcome orientation should not become a fog machine. A roadmap that refuses to say anything concrete is not mature; it is evasive. Teams still need commitments. Stakeholders still need clarity. The question is what kind of clarity is appropriate at each altitude.
For near-term work, clarity should look like executable detail. What are we building? Who owns it? What constraints matter? What is the acceptance bar? What needs to be true before we call it done?
For farther-out work, clarity should look different. What outcome are we pursuing? What metric would tell us we are making progress? What risks could invalidate this direction? What do we believe now, and how confident are we? What decision will we make once we learn more?
That is a more useful form of honesty. It separates confidence from theater.
A roadmap can say: current, near term, future. It can say: high confidence, medium confidence, low confidence. It can say: here are the outcomes we care about, here are the metrics we will watch, here are the risks we know about, and here are the bets we are considering. It can still include outputs, but the outputs sit underneath the outcome they are meant to influence. They do not replace it.
This changes the conversation.
Instead of asking, “Are we still shipping advanced matching in Q3?” the team can ask, “Is user growth still the outcome that matters most, and is advanced matching still our best bet?” Instead of arguing whether a feature is late, the team can ask whether the learning changed the path. Instead of treating roadmap change as failure, the organization can treat some change as evidence that the team is paying attention.
That last part matters because roadmaps have a trust problem.
Many teams have been punished for changing plans, even when the change was rational. So they learn to make roadmaps that look stable and then manage reality somewhere else. The published roadmap becomes a diplomatic artifact. The real roadmap lives in conversations, exceptions, side channels, and last-minute prioritization meetings.
An outcome roadmap should reduce that split. It should make the real conversation visible enough that people can participate in it.
There is a second-order effect here that is easy to miss. When roadmaps are output-heavy, learning becomes inconvenient. New information threatens the plan because the plan is defined by deliverables. When roadmaps are outcome-oriented, learning becomes part of the plan because the plan is defined by intended effect. The team still has to make hard calls, but it has a better language for making them.
This does not mean every roadmap item has to be abstract. It means every meaningful output should be traceable to an outcome. If no one can explain what effect a feature is supposed to create, the feature is not ready to be treated as important. It may be a good idea. It may even be the right idea. But it has not earned the confidence people are assigning to it.
A practical test I like is this:
If the roadmap item ships successfully and nothing changes for the user or business, would we still call it success?
If the answer is yes, you are probably managing outputs. If the answer is no or I don’t know, ask the next question: what change are we expecting, and how will we know?
That one question can improve the whole conversation. It forces the team to name the effect. It reveals whether metrics exist. It exposes assumptions. It helps separate “we need this because someone asked for it” from “we believe this will move an outcome we care about.” It also gives teams permission to change the output if they find a better way to create the same effect.
The roadmap’s job is not to make uncertainty disappear. Its job is to help people move through uncertainty together.
That means the most honest roadmap will always disappoint someone looking for a perfect prediction. It will have detail where the team has earned detail. It will have looser language where the team is still learning. It will show confidence levels instead of hiding them. It will connect vision to strategy, strategy to outcomes, outcomes to bets, bets to outputs, and outputs back to measured effect.
A roadmap should communicate the direction we plan to go. It should assume uncertainty and change. It should optimize for learning and response. And it should be oriented around outcomes, because shipping the thing was never the point.
The point was the effect the thing was supposed to have.