Roadmapping: the questions we get asked most

We end up explaining this on discovery calls often enough that it deserved writing down. The questions about roadmapping that come up most often on our calls.

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Do we need to care about this?

A roadmap is a statement of intent, not a promise. This is the sort of thing that compounds, quietly, in both directions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. In practice this is a scheduling problem more than a technical one.

How do we know it is working?

Review it quarterly or it becomes fiction. Getting it slightly wrong is survivable. Ignoring it entirely is not. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

The projects that go badly are rarely the ones with the hardest technical problems. 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 are not sure where your systems currently stand on this, it takes us about an hour to find out.