A Roadmap Is a Portfolio of Bets, Not a List of Promises

I don’t like roadmaps that pretend every box has the same level of certainty.

Some work really is predictable. A known migration may have clear scope, a dependency list and a date that matters to another team.

Other work isn’t like that at all. I’ve managed roadmap items involving ML, robotics, integrations and new product concepts where the first milestone wasn’t “ship the feature.” It was more like, “find out whether this is worth building the way we currently imagine it.”

Putting both kinds of work on the same quarterly timeline without showing the difference creates fake precision.

Commitment and confidence aren’t the same thing

A team can be highly committed to solving a problem and still have low confidence in the solution. That’s normal, especially in 0-to-1 work.

If customers are struggling with onboarding, I may be confident the problem is real but unsure whether a guided setup flow, better diagnostics, a services intervention or a different integration strategy will actually fix it.

I don’t want the roadmap to force the team to pretend that uncertainty has already disappeared.

I’d rather write the item around the problem and the next evidence we need.

For example:

Reduce failed first-time integrations. Test whether automatic connection diagnostics remove the two most common setup failures showing up in support cases.

That’s concrete enough for engineering and design to work with, but it doesn’t turn the first idea into a permanent promise.

Some roadmap items are dates. Some are learning milestones.

A fixed customer commitment may need a real delivery date. No argument there.

An exploratory AI workflow may be better served by something like:

By the end of the month, determine whether pilot users can complete the workflow with acceptable accuracy and without adding operator time.

That’s still a commitment. It’s just a commitment to produce evidence rather than a commitment to a feature name.

I’ve found this useful whenever technical feasibility and product value are tangled together. A model can work technically and still fail the workflow. A feature can be popular in interviews and still add too much operational cost. An integration can look promising until you discover the customer can’t reliably provide the data it depends on.

Those aren’t planning failures. They’re things the plan needs to leave room to discover.

I protect the outcome more than the noun

Stakeholders naturally remember nouns: dashboard, API, PDF report, AI assistant.

The underlying need is usually closer to a verb: understand, reduce, detect, automate, decide.

If discovery shows that a Monday morning exception email solves the problem better than the “reporting dashboard” on the roadmap, I’d rather make that change than defend the original rectangle on the slide.

There are cases where the implementation really is the commitment. Compliance work, contractual deliverables and platform dependencies can be very specific. But when the goal is a product outcome, I want some room for the solution to get better as we learn.

For me, a roadmap is doing its job when I can look at an item and quickly answer three things: what are we trying to change, how confident are we in this approach, and what evidence would make us change direction?

That’s a lot more useful than a box with a quarter printed on it.