Session note: why most roadmaps exist to reduce anxiety, not guide decisions

The Situation

You're asked for a roadmap. Leadership wants to see what you're building. Engineering wants to know what's coming. Sales wants to know what to sell. Everyone wants clarity, and a roadmap feels like the answer.

So you create a roadmap. Features, dates, priorities. It looks clear. It feels like progress. But when you actually try to use it to make decisions, it doesn't help. The dates are guesses. The priorities shift. The features change. The roadmap becomes obsolete faster than you can update it.

The roadmap exists, but it doesn't guide decisions. It exists to reduce anxiety—to show that you have a plan—not to actually help you decide what to build.

What Most Teams Try (and Why It Doesn't Work)

Most teams try to make roadmaps more accurate or more detailed. But this doesn't solve the real problem.

Making roadmaps more detailed

More detail doesn't make a roadmap more useful—it makes it more fragile. The more specific you get, the faster it becomes obsolete when things change.

Updating roadmaps more frequently

If you're updating the roadmap constantly, it's not guiding decisions—it's documenting what you already decided. You're spending time maintaining a document instead of making decisions.

Treating the roadmap as the deliverable

If the goal is to have a roadmap, you'll create one. But if the goal is to make better decisions, a roadmap might not be the right tool. The deliverable should be clarity, not a document.

How I Approach This in Practice

I create clarity that guides decisions, not roadmaps that document plans. The difference is focusing on what you need to decide, not what you plan to build.

Clarify constraints, not features

Instead of planning features, clarify constraints. What can't you change? What are you optimizing for? What are the non-negotiables? These constraints guide decisions even when specific features change.

Create decision frameworks, not timelines

Instead of planning when you'll build things, create frameworks for deciding what to build. When new information comes in, you use the framework to make a decision, not update a timeline.

Focus on near-term bets, not long-term plans

You can't plan six months out when things keep changing. But you can make clear bets about what you're learning in the next 90 days. Focus on near-term clarity, not long-term plans.

Use roadmaps to communicate, not to decide

Roadmaps can be useful for communicating direction, but they're not useful for making decisions. Use them to share what you're betting on, not to lock in what you'll build.

A Real Example

A growth-stage company that spent weeks creating a detailed six-month roadmap. It looked impressive. It had features, dates, priorities. But within a month, half the features were obsolete. Customer feedback changed priorities. Technical constraints emerged. The roadmap became a document they maintained but didn't use.

Instead of a roadmap, we created three things: constraints (what they couldn't change), near-term bets (what they were learning in the next 90 days), and a decision framework (how to evaluate new opportunities).

When priorities shifted, they didn't need to update the roadmap—they used the framework to make a new decision. The constraints stayed stable, but the specific features could change without breaking the strategy.

The outcome wasn't a stable roadmap—it was a stable way of making decisions. They still communicated direction, but the direction came from clarity, not a document.

When This Matters

Roadmaps help when:

• You're communicating direction, not making decisions. Roadmaps are useful for sharing what you're betting on, not for locking in what you'll build.
• Requirements are actually stable. If you know what you're building and why, a roadmap can help coordinate execution. But this is rare.
• You need to align stakeholders on priorities. A roadmap can help everyone see the same priorities, even if the specific features change.

Roadmaps hurt when:

• You're using them to make decisions. If you're looking at the roadmap to decide what to build, it's not helping. You need clarity, not a document.
• Requirements keep changing. If things change faster than you can update the roadmap, it becomes obsolete. Focus on decision frameworks instead.
• The roadmap exists to reduce anxiety. If you're creating a roadmap because people want to see a plan, that's fine—but don't confuse it with clarity. The roadmap is a comfort artifact, not a decision tool.