Roadmap

What it means

A roadmap states what will be built in a product or project and in what order. It is not a feature list: every item carries a reason, a benefit and an estimate comparable with its cost.

A good roadmap also says what will not be done. That decision is what stops a budget from scattering across ten things with none of them finished.

A roadmap is not a project schedule. A Gantt chart lays out tasks, dependencies and days, while a roadmap stays at the level of outcomes and order: what should be done in which period and why then. A detailed schedule is derived from it for the next stretch, not for years ahead.

How it works in practice

On bespoke development the roadmap pairs with the MVP: the first version tackles the most painful process and later steps follow what running it reveals.

Dates are estimates, not promises. So they are written in quarters or in sequence rather than days, and reviewed with stakeholders on a fixed cadence.

When we help a client digitise their accounting, we build the roadmap around where most time is lost: first the bank statement feed, then document digitisation and only at the end management reports. Each step pays off on its own, so the project can stop after any of them without money wasted.

What to watch out for

A roadmap with no owner and no numbers becomes a wish list. If an item cannot be given a person, a date and a benefit, it belongs in the idea backlog, not in the plan.

Another problem arises when an internal roadmap is shown to a customer or investor as a commitment. The estimate turns into a promise that ends up in a contract or a term sheet, and slipping a quarter then means not just a rewritten plan but a dispute over performance or a contractual penalty.