Where we’re going, there are a million roads
Rethinking the product roadmap as a tool of PMs
It’s kind of silly to me how the concept of a product roadmap has, in a lot of cases, devolved into essentially a calendar. Too often do product managers say “this is what we’re doing, when” — sure, there are some assumptions and unknowns to acknowledge, but the plan is the plan and the timeline is the timeline, even if it realistically could change. A series of commitments on a timeline.
In fact, this idea has totally taken over as the primary meaning of the word “roadmap.” When I Google the word, this is what I get:
And when I see what teams put forth as “roadmaps,” they often look something like this:
We PMs know this isn’t representative of reality.
I don’t care what anyone says or what any roadmap might suggest: product building is inherently ambiguous. We rarely truly know with 100% certainty what our users want, or what will work in the real world. Building something to address a problem or capture an opportunity usually involves a windy difficult series of roads with divergent paths, odd roadblocks, and interesting opportunities along the way. There are a million options, or roads, for how we get to our shiny objective.
In fact, you may want to reach your objective, or you may also find a different one that’s more compelling to achieve. Or you might end up at a dead end due to unforeseen circumstances and need to move on to the next thing. You may find out halfway toward building your north star that it’s not nearly as impactful or exciting of a north star as you thought.
But we still use the roadmap as the artifact representing the work we plan to do. We’ve rewired our brains to think of roadmaps as a set of promises to our stakeholders and our users — the directions instead of the map itself.
And I get why — it’s about providing that clarity of direction. I’ve been in dozens of situations where I’ve felt a pull to promise a clear set of deliverables, a tractor beam of targets, or even a list of things I won’t commit to, mostly to address the need for direction or (to be honest) peace of mind. There is value in this. I do not deny it.
But I also worry that it obfuscates (or worse, trivializes) the actual work that product managers and their teams do: talking to customers, interpreting what they say, brainstorming interesting solutions to the problems that emerge, worrying about what could go wrong, navigating sometimes intense bureaucracies of partner teams, getting blocked by and unblocking weird blockers, testing the product, shipping the product, analyzing the product, and then maybe (but not always) actually meeting the objective(s) they sought out.
Adding just a space to change my Google image search query to “road map” yields slightly different results, some of which show a web of possible routes to take:
I’ve always had a fascination with maps, especially highway and subway maps. They suggest possibilities — different routes to take to different destinations. Let’s look at the New York City Subway map:
Say I want to get from a hypothetical home in Hoboken, NJ to La Guardia Airport to meet a friend flying in to visit. There’s a bunch of ways I can get there. (Stating a disclaimer now: I am not an NYC resident and have a limited understanding of how the subway works in practice, so all of the following might be horribly thought out. The point is not to find the best way to LGA, but to illustrate a point about optionality and ambiguity in product development.)
In all cases, I need to at least take the PATH train simply to get into Manhattan, where I’m connected to the rest of the subway system. From there, I have a number of options to reach my destination — all of them involve a bus in some form, but my most efficient path likely involves minimizing bus time. So, I can take a number of paths:
- I can take any of the 1, 2, 3, A, B, C or D trains up toward the Bronx and pick up a bus to LGA there. I’d likely opt for an express train (2, 3, A or B) unless there’s somewhere I can stop on the way via local train to, say, pick up food so I’m also not starving when I meet my friend.
- Alternatively, I could wait for the E train and take it northeast into Jackson Heights, Queens, where I can pick up a bus there. That’s a fairly long trek on the subway, but the bus ride is extremely short.
- I could also walk a bit north from Penn Station to Times Square and pick up the 7 train — particularly the <7> Express, which likely will get me to that Queens shuttle bus faster. That said, there is now a walk involved. And possibly another subway fare I need to pay.
I’d probably opt for the <7> express option, but let’s say that line is closed for service — or worse, a train breaks down while I’m on it. Unforeseen consequences that make me question the direction I took. A local train may have more frequent stops, giving me the option to get off more frequently and seek an alternate route if I need to.
Now let’s say my friend’s flight gets messed up and needs to land at JFK instead (disclaimer: I’m not an air traffic controller and have no idea if that would realistically happen, I haven’t flown in 3+ years 😅), I now have a different destination I need to get to. But, I still need to take the PATH train into Manhattan regardless. From there, I can either deal with the hour-plus-long slog of the A train, or perhaps find a more optimal route involving transfers which may or may not get me there faster.
I have a final option: I could always ride in an Uber/Lyft/taxi. But this is likely (1) far more expensive, (2) may not actually be faster thanks to NYC bridge and tunnel traffic, or (3) may come with other positive and negative unintended effects (my driver may be awesome or terrible).
There are a TON of parallels in the world of product development. A ton of things can go wrong, a ton of options present themselves for the way forward, and a ton of opportunities exist between the origin and destination.
Let’s stop thinking of roadmaps like calendars and more like what they really are: maps. Maps that get us different possible destinations.
When I’m thinking about a roadmap, especially when there’s a lot of ambiguity around where to go, I sometimes will create something akin to a flowchart — but instead of parts of a flow, the items are assumptions to be tested, features to address needs, capabilities to unlock value –which may or may not lead to various possible outcomes. Almost like a “choose your own adventure”. Almost like a map without the directions fully defined yet.
I may start with a possible destination / outcome / North Star, a starting point, and a first decision I need to make.
Then continue to map out possibilities, assumptions and open questions from there. I tend to let my mind naturally flow through these first, and then attempt to sequence them based on risk and sensible sequence. That may result in something like this:
I obviously need to provide some guidance on when I hope to tackle the questions or ideas laid out there, so I color-code different types of items (actual features to build, assumptions to test, decision points) so it’s clear when we’re building, testing or researching:
And so I end up essentially a different representation of the same commitments I may put on a classic “roadmap slide” — but with all the possible paths, justifications and logical sequencing that drives the things we may or may not achieve. Add in a rough timeline and you’ve got all the key ingredients:
This concept obviously contains a bunch of assumptions in its own right, and clearly oversimplifies the reality of building products. Regardless, I really like this for a few reasons:
- As a PM, this is how I actually think about the roadmap. I’ve personally made visuals like this in previous roles to map out possible roadmaps, for my eyes only, simply to make sense of a problem space.
- It healthily and clearly establishes the notion that we may not achieve the singular outcome we hope to achieve, but we may achieve other outcomes along the way or instead.
- It especially feels useful when building 0-to-1 products, where my team may be iterating toward a presumed ideal state but we simply don’t know what it looks like yet.
I also realize it falls short in one very important way: it is way too cumbersome for any non-product/technical person to be willing to navigate. There is immense value in the “executive summary,” the punchlines of a complex map like this. I created this in Whimsical, which was the best-looking flowchart tool I could find. Ideally there would be a way to easily collapse all the possible routes, highlighting the big features, themes and questions, for stakeholder digestion — but from what I can tell, such a tool does not exist for this (admittedly niche) purpose.
What if there was a way to minimize (without hiding) the other nodes in this map, such that the primary milestones or deliverables were prominently displayed against the timeframe, but the ambiguities and possible directions were still clear? I would love a simple way to toggle between the complicated map above and a simpler view for stakeholders that showed direction while acknowledging those possible outcomes and weird realities of building software, and even showed my team’s confidence around hitting certain outcomes. Perhaps something like this:
How might this play out in the wild?
So I’ve tried this type of roadmap artifact in a few previous roles — mostly for myself to personally keep track of all the options, but to also share with stakeholders as a way to envision the ways (not way) forward. While it’s certainly not a perfect document, it helped to convey the idea that while we (the product/design/technology function) did not know exactly what this product would look like, we did know the problem it should solve, what success may look like, and a few variations of how much work it may take to get there.
But the document didn’t solve for that on its own. Communication is also critical – as you test your assumptions and potentially change direction, you need to (1) update the living document and (2) communicate that change. I fell into a good cycle of this every 2 weeks; that may work better or worse in some contexts, depending on how quickly you need to learn or how complex/risky your problem space is.
Finally, none of this works without a clearly articulated vision, strategy and — most importantly, I’d argue — guiding principles. Principles to guide what success is and isn’t, what features or even design conventions are in scope and aligned with your vision, and the values of the customer you build for.
My overarching conclusion here is that, above all else, we as product managers and leaders should be critically reviewing not just our work, not just how we work, but the artifacts we use to document our work.
The roadmap is such a core part of the work of product managers, an essential tool for communicating the direction of your and your team’s work. But it also, at best, obfuscates the hard work of PMs. At worst, risks creating false confidence based on expectations that may simply be wrong — not to anyone’s fault, but due to a simple lack of acknowledging the assumptions and options of how to move your product forward.
So let’s humor new ways of communicating how we move forward.
