How to talk about commitments, experiments, and open questions honestly, instead of pretending the future has already been figured out.
Imagine you tell your parents your weekend trip plan: "Saturday morning we see the museum, Saturday afternoon we hike, Sunday we visit grandma." It sounds solid. Except you haven't actually checked if the museum is even open, the hike depends on weather nobody can predict yet, and grandma hasn't confirmed. You didn't lie exactly — you just said it like it was all decided when really, only one part was.
When the museum turns out to be closed, it doesn't just mess up Saturday. It makes your parents trust your next plan a little less too, even if that one is solid. That's the real cost of a fake-certain plan: it's not just wrong once, it makes people doubt you the next time you sound sure.
A product roadmap has the exact same problem, and it happens all the time.
There are really three different situations hiding inside most roadmaps, and they get treated as if they're all the same:
Things that are actually decided. Like a train ticket you've already bought — it's happening, the date is set, you're not still thinking about it.
Things you're still testing. Like trying a new recipe before you serve it to guests — you have a plan, but you genuinely don't know yet if it'll turn out well.
Things you honestly don't know yet. Like not knowing if it'll rain next month — you can guess, but pretending you know for sure doesn't make it more true.
A roadmap that mixes all three together and presents them the same way — as if they're all just "coming soon" — is quietly lying, even when nobody meant to lie.
Nobody hides uncertainty because they're trying to trick anyone. It's usually simpler than that: saying "I'm not sure yet" feels weak, and saying "this will definitely happen by March" feels confident and in-control. So teams often round "we think, we're testing, we hope" up to "we will," because the second one is more comfortable to say out loud in a meeting.
The problem is, reality doesn't care how confident you sounded. When the untested thing doesn't work out, the gap between what was promised and what actually happened is exactly the same size — the only difference is whether people saw it coming or got blindsided.
The fix isn't complicated, it's just uncomfortable at first: label each thing on the roadmap for what it actually is. This one's locked in. This one's an experiment — it might not work, and that's fine, that's what testing means. This one's still an open question — we genuinely don't know yet, and pretending otherwise doesn't help anyone.
This feels riskier to say out loud, but it actually builds more trust over time, not less. People stop being surprised when an experiment doesn't pan out, because you told them upfront it might not. And when you do say something is fully committed, people believe you — because you've shown you don't say that about things you're actually unsure of.
A roadmap isn't a promise that the future is already figured out. It's a map of what's locked in, what's still being tried, and what nobody has answered yet. Hiding the third kind doesn't make a team look more in control — it just delays the moment everyone finds out the truth anyway, usually at a worse time than if you'd just said it upfront.