Roadmaps Are Where Exploration Goes to Die
Picture your company’s roadmap — or use this one as an example:
Now, add one change. Instead of tracking delivery status, every row is color-coded by how much the team actually knows.
Blue: scoped, estimated by the people building it, dependencies mapped, open questions answered.
Purple: directionally clear, but the team has real unknowns they haven’t worked through yet.
Gray: effectively a placeholder. The work behind it might be three months of discovery or a conversation that hasn’t started.
Now look at your roadmap and recolor it honestly.
Most roadmaps mix all three: blue bars that carried forward from last year, a band of purple where teams have direction but not answers, and gray rows where someone needed to fill a cell during planning. But nobody reading the roadmap downstream can tell which is which. The format doesn’t carry that information.
A roadmap is one of the few artifacts that travels the full organization. Product owns it. Engineering builds from it. Finance maps spend against it. Sales references it in client conversations. The board sees a version once a quarter.
Each audience reads the same document for a different reason, and every reason demands confidence. Finance needs numbers to plan against. Sales needs dates to sell against. The board needs evidence that tech investment reflects strategy. A document serving all those audiences can’t afford a row that says “we’re still figuring this out.”
Every row carries the same weight: a name, a resourcing estimate, a delivery quarter. Nobody chose that design flaw. It’s a consequence of what roadmaps are asked to do.
Nobody announces “we’re treating this open placeholder as a locked commitment.” The format does it automatically.
Exploration dies two ways on a roadmap. Work that isn’t ready to present as committed gets forced into that shape anyway: a rough guess becomes a headcount number becomes a delivery date. Or it never earns a spot at all, because the format has no way to represent “we need to figure this out before we can plan it.”
We had a home-grown internal application I’ll call CompanyLedger. It had been around for years, accumulating processes, workarounds and manual inputs. It ran on spreadsheet uploads, duct tape and people running scripts at 3am (yes, really). It had been flagged by our auditors, so the CEO and CFO both knew it was a liability. A scrum team was already automating some of the billing calculations. The project shot to the top of their roadmap.
Then annual planning asked for a resourcing estimate.
Nobody had mapped what CompanyLedger actually did end-to-end. Different teams had asked the application owner to accommodate their processes over the years, and nobody documented any of it. The only way to understand system behavior was to shoulder-surf as users performed their daily activities.
To estimate resources, you need scope. To know scope, you need to understand the current system. To understand the current system, you need discovery that hadn’t happened yet.
We made an estimate anyway. That’s how planning works.
We’d submitted our “I-think-this-will-be-4-ish-people-of-work” estimate. Now we had to pull the rest of the business case together for leadership. I asked the product manager and engineering manager a simple question: for the “Deprecate CompanyLedger” initiative, at what point will users be fully out of the current system?
They looked at each other, then back at me. They weren’t planning to turn off CompanyLedger. They had never intended to turn off CompanyLedger.
They were deprecating CompanyLedger’s billing module. That’s all they’d ever scoped.
But the roadmap said “Deprecate CompanyLedger.” Internal team shorthand came thisclose to being what the CEO would read. What the CFO would plan around. What the board would anchor on.
We caught it. Changed the name to “Deprecate CompanyLedger Billing.” A small fix, but a critical one. Without it, the roadmap would have told the organization a story that wasn’t true. Not because anyone was lying. Because nobody had stopped to check whether the words on the slide matched what the team was actually building.
But by the time we caught the scope problem, the resource commitment was already in. The rough estimate had already hardened into a headcount allocation.
This is where planning processes quietly do their damage. The estimate goes in as a rough guess. It comes back as four people on a roadmap with a delivery date. The format doesn’t distinguish between “we’ve sized this carefully” and “we threw a number in because the spreadsheet needed one.” Both look the same on the slide.
Where the roadmap worked: as a shared artifact that forced the conversation.
Where it failed: distinguishing between “we’ve scoped this” and “we’re still figuring this out.”
On that imaginary recolored roadmap, this row was deep gray from the start. The team knew it. Nobody reading the roadmap could see it.
CompanyLedger took the first path. It earned its roadmap slot by pretending to be concrete. The initiatives that take the second path never show up at all. They’re the discovery effort nobody funded, the investigation that couldn’t compete for a row because it didn’t have a delivery date to offer. You can’t recolor what isn’t on the board.
The instinct here is to fix the format. Add a confidence column. Build a discovery track. Create intake stages. Those aren’t wrong, but they only work if the organization actually believes that not knowing yet is a legitimate stage of work rather than a failure to plan.
Discovery isn’t delay. It’s where the organization figures out whether a bet is worth making, before committing resources and a delivery date to finding out the hard way. But most planning cultures treat uncertainty as a gap to be flattened. Leaders who surface unknowns get asked when they’ll have answers. Teams that flag open questions get told to come back when they have a plan. The incentive is to project confidence whether or not it’s earned. So the format stays flat, every row looks blue, and the organization loses track of where its own knowledge ends and its assumptions begin.
Roadmaps aren’t plans. They’re conversations. The useful ones make room for what the organization doesn’t know yet. The dangerous ones paper over it.
Next time you’re looking at your company’s roadmap, pick the row you’re least confident in. Ask the team behind it: what do you still need to learn before this estimate is real?
If they can answer that clearly, the row is honest. The team knows what they know and what they don’t.
If the question surprises them, the roadmap has already done its damage. A guess went in. A plan came out. And somewhere downstream, someone is building against it.