Rethinking outcome-based product roadmap to plan for uncertainty (part 1).
Understand that a roadmap should define the what before communicating the how.
A few posts ago, I wrote I was reviewing four of my most frequently downloaded templates. Today, I’m starting with product roadmap, specifically outcome based product roadmaps in a two-part article.
In 2020, I wrote Outcome based product roadmaps using "Now, Next, Later”. Over the last two years, I’ve created a few and seen my fair share of product roadmaps. This year, I wrote an entire series of articles reviewing product roadmapping SaaS software (ProductPlan, airfocus, ProdPad, Productboard).
I believe there are two types of philosophies people hold when it comes to product roadmaps. In camp A are people who create roadmaps and expect it to be predictable. People in this camp view a product roadmap closer to an actual road map, helping everyone navigate from point A to B.
In the other camp, camp B, are people who create product roadmaps and value the creation process more than the final result. Yes, a roadmap is good, but it’s more directional. They might say “Roadmaps are useless, but roadmapping is great”, a play on Eisenhower’s quote “In preparing for battle I have always found that plans are useless, but planning is indispensable.” People in this camp view a product roadmap like a hurricane forecast map. It informs the general direction, with the accuracy of that information weaker the further out in time.
As you can imagine, Camp A people and Camp B people don’t always get along.
While my analogy is a bit extreme and you likely don’t fit perfectly in either camp, you probably lean towards one. I think the deciding factor in which way you lean is your comfort level with uncertainty. Crave predictability, you want A. Enjoy variability, B is your cup of tea.
As a PM, I try to practice in camp B because I know rationally I’m not good at predicting the future, especially further out in time. However, I personally relate to camp A. So I understand the internal struggle between people in the two camps. We need to get more people in camp A, who dislike camp B, to function and perform well in camp B. What can we do to make people who are uncomfortable with uncertainty, which is exhibited in the Now, Next, Later type of outcome-based product roadmaps, more comfortable with uncertainty?
Why involving more people isn’t a scalable approach when creating a product roadmap.
It’s hard to convince people in camp A to adopt camp B behaviors. You can’t tell some to be comfortable with uncertainty. Not everyone swims if you throw them into a pool.
One common approach people try is to engage everyone in creating the product roadmap together, where they see how uncertainty is unpacked and model the behavior of others who are more comfortable handling uncertainty.
While this technique can work, the critique is time-consuming, often requiring repeat exposure. It also necessitates someone comfortable guiding those through uncertainty. Even then, this technique never scales. You simply can’t involve everyone in the product roadmapping process. Too many people when your company grows. Just as some of us have to be taught how to read and react to a hurricane forecast map, there will always be people who only read the final product roadmap and they must be taught.
Teaching others how to read and use an outcome-based product roadmap
Just as people misinterpret hurricane forecast maps, people misinterpret outcome-based product roadmaps. I attribute one contributing factor to misinterpretation to the fact that readers of outcome-based product roadmaps confused it with date-driven output roadmaps (i.e., project roadmaps).
The other contributing factor is that people don’t know how to change their responses to handle the uncertainty in outcome based product roadmaps. It’s easier to respond to a roadmap where, if A happens, you do B. But how do you decide what actions to take if A might happen? In other words, if certain information in a product roadmap is a “maybe", how does anyone else use the information? [Side note: In part 2, I’m planning to try to update the roadmap template to address this issue.]
Unpacking uncertainty.
Recall that there are two major principles to outcome-based roadmaps using Now, Next, Later.
It is a roadmap that is goal or problem oriented. In other words, we worry about what before how. [Note: I prefer the word problem rather than goal here. You’ll see me say why further on.]
Items in the Now column are more certain than items in the Next and Later. So while there is uncertainty, not everything is a “maybe”.
With that quick overview, how do we unpack what makes roadmaps uncertain? For this, I’m leaning heavily on the paper, “Coping with Uncertainty in Planning” by Karen S. Christensen. In it, she describes two major types of uncertainty that we must understand.
There’s uncertainty about the problem we’re trying to solve, what she might label “disagreement on the goal”.
There is uncertainty about the solution to the problem. She calls this technology, but I prefer to think about it as the “how”.
The combination of these two uncertainties creates a 4x4.
In date-driven, feature-oriented product roadmaps or project roadmaps, the focus is almost exclusively on the how (i.e., Solution). If it’s a product roadmap, it is presented as a list of features delivered against a timeline. If it’s a project roadmap, it is a list of tasks. The goal is to deliver those features or complete the task. It is assumed delivering the features or completing of the tasks will address the problem (whatever it is). The problem is rarely explicitly stated.
Outcome-based product roadmaps try to lead with the problem. Recall I wrote earlier I prefer the term problem rather than goal? This is part of the reason because a goal also exists in feature-oriented product roadmaps. The goal is to deliver those features.
Now, in my current outcome-based product roadmap templates, I attempt to address the problem orientation by using OKR techniques, but I’m not certain that’s the best solution anymore. In short, it could be made better.
In this step, we are trying to unpack the uncertainty in our problem. This is what Karen might label as … articulating and gaining agreement on the problem(s). There are different techniques to achieve this, all with the aim of moving from “Not Agreed” to "Agreed”. Only then should we evaluate the how.
In how, I use the technique of “Now, Next, Later”.
But Karen points out that the uncertainty in this area is caused by the different approaches people use to evaluate whether the proposed solution (i.e., feature roadmap) will solve the problem. In other words, readers of the Now, Next, Later roadmap may doubt the solutions will be successful or find the list and order of solutions arbitrary. Most Now, Next, Later roadmap doesn’t address this issue, without a human voiceover (i.e., presentation). Thus, I think there’s an opportunity for improvement here.
And that’s part 1. In summary:
There are two camps of people who hold different perspectives on how to create and use a product roadmap. I believe which camp you sit in depends on your comfort level with uncertainty.
Outcome-based product roadmaps introduce more uncertainty.
People who dislike uncertainty need to be taught how to read outcome-based product roadmaps. They also need to be taught how to evaluate and use information dependent upon whether the uncertainty is “gaining agreement on the problem(s)” or evaluation if the solution will be effective.
Welcome feedback on this writing because I’m trying to advance the thinking on outcome-based product roadmaps. If any part that’s unclear…please let me know.
Additional Reading
Looking forward to Part 2...
Excited for part II!