What a good data roadmap actually looks like

Most data roadmaps are wish lists

Twenty initiatives, no owners, no sequence, and a horizon of three years. It reads well in a steering committee and tells nobody what to do on Monday.

Three horizons, and nothing beyond twelve months

Now, zero to three months. Specific, funded, with a named owner. If you cannot say who is doing it this quarter, it is not in this column.

Next, three to nine months. Shaped but not scheduled. Enough detail to know the dependencies.

Later. A list of problems, not solutions. Writing solutions this far out commits you to an approach before you understand the problem.

Anything past twelve months is a strategy document, not a roadmap, and should be labelled as such.

Every item needs four fields

• The decision that gets better, in business language
• The owner, by name
• What it depends on
• How you will know it worked

Items that cannot fill all four are not ready, and that is useful information.

Sequence by dependency, not by enthusiasm

Forecasting cannot precede a trustworthy demand history. Governance work that nobody can see is easier to fund after one visible win. The order is usually forced more than people expect.

Revisit quarterly, in public

A roadmap that is not revised is being ignored. Reviewing it openly each quarter, including the things you dropped, is what keeps it a working document rather than a poster.