← Back

When your roadmap becomes an excuse

I told a team member no last week. Not no in the polite “let me get back to you” way. No in the “that’s not on the roadmap” way.

The request was smart. Fast-moving market, customer signal was strong, the work would have shipped in two weeks. Everything pointed to doing it. Except the roadmap said Q4.

So we didn’t.

Two days later, the market moved. Not in the way we’d planned. In a way that made our Q4 plan look like it was built by someone who wasn’t paying attention. And now we’re building it anyway, except we’re five weeks behind where we’d have been if we’d just moved when we had the signal.

I’ve been thinking about why that felt easier than actually moving.

The roadmap as permission

Here’s what I realized: a roadmap isn’t a plan. It’s permission to say no.

This sounds smart. You can’t do everything. You have to prioritize. If you don’t have a plan, you’re just reacting to every signal. That’s chaos. So you build a roadmap, and it becomes the thing you point to when someone asks for something that doesn’t fit.

The roadmap gives you cover.

And cover is intoxicating. Because the real work isn’t building the roadmap. It’s making the decisions that come after. Every week, signals arrive. Some of them contradict the plan. And every time they do, you have to decide: is this a signal I should trust, or is this noise that I should ignore because I already planned Q4?

Most teams default to the plan. Because the plan is already made. The decision is already behind you. Deciding to ignore the signal is easy — you already decided when you built the roadmap.

Actually responding to the signal? That requires deciding again.

The cost of a plan that stops thinking

Here’s the part that kills execution: the moment you build a roadmap, most teams stop asking if the roadmap is right.

You ask during planning. You debate, you argue, you build consensus. Then you lock it. And for the next three months, the roadmap isn’t a guide — it’s a cage. Every decision gets filtered through “is this on the roadmap?” instead of “is this the right move?”

I’ve watched this kill signals so good they were practically screaming.

A customer tells you they’d pay 40% more for a specific feature. That’s not noise. But if it’s not on the roadmap, most teams will file it for “future consideration” and keep building what was planned. Then they hit their revenue target and are confused why they’re not hitting growth targets.

A metric tanks that you didn’t expect to track. A channel you weren’t focusing on starts performing better than the one you invested in. A team member figures out a way to deliver something you thought was impossible.

All of these are signals. All of them mean the roadmap is stale. But a stale roadmap is comfortable. It means you don’t have to decide again.

What happens when you defend the plan instead of the decision

The really weird part is how normal this feels. You’re not lazily ignoring signals — you’re disciplined. You’re sticking to your plan. You’re being responsible.

Except responsibility isn’t about keeping a plan. It’s about keeping your customers and your business in motion. And if the plan stops you from doing that, the plan is the problem, not the signal.

I’ve done this every way: I’ve ignored signals because “we’re locked in until Q4.” I’ve added them to a backlog I’ll look at eventually. I’ve scheduled a review meeting to discuss whether we should deviate. All of it amounts to the same thing: I’m defending the plan instead of defending the work.

The worst part is that it feels thorough. You’re not making a rash decision. You’re evaluating it systematically. You’re getting input. You’re being measured and careful.

Then Q4 arrives and you realize you were careful about the wrong thing.

How fast movers actually use plans

I’ve noticed that the teams that move fastest don’t have better roadmaps. They have lighter roadmaps. They plan three months out, and they plan loosely. Because they know that the real decisions are going to come from signals they can’t predict.

The roadmap tells them what they think is important. The signals tell them what’s actually important. And the teams that move fast are the ones who are willing to update what’s important when the signals disagree.

This doesn’t mean they scrap the plan every week. It means they hold it loosely. “We planned Q4 to be X. But signal arrived that suggests Y is more urgent. Should we move Y forward and push X back? Or do we have a specific reason to keep the plan as-is?”

That’s a decision. An actual one, made with new information.

It’s not “is this on the roadmap?” It’s “should the roadmap change?”

The permission I had but didn’t take

The thing that bothers me is that I had all the information I needed to move. The customer signal was clear. The work was scoped. The team was ready. The only thing stopping us was the plan.

And I chose the plan.

Not because I thought the plan was better. But because moving would require me to decide. Sticking with the plan meant the decision was already behind me.

This is the trap: plans feel like they reduce decisions. They don’t. They just defer them. You make the big decision once (build the roadmap), and then you make dozens of small decisions (ignore or accept each signal) without admitting that’s what you’re doing.

The cumulative result is that you end up defending a plan you wouldn’t make if you were making it today.

What I’m learning about planning

I still think plans are useful. You need to know roughly where you’re heading. But the plan isn’t a cage. It’s a statement about what you think now. It’s not permission to stop thinking.

The way you know a plan is working is if it still makes sense when new information arrives. If every signal is noise and the plan is right, you’re either incredibly prescient or you’re not paying attention to the signals.

I’m almost never incredibly prescient.

So these days I’m trying something different. I plan what I think should happen. And then I set a rhythm: every two weeks, is the plan still right? Not “are we on plan?” but “if we were planning today, would we plan the same thing?”

If the answer is yes, we stick with it. If the answer is no, we don’t defend the old decision. We make a new one.

It’s slower than just trusting the plan. But it’s faster than ignoring signals until they become crises.

And the next time a smart idea arrives that’s not on the roadmap, I’m going to decide. Not hide behind the plan.

The decision might be no. But it won’t be because the plan said so.

It’ll be because I decided.