Three maps better than a roadmap
"We need a roadmap, is there a template we can use?"
I see this request all the time. From clients to peers, developers to product execs.
I get it. A roadmap feels like such a great thing, its an artifact that says "this is what we're doing, and when we'll do it".
Most roadmaps look like this:
These aren't great.
This isn't so much a map, as it is a chart – and a fragile one at that. It places "features" into "time" categories. Nearly anything unanticipated happens – good or bad – and this chart becomes out of date immediately. In fact, simply moving through time & on-schedule makes this chart less useful – how valuable is this for decision making in q3 or q4?
Not only that, but this chart has the illusion of alignment – when often, there isn't. How many stakeholders weighed in? What prioritization process put Project A in front of Project B?
Most roadmaps don't describe (or sadly, reflect) a strategy.
I admit – I'm 100% guilty of this. In fact, I've been hired to create this type of roadmap for clients for years. I may have used a nicer color coding and more a future-proof "Now-Next-Later" format. But the essential issues remain the same.
Roadmaps are status reports, not decision-making tools
Don't get me wrong: roadmaps have a use. Especially for coordinating efforts across teams. GTM, sales and support teams love having a product roadmap. It allows them to work in sync and plan their own activities.
For outside teams, a roadmap is an artifact that helps them know what to expect.
The hidden trap is that when asked for a roadmap, most teams start "building out a roadmap". Instead, they should engage in a process of discovery and decision-making, that results in a roadmap artifact.
Great roadmaps are a byproduct of a repeatable strategy process
A great Roadmap is made like a great entreé – its product of preparation: collect the ingredients, follow a well-thought out recipe and present the final dish.
The "ask" is for the Duck à l'Orange, but as the chef, you know that means that you went to the market earlier this week, spent the morning preparing the sauce, and used the recipe you've honed over years.
Most teams treat roadmapping like a homework assignment.
Unfortunately, teams start with:
Presentation > Preparation > Inputs
That process looks like this: - Open MIRO with a roadmap template - Get the team together and brainstorm, what goes on here? - Send it around and gather feedback, but actually – that feedback is too late, since the roadmap is already "done"
What should happen instead is:
Inputs > Preparation > Presentation
Today, I'm going to walk through three maps that I've found to be invaluable, repeatable, prepared inputs for a roadmap:
- Wardley Map
- Domain Map / Team Topology
- User Journey Map
Decision-making is a super power for any leader.
Wardley Map – What's our landscape?
Wardley maps, named after their inventor Simon Wardley, are a visualization of the landscape a business operates within. The key elements are the resources that produce value for a customer (the value chain), plotted against the sophistication of the market (evolution) and the visibility of the resource. This seems complex in prose, but as a map is quite simple to parse.
Domain Map - How do we do work?
Domain maps are high level views of how your organization functions, and shows service boundaries. This is not an org chart. Its not about how your org is laid out from a hiearchical standpoint, but how work translates into value. These maps capture your components, capabilities, ubiquitous language and the boundaries that make up your communication structure.
The team behind Team Topologies, uses the exercise of a User Needs Map to define service boundaries. This is a great way to arrive at your Domain Map. I've also used 4C's workshops to pull this out of teams.
I'm being explicit about high-level because much of the literature and frameworks surrounding this tend to be very workflow-y, architecture-y and detail-y. Very "if-this-then-that", which is too granular.
Sure, the details matter, but what we want to know is "how does a bill get made?" not "who couriers the letter to the speaker of the house?"
User Journey Map - What's the promise to our customers?
A user journey map outlines the activities, touchpoints and quality of experience that your user (usually: customer, but could be an internal user, downstream team, etc) has with your product.
Journey maps are ubiquitous for UX and Marketing teams, but somehow less so on technical product teams. The great thing about a journey map is that they are extremely easy to create and once you have it, simple to adjust, correct and augment.
User journey maps are used for decision making by outlining where your product is failing to meet needs, or where you may be overcommitted. Because the user experience is placed where position matters, you can see if a touchpoint with your product (or a competitors) is an opportunity to prioritize the experience.
Pulling in all together: Roadmaps as a process
As I said above: the process is far move valuable than the result. If you already have the three maps above, here's your headstart on your roadmap process:
- A clear view of the environment your venture/product/startup operates within, including where the opportunity lies and what approach is befitting of your evolutionary stage
- A full graph of the boundaries within your organization, where communication crosses them and
- An end-to-end picture of the customer journey and where you show up during that (and where you don't)
If you pass this along to your peers, boss or clients – the input you'll receive will be far more useful than "when will that be done?". If you can imagine: being able to ask and answer "Why are we doing this?" with a "No, we shouldn't be doing this" is just glorious.
There's a place for a traditional Roadmap. Its a necessary artifact to rally folks around expectations – to be able to share a visualization of "What we're doing" to your leadership and peers.
But if you want to provide strategic alignment and work on the most important things – its all about the preparation and process.