Three myths about roadmapping

The advice here is unglamorous, which is probably why it gets skipped. A few things about roadmapping that get repeated more often than they get checked.

The projects that go badly are rarely the ones with the hardest technical problems. Assume whoever inherits this will have half your context and none of your patience.

“It only matters for big sites”

A roadmap is a statement of intent, not a promise. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.

“We can deal with it after launch”

Sometimes true, usually expensive. There is a version of this that is over-engineered, and it is worth avoiding.

“Our platform handles it”

Review it quarterly or it becomes fiction. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about roadmapping before you move on:

• Someone can say what the current setup is without going to look
• Sequence by value and dependency, not by loudest request — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.