Why outcome based roadmaps are difficult to implement?
What we want is control, but we need is to be better at adapt to "uncertainty, unpredictability, and serendipity".
I’m recovering from COVID-19 while writing this article. Thus, it’s been a little more mentally challenging, staying focused. If you’ve found some parts difficult to comprehend or see a grammatical error, leave a comment and I’ll fix it.
If you look through my substack, you’ll discover multiple articles that come with a sample or example template. Recently, I took a look at the usage data over the last year. The two most common template readers requested access are Sample Outcome Based Product Roadmap Template and Sample Enhanced User Story w/ Specifications Template. They account for almost 40% of all template requests.
I don’t know exactly why they are the most popular. The templates aren’t associated with my most popular article on the homepage.
Google analytics don’t list them as major drivers of new traffic from organic search. Maybe I should conclude that it’s because they are the most pressing work issues product managers face (e.g., how to create a roadmap and how to define user needs).
Regardless, I decided to take a look at the sample outcome roadmap template critically since it’s been almost 3 years since I created the template. Plus, my recent experience looking into product roadmapping tools made me wonder if my templates were outdated.
1. Moving away from Google Doc to Notion
When I created the template in 2019, Google Doc was my documentation tool of choice. But by 2020, I had migrated to using Notion because Notion has better organization (easier to find documents), more refined sharing and collaboration, and a built-in database feature. This isn’t to say that Google Doc is bad, but Notion has more advanced capabilities. Some Notion features such as the backslash command ‘/’ to bring up a dropdown menu of options have now become available in Google Doc (via “@”).
But the biggest single reason to use Notion over Google Doc is the database feature. In Google Doc, you can embedd Google Sheets. But Notion database enable you to build relations between tables.
Thus, I’ve updated the roadmap template in Notion and made some enhancements. See Sample Outcome Based Roadmap in Notion.
2. Understanding roadmap’s central fallacy: ability to accurately predict the future
The act of creating a roadmap is relatively easy. The hard part isn’t writing words down or formatting. It’s getting a group of people to agree that this roadmap is the “correct” roadmap. Here, I’m defining correct not as the sequencing of how work should be accomplished, but that doing initiative A will cause B outcome.
Here lies the crux of the problem for outcome-based roadmaps: the future is uncertain and so is the causation. As Dominic Hofstetter wrote: “Most roadmaps suggest development pathways that are linear and sequential. The underlying logic is that outcomes serve as prerequisites for other outcomes, according to the logic: A leads to B, B leads to C.” Yet, many of the initiatives we present on roadmaps are merely educated guesses that may generate the key result. Smart people looking at the same data likely disagree on which initiative will work. Product managers than spend all day “managing stakeholders”, a fancy term for herd people who disagree.
Outcome-based roadmaps doesn’t solve this problem, bven if people all agree on the same outcome or mission. Having a shared mission isn’t sufficient standalone. That’s becasuse it takes a different set of skills to motviate people to take joint action under uncertainty, including understanding your own response to ambiguous situations. [I created a free assessment based on the Intolerance of Uncertainty Assessment. Give it a try.] My roadmap template doesn’t really address this issue. It assumes you’ve resolved it when you created the roadmap.
3. Roadmaps as narratives versus roadmaps as tactical guide
Outcome-based roadmaps tell a particular type of narrative that is different than date-driven output roadmaps. Whereas many people complain about output or project roadmaps, the point of evaluation is very different. As an anology, an output roadmap will result in a bridge (the feature you built), whereas the outcome roadmap should result in reduced commute time between A <> B by 35 minutes with maybe a bridge. But just because you built a bridge doesn’t mean commute times will decrease. Maybe the bridge will induce more drivers.
This is why I believe you need to completement outcome roadmaps with multiple project roadmaps, that breakdown initiatives into it’s details and handles sequencing of work. One wthout the other isn’t sufficient.
Yet, the other problem with outcome-based roadmaps it that they only tell one narrative. Recall the above fallacy. Thus, recently, I’ve been exploring the concept of multi-outcome-based roadmaps.
Instead of a single roadmap, have two: a primary and an alternative roadmap that both try to achieve the same outcome. They should be diametrically opposed to each other in terms of initiatives. In trading off a single narrative, the two outcome roadmaps highlight a narrative that the primary is “what the majority believe now give the data”, but if things change, we’re willing to make a different bet. A key aprior work is identifying data or time that would trigger the alternative roadmap to become the primary.
I’m not sure if this is one of those “work in theory, not in practice” ideas. Is it double the work? Does it cause unnecessary confusion? Drop a comment if you’ve ever worked this way or heard of this concept.
Additional Reading: