What is a roadmap?

A roadmap answers one question: where is this product going? It is the map of the major stages, in order and with approximate horizons — we are working on this now, that comes next, the other one later. The difference from a classic project plan is one of nature rather than detail: a plan promises deliverables on dates, while a roadmap communicates direction and priorities. The mature industry format says so explicitly, using Now, Next and Later columns instead of quarters with dates, because certainty honestly decreases with distance and priorities rearrange themselves as the market teaches everybody something. The document matters in three situations. When buying software, a vendor’s public roadmap is a test of vitality and alignment — a product evolving toward your needs versus one that stagnates or invests in a different market — and a critical feature described as on the roadmap means maybe, so purchase decisions rest on what exists today. When commissioning development, the roadmap of your own product is how you steer the investment without drowning in detail: you decide the business priorities and the reasoning behind them, and the supplier translates them into stages. The healthy version stays alive, revised at every major stage rather than framed at signature, and ties each item to a business outcome instead of to a feature name.