The Roadmap Is Not the Territory
How to structure your product roadmap for maximum impact
One of the biggest questions that product people face when it comes to roadmaps is which elements to include.
Roadmaps can vary significantly depending on the needs of the company and stage of the product, and they all have a different level of detail. I’ve seen roadmaps with a few high level bullet points per quarter and that’s it; and on the other end of the spectrum, a granular list of tasks and sub-tasks, descriptions, KPIs, labels and scoring mechanisms of all types, timelines, assignees, dependencies, and more.
The dichotomy between the two approaches begs the question: What’s the optimal level of detail for your product roadmap?
There’s no one-size-fits-all answer, and what I’m about to suggest is probably geared more toward startups than large corporations, but I’d like to offer a simple framework for thinking about it.
Abstraction as a feature
I think it’s useful to draw on the work of an American mathematician from the 1930s named Alfred Korzybski in which he talks about how the map is not the territory.
According to Korzybski in his book Science and Sanity, “A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”
Korzybsi is saying that no map can or should attempt to exactly replicate the territory it represents. Maps must be an abstraction of the territory to be useful.
One practical reason for this is that it would be very hard to use a map with a one mile to one mile scale. You’d need a pretty big map. Another reason is that humans have a hard time processing large amounts of information. The more details on a map, the harder it is to get from point A to point B.
In her fascinating essay What Makes a Map Good, Barbara Tversky discusses this concept in depth, saying that “the most useful maps distort what they depict and leave out tons of possible information”.
An example she gives is the London Tube map. It shows a simplified representation of the train lines with horizontal, vertical, and diagonal lines, together with little circles to indicate each stop.
The map completely distorts actual distance and direction for the sake of clarity. Commuters don’t need a geographically accurate depiction of the London Tube lines. They just need to know how to get from one station to another.
In other words, abstraction is a key feature of maps, not a bug.
Finding the right balance
Product roadmaps are similar to the maps that Korzybski and Tversky speak about, in that they need to communicate complex concepts at a glance and help people get from point A to point B. The difference is that the territory of a product roadmap is the product, so in addition to showing how it will evolve from today to tomorrow, you also need to communicate how everything ties in to your broader product and business strategy.
Too many details can make communication difficult. But how much abstraction is necessary, and can there be too much?
Too little information is also a problem. If your roadmap doesn’t communicate what you plan to do, why and when, you probably aren’t using the tool correctly. You need to strike the right balance.
How then do you utilize the principle of abstraction while at the same time, provide enough information to address the core questions your roadmap is meant to answer?
Turning theory into practice
For me, there are a few elements that every product roadmap should include. Without going into too much detail (see what I did there?) the essential ones are:
Goals: How the things you plan to do align with the broader business strategy. I personally like to use KPI categories such as acquisition, activation, retention, referral, revenue, but you can make your goals more specific as needed.
Initiatives: The main things you plan to work on. This can be new features or areas of the product to improve and similar to a theme or epic in terms of scope. Avoid using technical language or internal jargon. You want to describe your initiatives from the user’s perspective using simple terms that anyone could understand.
Timeline: An indication of when your initiatives will reach your customers. I recommend avoiding specific dates at this stage. It’s hard to estimate exact timing, and since projects often run late but never early, you’re just setting everyone up for disappointment. Instead, a good balance between pragmatism and accuracy is time buckets, laid out kanban style, with columns for “Next 30 Days”, “1–3 Months”, “3–6 Months”, and so on.
That’s it! You can include a lot more information inside each card such as links to research, rationales and prioritization frameworks, designs, metrics for success, etc. — all one click away — but the main view is your communication tool, your map, so keep it focused and easy to understand at a glance.
Good luck!
I hope this theoretical framework and practical example of how to structure a roadmap with just enough detail to maximize impact — and nothing more — will help you and your team navigate the complex territory of your product. Just remember that when it comes to roadmapping, less is usually more.
“That’s been one of my mantras — focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
— Steve Jobs
