The Roadmap Problem No One Admits

March 15, 2026

A few weeks ago, I sat down with a founding team that felt something was off.

They weren’t stuck. Quite the opposite - they were moving fast. There was activity everywhere: features in progress, decisions being made, code being written.

But nothing seemed to land.

Features dragged. Decisions lingered. Shipping felt inconsistent.

“We’re slower than we should be,” one of them said.

From the outside, nothing obvious was broken. The team was strong. The product direction made sense. There was no chaos.

So I asked a simple question:

“What’s supposed to ship in the next two weeks?”

They started listing things - onboarding improvements, a new API direction, analytics, infrastructure cleanup.

It sounded like momentum.

Then I asked again:

“No - what is actually expected to be done?”

That’s when things got quiet.

The Illusion of Progress#

We pulled up their board. Nine active items.

At a glance, it looked healthy - work in motion, engineers engaged, no obvious bottlenecks.

But as we went through each item, a pattern emerged. The onboarding work was “almost there,” but still missing edge cases. The API effort was split between two directions, neither resolved. Analytics had backend work, but no usable surface. Infrastructure had been “improved,” but not stabilized.

Nothing was blocked. Nothing was abandoned.

But nothing was finished.

So I told them:

“You don’t have nine projects. You have zero.”

Individually, everything had progressed. Code existed. Effort was real.

But at the level that matters - what users experience, what the business can rely on - none of it existed yet.

This is the subtle failure mode where teams confuse motion with delivery. And once you fall into it, velocity starts to look intact while actually degrading underneath¹.

How Teams End Up Here#

This state rarely comes from bad decisions. It comes from non-decisions.

At some point, someone says: we should improve onboarding, we’ll probably need a better API here, can someone look into analytics, we should clean this up at some point.

These aren’t commitments. They’re signals.

But in small teams, signals are enough. Someone picks it up, starts exploring, opens a branch, pushes things forward.

Work begins.

But no one ever decides that it needs to end.

So it accumulates.

In practice, this is what “shipping in uncertainty” looks like when it’s unmanaged - continuous bets being placed, without a clear mechanism for deciding which ones actually need to resolve².

What This Does to Execution#

The cost isn’t obvious at first.

From the outside, the team looks productive. There are updates, pull requests, and visible movement across multiple fronts.

But internally, something breaks.

There’s no clear center of gravity. Engineers start their day without a single dominant objective. They move between tasks, resume half-finished work, and switch context as soon as friction appears.

Work stops converging.

Instead of pushing one thing to completion, the team advances several things slightly. You get a steady stream of partial progress - and almost no finished outcomes.

Over time, quality degrades. Not because people are careless, but because nothing stays in focus long enough to be done properly.

This is the inverse of what high-velocity teams optimize for. They don’t maximize activity - they maximize completed, shippable outcomes¹.

The Reset#

With this team, we did something simple - and uncomfortable.

We took every active item and asked a single question:

“Are we committed to finishing this in the next two weeks?”

Not whether it was important. Not whether it might matter later.

Only whether we were willing to finish it now.

If yes, it stayed.

If not, it stopped - completely. No background progress, no partial ownership, no “we’ll keep chipping away.”

This is the same discipline behind small bets and fast learning: forcing work into a form where it can actually resolve, instead of lingering indefinitely³.

Where It Gets Hard#

This is the point where most teams hesitate.

Every item comes with a justification. You’ve already invested time. It will likely matter soon. You’re close to something useful. Dropping it feels wasteful.

All of that is true. None of it is relevant.

The real question isn’t whether something is valuable - it’s whether you’re willing to delay everything else for it.

That’s what being on the roadmap actually means.

What Changed#

They ended up keeping three items. Everything else was paused.

At first, it felt slower. There were fewer updates, fewer parallel threads, less visible activity.

But within two weeks, the difference was obvious. One feature shipped cleanly, end-to-end. The API direction converged. Infrastructure issues were actually resolved.

Nothing about the team changed.

No new process. No new tools.

Just fewer things, taken seriously.

The Role of “No”#

Early-stage teams tend to avoid saying no. It feels like giving up optionality, like slowing down.

In reality, it’s the opposite.

Every “yes” adds surface area: more coordination, more dependencies, more decisions deferred into the future.

Without constraint, the system becomes harder to reason about - and eventually, harder to trust.

Saying “no” isn’t about rejecting ideas.

It’s about protecting the conditions required to finish them.

This is also why breaking work into smaller, committed slices matters. Without that discipline, you don’t just take on more work - you take on more unresolved risk⁴.

What a Roadmap Actually Represents#

Most teams treat the roadmap as a list of things they want to do.

In practice, it’s a list of trade-offs.

Every item carries an implicit statement:

This is more important than everything we are not doing right now.

If that trade-off isn’t explicit, the roadmap loses meaning.

Execution becomes reactive - driven by momentum, interruptions, and partially completed work.

A Simple Test#

If you want to know whether your roadmap is real, don’t look at priorities.

Look at what’s currently in progress.

For each item, ask:

“Are we committed to finishing this?”

If the answer isn’t clearly yes, you’re not prioritizing.

You’re accumulating.

Closing#

The teams that move fastest aren’t the ones that generate the most ideas.

They’re the ones willing to ignore most of them.

Because in practice, speed doesn’t come from doing more.

It comes from finishing what you start - and being deliberate about what you never start at all.

References#