A roadmap, in the sense most companies practice it, is a prioritized list of features and projects handed down to product teams — the artifact that most companies mistake for a Product Strategy.
A roadmap alone does not resolve prioritization conflicts inside a company: 'We don't have a prioritization problem. We have a lack of focus problem.' Only a real strategy — evidence-backed, sequenced, transparent about its reasoning — can adjudicate between competing priorities; a list of projects cannot, because everyone advocating for their item on the list already believes it's important. 'Every leader in the company thinks they know what's important. And none of them are wrong.'
Contrast with the Product Model (vs. Roadmap Model), where teams get problems, not lists.
Apply: Recognize that shipping a features-and-projects list is not the same as having a strategy, and does not by itself resolve conflicts over what matters most.
Per Leah Hickman: a roadmap that is just a list of ideas is harmless. The moment a date is attached to an idea, it stops being an idea and becomes a commitment, a promise, an expectation — made before discovery has validated anything. She has seen well-intended roadmaps destroy trust in a company because one stakeholder had a missed expectation or failed commitment.
Most roadmap items fail to achieve their intended outcome because they rest on unvalidated assumptions from people disconnected from the actual work. This is the core case for replacing the feature/date roadmap with Outcome-Based Roadmap Reframing, and for the family of failure modes in Roadmap Antipattern Taxonomy.
Some roadmaps are communicated in a simple three-tier format — "now, next, and later" — surfaced in "What Do Product Managers Do?" (children's-book reading) as the plain-language way PMs describe what's shipping soon versus further out. The format is explicitly caveated as provisional: "not everything happens as originally planned," reinforcing that the roadmap communicates the current best plan rather than a commitment — consistent with Roadmaps as False Control and Transitional Roadmap.
A simple framing for what a roadmap communicates: what the team will give the team now, next, and later. This is looser than a committed schedule — the same framing explicitly expects the plan to move, since 'not everything happens as originally planned.' That expectation of change is the counterpart to Product Backlog (Prioritized List with Deletion Discipline)'s deletion discipline: a roadmap that only ever adds and never reprioritizes as reality intervenes isn't actually functioning as now/next/later, it's a fixed list wearing a roadmap's name.