Main idea

A roadmap sets a direction, and that is its function. The same move produces a lock-in effect: once the places are allocated, a topic without one can no longer be handled, however obvious it is.

The topics lost to that lock-in have a consistent profile. They are small, very useful, much-awaited improvements whose value nobody disputes — but too small to deserve a roadmap place, or too opportunistic to wait for the next cycle. An imperfect text export that spares a customer from hunting for data across ten screens is one of them: it will never become a roadmap topic, and it saves several hours.

The flaw is therefore not a flaw of application — it is not fixed by holding the roadmap better. It is the exact reverse of what makes the roadmap useful, and it calls for a separate device rather than a loosening.

Why it matters

It prevents two equally bad reactions: adding an exceptions column, which undoes the constraint; or denying the problem, which leaves the team bypassing the roadmap on the quiet.

It also gives a fair reading of requests for exemption. They are not all attempts to jump the queue: some of them point precisely at what the format cannot handle.

Nuances and limits

The lock-in is not always a cost. In an organization that scatters, blocking small opportunities is exactly the intended effect, and the sacrifice is owned.

And the obviousness of the value, invoked to bypass the framework, is often an illusion: many "small obvious topics" are not, and the roadmap would have been right to discard them.

Open questions

• What share of a team's capacity can stay outside the roadmap before the stated direction becomes fiction?