Roadmapping

The most common, and most damaging, roadmap format is a simple table or Gantt-style chart listing specific features against specific calendar dates, often stretching six to twelve months into the future. This format feels reassuring to stakeholders in the moment it's presented — it looks precise, confident, and easy to plan around. It is also, in most real product organizations, close to fiction the moment it's published, for exactly the reasons established in Lesson 31: requirements clarify, priorities shift, and unexpected discoveries reshape plans as teams actually build and learn. A roadmap presented as a set of fixed promises will, with near certainty, be broken in some particulars — and every broken date quietly erodes trust in the PM who published it, even when the underlying reasons for the change were entirely sound.

This is not an argument against forward planning — stakeholders have a legitimate need for direction, and refusing to provide any (Lesson 31's Mistake 5) is its own failure. It is an argument for choosing a roadmap format whose structure matches the actual level of certainty available at each time horizon, rather than a format that manufactures false precision uniformly across the whole timeline.

A widely adopted alternative, popularized by Janna Bastow, organizes a roadmap into three horizons instead of fixed calendar dates:

The critical design principle is that specificity and confidence are meant to decrease as the horizon extends, and this is stated openly rather than hidden. "Now" items can be described with real feature-level detail, because they're already well-groomed (Lesson 34) and actively being built. "Later" items are deliberately described as problem areas or themes ("improving new-user onboarding," not "add a five-step interactive tutorial with X, Y, Z screens"), because committing to specific solutions that far out would misrepresent how much is actually known. This structure lets a PM be simultaneously honest and useful — precise where precision is earned, and appropriately vague where it isn't, rather than uniformly vague (unhelpful) or uniformly precise (dishonest).

A second, related distinction concerns what a roadmap's rows represent. A feature-based roadmap lists specific things to be built ("add SSO login," "redesign the search page"). An outcome-based roadmap lists problems to be solved or metrics to be moved ("reduce enterprise sales friction from authentication concerns," "improve search result relevance"), leaving the specific solution open, especially for items further out on the Now-Next-Later horizon.

In practice, most healthy roadmaps blend the two: feature-specific in the "Now" column, progressively more outcome-oriented moving into "Next" and "Later" — which is precisely the Now-Next-Later structure's underlying logic applied to content, not just to labeled time buckets.

It's worth being explicit about the altitude difference here, since new PMs sometimes collapse these into one artifact. A roadmap operates at the level of quarters-to-a-year, expressed as outcomes or themes with decreasing specificity; a Sprint Backlog (Lesson 32, Lesson 34) operates at the level of a single Sprint, expressed as specific, groomed, INVEST-compliant items. The relationship between them should flow in one clear direction: a roadmap's "Now" items should be traceable down into the current Sprint's actual work, and a Sprint Goal (Lesson 32) should be explainable in terms of which roadmap theme it serves. A roadmap that has no visible connection to what a team is actually sprinting on has become disconnected fiction; a Sprint Backlog with no visible connection to any roadmap theme has lost sight of its longer-horizon purpose.