Roadmap

Origin & evolution

Roadmaps arrived in software from manufacturing and chip design, where a literal timeline of feature⭐FeatureProduct SpecificationA product capability or featureView reference → dates made sense because the work was predictable. Carried into software, that format hardened into the Gantt-style roadmap: a grid of features against quarters, read by everyone downstream as a promise. The features shipped on time and the business metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → moved the wrong way, which is the failure mode Mind the Product documents in its case against feature roadmaps.

Cagan's *Inspired* makes the same case from the team side: when a roadmap locks in features rather than problems, the product team is reduced to an implementation contractor, and the four discovery risks🎲RiskComplianceA risk to the product or businessView reference → — will customers buy it (value), can they use it (usability), can the team build it (feasibility), and does it work for the business (business viability) — go unexamined until it is too late to change course. By that reading, a feature roadmap does not just mislead stakeholders; it structurally prevents the team from doing the work that determines whether any given feature was worth building.

Two corrections reshaped the artefact. In 2012 Janna Bastow and Simon Cast sketched a lean alternative with renameable time-horizon columns, originally labelled Current, Near Term, Future; an early ProdPad customer relabelled them Now, Next, Later, and Bastow kept the rename as the default. The horizons carry an honest signal: Now is committed and specific, Later is a problem area still in discovery, and nobody reads a date into it.

The second correction came from *Product Roadmaps Relaunched* (Lombardo, McCarthy, Ryan, Connors, 2017), which put the theme at the centre. A theme is an area of work framed as a customer or business outcome🏆OutcomeStrategyA desired business or user outcomeView reference →, drawn from problems, needs🫀NeedUserA user need, pain, desire, or constraintView reference →, and objectives🏁ObjectiveStrategyA strategic goal (OKR)View reference →, and it is deliberately broader than any feature that might serve it. The authors' point is that a roadmap built from themes survives changes in solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →, because the team can swap features under a theme without rewriting the plan. The field has largely landed on outcome-and-theme roadmaps for external communication, while keeping feature detail in the backlog.

How it works in practice

A B2B analytics team replaces its quarterly feature grid with three horizons. Now holds one committed theme, "cut time-to-first-dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference →", with two features attached and a target of dropping median onboarding from 40 minutes to under 10. Next holds "trust the numbers", a validated problem area where the solution is still being shaped. Later holds "collaborate on findings", a theme backed by support tickets🆘Support TicketCustomer SuccessCustomer support request or issueView reference → but no committed approach.

When sales asks for a specific export format, the PM points at the roadmap. The format is a candidate solution under a Later theme, not a Now commitment, so the conversation moves to whether it serves the outcome, leaving the question of when it ships aside. Six weeks on, discovery shows the onboarding delay is mostly data-connection failures, so the team changes the features under the Now theme without touching the theme itself. The plan held; the solution moved.

Roadmap vs. its neighbours

• Backlog: a backlog is the prioritised, granular list of stories, tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, and bugs🐛BugProduct SpecificationA defect or unexpected behaviourView reference → the team pulls from sprint to sprint. A roadmap is the strategic, sparse view of direction over months or quarters. ProductPlan frames the split as the roadmap carrying the why and when for executives and customers, the backlog carrying the what and how for the delivery team.
• Release🚢ReleaseProduct SpecificationA shipped version of the productView reference → plan: a release plan commits to dates and scope for a specific ship. A roadmap can schedule releases, but its job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is direction across many releases, and a good roadmap survives a slipped release.
• Vision🔭VisionStrategyA long-term aspirational statement of the future stateView reference →: a vision is the fixed destination years out. A roadmap is the moving path toward it, rewritten as the team learns, and it answers "what next and why" where the vision answers "where in the end".

In the graph

In the Unified Product Graph, a roadmap sits in the Product & Delivery region as a container. It owns its entries through roadmap_contains_roadmap_itemRoadmapcontainsRoadmap Itemhierarchy, groups them by outcome through roadmap_categorised_by_theme, and ties to delivery through roadmap_schedules_releaseRoadmapschedulesReleasehierarchy. The theme edge is what keeps the artefact outcome-shaped: items cluster under a customer or business outcome, with the date demoted to a secondary detail, so the graph can show a roadmap that holds its direction even as the features beneath each theme are swapped out.