Getting started with roadmapping
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to roadmapping for teams who have not touched it before.
The projects that go badly are rarely the ones with the hardest technical problems. If it only works because one person remembers to do something, it does not work yet.
Why it matters
A roadmap is a statement of intent, not a promise. It is worth being explicit about, because assumptions differ quietly. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Your first week
- Find out what is already in place
- Sequence by value and dependency, not by loudest request
- Change one thing and measure it
Review it quarterly or it becomes fiction. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.
The short version
Clear scope protects the client at least as much as it protects the agency. 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
The point is not perfection, it is knowing which of these you have consciously chosen to skip.