Collaboration & Process › Estimation & Planning

Roadmap

A plan of what to build over the coming months.

A roadmap communicates intended product or platform outcomes over a future period and the reasoning behind their order. It helps teams and stakeholders coordinate, but it is not a guarantee that every item will ship on a fixed date.

A useful roadmap emphasizes problems and outcomes—for example, “make imports recoverable” before listing every implementation task. It should make dependencies, assumptions, and confidence visible. Dates may be appropriate for contractual or regulatory commitments, while other work may be better shown in broader time horizons or ordered themes.

Roadmaps become misleading when they are treated as immutable promises or packed with too many items. New evidence, incidents, and customer needs can change priorities. Update the plan transparently and explain which outcome moved and why. Keep detailed execution tracking in the team’s work system rather than maintaining duplicate task lists in a presentation.

Backend, frontend, and data engineers can identify platform work and sequencing that is invisible in a feature-only view. Product and leadership partners own prioritization decisions; engineering should make technical consequences clear. See milestone, OKRs, and prioritization frameworks.

Treat the plan as a decision aid, not a promise detached from its assumptions. Name who can change scope, what evidence would prompt a replan, and which risks need a separate owner. Backend developers can identify system dependencies, frontend developers can clarify user-facing acceptance, and data engineers can expose source, quality, and backfill uncertainty.

Update the assumptions when new evidence arrives, and tell affected partners which consequence changes rather than only changing a date.