Stop Presenting Roadmaps
Every roadmap ends up in fifteen versions because it carries information, not knowledge. Here are five things that work instead.
I hate roadmaps. That needs qualifying before every product person I know closes the tab (even if secretly agreeing): as a private thinking tool, a roadmap is fine. What I hate is the roadmap as an alignment mechanism, the artefact you present outward, and I hate it for a specific, structural reason. My articulation of that reason has got better every time I have had to talk to someone about a “roadmap”.
Here is the symptom, and you’ll recognise it too. Every roadmap I ever presented ended up existing in an increasing number of formats and versions. The board got one, sales another, engineering a third, customers a fourth, and each edit was an attempt to inject the context the artefact itself couldn’t carry. Each version drifted a little further from the others, until the roadmap wasn’t a shared plan at all but a family of loosely related documents that meant different things to different people.
Yesterday whilst scrolling LinkedIn, I found the most definitive language for why, in an unexpected place (for me, though on reflection a very obvious place): Dave Snowden, who you likely know because of the Cynefin framework, revisiting a knowledge management chapter he wrote in 1998. It is a series: the first post takes apart the models the field built itself on, and the second post, which is the one I read yesterday, is the one my piece here leans on. Two ideas in it explain the roadmap problem completely, and they point at what actually works instead. I’m always thankful for the deep work and research Dave and others do that help me better articulate “why” on topics such as this.
A map only works if you already know the territory
My take is that Snowden’s story distinguishes information from knowledge using a map and a guide.
A map is organised information: useful, portable, safe.
A guide is knowledge. They don’t consult the map; they read the terrain live, adjusts for what happened yesterday, and gets you there faster, provided you trust them.
And here is the line that I think matters: a map is only information to someone who shares the map-maker’s context. Hand it to someone with a different background and it degrades into data, marks on paper without the context that made it legible.
That is precisely what happens to a roadmap the moment it leaves your laptop. To you (and me), the author, it is dense with meaning. Every line item carries the user conversations, the trade-offs, years of experience, the bets you almost made instead, the months of market research, customer immersion and more ambiguously, the stuff you just know to be true. To everyone else it is marks on paper. They read it through their own context, which is different from yours, and each audience reconstructs a different roadmap from the same slide. Creating fifteen versions are not a discipline failure. They are the inevitable result of trying to move knowledge by shipping an artefact that can only carry information. How many times when presenting have you found yourself saying a version of “...obviously there is so much more context I’d like to share”?
Can versus should
The second idea is obvious when you read it, but one you likely don’t act on enough, or at all. I know I didn’t, but I will consciously try to more now. Snowden argues that turning tacit knowledge into an explicit artefact involves two separate judgements that almost everyone collapses into one.
First: can this be written down? Usually yes.
Second, and separately: should it be?
His decision rule: the more uncertain and fast-moving the environment, the more the knowledge should stay tacit, held in people and conversation rather than frozen into a document. Writing it down is not free. He led with the quote “Old wine does not set easily in new wineskins”: decant knowledge into an artefact and you don’t get the same thing back.
Now think about what a roadmap is in a company still finding product-market fit. It is the most uncertain, fastest-moving knowledge in the building, the emerging strategy itself, decanted into a rigid artefact and distributed to people who lack the context to rehydrate it. It is wrong by the time it is approved. We keep asking whether we can write the strategy down. We rarely ask whether we should.
Format infers certainty
Most product leaders will already be reaching for a rebuttal: this is exactly why we moved away from dated Gantt charts. To Now/Next/Later. To themes. To outcome-driven roadmaps. That instinct is right, as far as it goes. Read the history of roadmap formats and you are watching a profession slowly back away from false precision. Each format is, in effect, a claim about how much you know.
A dated timeline makes the strongest claim: we know what we will build and when. Sometimes that claim is honest. A compliance deadline, a contractual integration, a platform migration with fixed dependencies: the knowledge is stable, so the artefact holds, and dates are exactly what stakeholders should get. Not that they necessarily will, once you get into delivery and start hearing about the cone of uncertainty and best endeavours. And let’s not get started on point-sizing estimates. This for me is still the most damaging roadmap to agree to present, even if people think they want this (false) certainty. I get that planning has to happen; launches, customer commitments, cross-business coordination and so on. But that for me is a different conversation.
Now/Next/Later makes a weaker claim: we know the rough order, and our certainty decays with distance. It fixes the false-precision problem. It does not fix the context problem. “Next” still means different things to sales and to engineering, and the items on the list are still solutions that someone decided on somewhere else, for reasons the reader cannot see.
Outcome-driven roadmaps make a different move. Instead of shipping a solution list, they ship intent and delegate the how to the team. But they carry a dependency nobody talks about: the team needs enough context to interpret the outcome well. Hand an outcome statement to a team without that context and you have simply drawn a smaller map with the same problem.
So the question is not which format is best. The question is whether the format’s claim matches what you actually know. Trouble starts when it overstates: dates on discovery work, a committed solution list in a market that moves in weeks. And before product-market fit, even the outcomes are provisional, which is the point where no format saves you, because the constraint was never the format. It was the missing shared context.
Audiences that genuinely need a map
There is a hole in the argument so far, and anyone who has sat on the commercial side of the table has already spotted it. Everything above treats the roadmap as an internal alignment tool. But much of the demand for one comes from outside the building: the enterprise prospect who won’t sign without seeing the capability they (think they) need on a timeline, the CEO/founder mid-raise who needs a slide showing eighteen months of intent, the board that has to govern a company it doesn’t attend daily.
These audiences are not naive, and it took a board member to teach me this properly. He told me he has never once believed a two-year plan. He asks for one anyway, because for him the plan is the instrument and the deviation is the information. A board can’t sit in the daily conversations, so it governs by watching leadership articulate a theory of the future and then explain the variance against it. For that job, the artefact being wrong is not its failure. Its wrongness, tracked honestly over time, is what makes it useful.
Sales is similar in kind if not in sophistication. A prospect asking for a date isn’t asking to see your strategy; they’re asking for a commitment they can plan their own business around. That is a contract question, not an alignment question, and it deserves a contract-quality answer on the narrow thing they need, not a tour of your thinking.
So the resolution is not “no maps”. It is: know which job the artefact is doing. For outsiders, a roadmap is a communication device drawn on purpose: scoped to the commitments you can honestly make, labelled with the confidence behind each item, dates only where the knowledge is stable, direction where it isn’t. For insiders, it’s supposed to be an alignment mechanism, and that is the job it structurally cannot do, for all the reasons above.
Seen this way, the fifteen versions weren’t wrong because they were plural. Tailoring a message to its audience is just communication. They were wrong because they were accidental: each drifting from the others with no shared understanding underneath. Two deliberate maps drawn from one well-understood strategy is healthy. Fifteen accidental ones drawn from a document nobody shares an understanding of is most definitely unhealthy.
What to try instead
Hating roadmaps is easy to do and slightly tongue-in-cheek, although I do genuinely have a (learnt) hatred for them. So let’s name the alternatives and be precise about why each one works. None of them are new, by the way: Marty Cagan has argued the outcomes case for years, Shape Up was published in 2019, and #NoRoadmaps was a conference staple before that. What the article from Snowden adds for me is the why underneath all of them, and a rule for choosing between them. Every alternative below works for the same underlying reason: instead of shipping a map, it either builds the context that makes maps readable, or it keeps the volatile knowledge with the people doing the work.
A strategy you repeat until you are bored of it. The first alternative is not a document at all. It is a clear vision and strategy, communicated relentlessly: in kickoffs, in reviews, in one-to-ones, in the answer to every “why are we doing this.” It works because repetition transfers context, and context is what turns any subsequent artefact from data into information. The test of whether it has landed is not whether people have read the strategy doc. It is whether they can make the call you would make, without asking you. I’ve said this before, and it is where I personally spend significant effort as a product leader.
Outcome-based objectives, given to teams that hold the context. Give teams problems and intended outcomes, not feature lists, and let them own the how. This works in Snowden’s terms because it makes explicit only the stable knowledge, the intent, and leaves the fast-moving knowledge tacit with the people closest to the work, where it can keep moving. It fails without the previous alternative, which is why so many OKR rollouts disappoint (did I ever say I also hate OKRs? That’s for another time): an outcome handed to a team without context is a small map, not a delegation.
Commit to bets, not timelines. The Shape Up school: a fixed cadence, a betting table, full commitment to what is in the current cycle, and deliberate silence about everything beyond it. This works because the artefact’s claim finally matches the actual state of knowledge. Complete detail on what is underway, nothing promised about what is not. It refuses to publish certainty it does not have, which is exactly the honesty a roadmap format cannot achieve.
Bounded builds, when even the outcomes are provisional. This is the pre-product-market-fit case, and it is where I am living right now. At an early-stage AI company I work with, we stopped trying to present our way to alignment this week and ran a different play: a three-week build sprint. Three mixed teams, engineering and ML alongside product and domain experts, each owning a set of use cases, with one job: get as close to commercial readiness on your use cases as you can. We made explicit only the stable things: the vision, the value proposition, the audience, the use case list, summaries of the customer calls, and one shared vocabulary of four words every prototype must speak. We deliberately did not hand down solution designs, feature specs, or a sequenced plan. Each team finds its own path: talk to the customer contacts, interrogate the evidence, build, get it wrong, build again. The weekly deliverable is explicitly the written learnings, what we now believe and why, with the prototypes demoted to evidence. A team that reaches commercial readiness this way doesn’t just have a prototype. It has judgement, the ability to make the next hundred small decisions without asking anyone. No document transfers that. Doing the work does. Snowden would call this an artificial community, a team assembled around a bounded, real task, and he argued it is the only reliable way to manufacture competence to order.
Note: I’ve done this before, at a Series B incumbent building a new product in a domain it already knew: around 120 people, 20 of them engineers. I can be precise about what “it worked” looked like, because the evidence was behavioural. Teams self-organised to sit near each other in the office. They set up their own repos, wrote their own team working agreements, agreed their own definition of done. I was pulled into minor decisions less and less, and more engineers ended up on prospect-facing calls, which is where tacit knowledge of the customer actually gets built. It was as near to the almost utopian “empowered teams” state as I have seen. Honestly, it was up and down like most cycles of learning, but it held for about eighteen months, and for another six months after the company was acquired. Then other mechanisms and principles started coming in: a renewed focus on defined delivery dates for ‘predictability’, more time spent estimating and communicating estimates. In my view that changed it, and not for good. Note the irony, because I only saw it clearly while writing this: the thing that ended the closest sighting of empowered teams in my career was a reversion to exactly the artefacts this essay is about. This time we are just starting, so in three weeks I canreport back on what worked. Whichever way it goes, a failed experiment honestly is worth more than a case study with a pre-planned happy ending.
Keep the knowledge liquid. More has been written on this in the past five years, thanks largely to Teresa Torres, than on most of the other items here. Continuous discovery, done properly: a steady rhythm of customer contact, with raw evidence (call summaries, transcripts) shared widely rather than pre-digested into conclusions. This works because it refreshes tacit knowledge instead of freezing it. The wine stays in the barrel. Teams drawing on last week’s customer conversations don’t need a quarterly artefact to tell them what matters.
A challenge: guides don’t scale
There is a second hole, and it was pointed out to me from two directions at once: from the most junior reading of this piece and from the most senior.
The junior version goes like this. “The strategy lives in people and conversation” is a wonderful sentence if you were in the conversations. If you joined last month, sit in a different timezone, or simply aren’t senior enough to be in the room, tacit knowledge is a privilege system, and the document I’m telling leaders to withhold is the only on-ramp you likely have.
The senior version: maps exist because guides don’t scale. A guide serves one or a few more travellers at a time. At forty people, relentless repetition works. At four hundred, it is a bottleneck with our face on it, and the artefact isn’t a degraded substitute for the guide. It is the only technology we have for knowledge outliving its holder.
Both are right, and Snowden himself supplies the warning that ties them together. In the same chapter, he notes that too much knowledge is only tacit because its owners have mystified it to protect their own authority. Read that sentence as a product leader and wince: a strategy that lives mainly in your own voice is a key-person dependency. I have been that dependency. Being needed is nice, and “the strategy lives in our conversations” can be a way of making sure the conversations need you.
So the guide model carries obligations, and they are the opposite of hoarding. Write the stable things down precisely because they are the on-ramp for people who weren’t in the room, and keep them mercilessly current. Put the raw evidence, the call summaries and transcripts, where everyone can reach it, so context is not gated by meeting invitations. When you test whether the strategy has landed, be clear about who is being examined: you. If someone two levels away can’t play the strategy back, that is your communication failing, not their potential. And measure yourself by redundancy. The goal was never one guide with a devoted following. It is many guides, which means the real test of your guide work is how well things run when you are not there.
A certain product leadership skill
One more thing, and it is the part I find hardest to say without it sounding like a humblebrag. When being asked what kind of product leader I am, and strengths, this sometimes get described as ‘visionary’, usually because I bang on about product vision and strategy more than most. I have come to think the label is wrong about what is actually happening, and after the section above, you can probably see why..
What I actually do is guide work. I communicate the vision and strategy constantly, far past the point of personal boredom. I test whether it has landed: asking people to play it back, watching the calls they make without me, correcting drift early. The goal is never that people can recite my document. The goal is that they can draw their own map in their heads, one that fits their context, so that when the terrain shifts they can redraw it themselves. Done properly, this makes the “visionary” progressively less necessary, which is how you know it is working.
Snowden’s chapter names four ways knowledge moves in an organisation, and the one he flagged as rarest is the move nobody builds for: explicit knowledge becoming tacit fluency, the moment a team has internalised a strategy so completely it stops consulting the document.
That goal for me is the entire job of product leadership, and it cannot be shipped as an artefact. It only happens through frequency, testing, and trust. What gets called vision is mostly just that move, done in public, over and over.
Things to try
Match the format to the stability of the knowledge, not to fashion. Dates for genuinely ordered commitments. Now/Next/Later where order is known and detail isn’t. Outcomes where the team has the context to interpret them. Where even the outcomes are provisional, stop reaching for a format and build context instead.
Draw the external map deliberately. Sales, board, and customers have legitimate map needs that are contract and governance questions, not alignment questions. Give them an artefact drawn on purpose: scoped to honest commitments, confidence labelled, produced from one shared understanding. Never confuse it with your internal alignment mechanism, and never let it breed accidental versions.
Test the knowledge, not the readership, and know who is being tested. Stop measuring whether people have seen the strategy. Ask someone two levels away to present it back, or to make a live prioritisation call. If they can’t, the fix is more communication and exposure from you, not another document from them.
Build on-ramps for the people who weren’t in the room. Keep the stable artefacts short and mercilessly current, and make the raw evidence (transcripts, call summaries) available to everyone, so that new joiners and remote colleagues can build context without needing an invitation.
Split every strategy artefact into stable and volatile. Vision, audience, value proposition, vocabulary, evidence: write them down, keep them short, keep them current. The how and the sequence in any genuinely uncertain area: resist documenting them, and say out loud that the resistance is deliberate.
Replace one roadmap presentation with one bounded build. Take your most contested roadmap item and give a mixed team (engineering plus product plus a domain expert) two to three weeks to take it to a validated prototype. Compare what the organisation knows afterwards with what a presentation would have achieved.
Make learnings the deliverable, not the demo. End each week with a short written synthesis, what we now believe and why, with evidence, and treat the artefacts as exhibits. If a team can demo but can’t articulate what changed in their understanding, the sprint isn’t working.
Give teams a shared vocabulary before a shared plan. A handful of precisely defined words that everyone’s work must be expressed in buys more alignment than fifty slides, because it shapes how people think rather than telling them what to think.
Summary:
Most of what we call alignment work is producing maps for people who needed to become guides themselves.
Outsiders get a map drawn on purpose.
Insiders get the context to draw their own.
And the leaders who get called visionary are usually just the ones doing the guide work, whose final measure is not how much everyone needs them, but how little.
Stop: Polishing the (road)map. Start: Helping people draw their own.
Researched and edited with AI. Written, argued, verified, and signed off by a human.
Very good one. Like it.
Yet there is one weakness. And that turns to Snowden again.
A vision and intents can be - often are - a 'idealized future state', which he also argues against, because (and that may be my limited, simplified understanding) their main feature, providing focus, is also their weakness: constraining perception for options along the path you take. They are not just a bet on the 'idealized future state' becoming true, being the best place to be once you get there; they also avoid/hinder you discovering better places (options) during your journey.
The map & guide analogy doesn't transform nicely to this problem, because a guide is typically given that goal in the form of a specific location to get to. The path stays variable, the location to get to is fixed. And Snowden advocates for a direction of travel and to leave the goal open.
On a territory phrasing he asks to explore it. And it's less like the guide who knows the territory, but the experience or skill of a guide in exploring a territory she's never seen before.
I know that this typically is not what those people asking for a map want and (believe to) need. And perhaps this tension is what needs to be explored further.
Fascinating! definitely a challenge product people encounter every day