How To Make Roadmap Conversations More Strategic
By Making Uncertainty Explicit with the Problem, Solution, Delivery framework
There is an immense amount of “How to” roadmap articles. I hope this will not be yet another one of those…
As a brief introduction, we will probably agree that roadmaps have a series of challenges, including:
- Communicating with different audiences: how do you use a single artifact to communicate with c-level stakeholders and the development team?
- Updates: plans are constantly changing. How you keep it up to date? How you prevent that stakeholders hold the team accountable for something that was displayed on the roadmap, but it later changed?
- Strategic vs. tactical: a roadmap is a tool for strategy communication, but when displaying next quarter information, people will want details…
- Outcome vs. Output: similarly, you want to be strategic and focus on results, but conversations often move to solutions (and dates).
- Timeframes and uncertainty: the further away something on the roadmap is, the more uncertain it’s potential value, and it’s expected target date.
I want to focus on this last one since I feel there is a quick fix that can impact many other topics like outcomes, strategy, and communication.
Problem, Solution, Delivery
Even when defining a “standard” Product process is rather hard, a potential roadmap item (or any product idea) will usually go through three “major” stages: Discovery — Problem, Discovery — Solution, and Delivery. Let’s see a very brief definition.
Note: before the “Problem” phase there should be a opportunities identification process and post Delivery there might be Optimization, but it is not in the scope of this article :)
Discovery — Problem
At this stage, we are yet not sure if we really understand the problem, or if it is a problem worth solving. Our goal to move on will be to empathize with the target user, gain more knowledge about what problem we need to address and the potential impact of solving it (for further prioritization).
Activities in this phase may include In-depth Interviews, Context research, JBTD interviews, etcetera. It might also include market research and sizing.
Discovery — Solution
Once we identify and understand a problem worth solving, we need to know if we can create a potential solution attractive enough for users to change from their current status-quo.
Ideally, you will tackle Marty Cagan’s four big risks before moving on to delivery:
- value risk
- usability risk
- feasibility risk
- business viability risk
Activities in this phase vary a lot depending on the solution, ranging from usability tests on low fidelity prototypes to fully functional prototypes.
Delivery
Now you have certainty on what you need to build. At this stage, the primary uncertainty is delivery time, but you are committed to delivering this item.
Using Phases in the Roadmap
If we let stakeholders and any roadmap user understand these phases, later when we visualize them in the roadmap, it should help quickly clarify the level of uncertainty.
A quick example with stickers
As you can see, even when colors are used for themes or other purposes, you can easily include visual elements to display the different stages. I suggest you check what makes more sense depending on your roadmap software and the time required to update the visual details.
Why is this “divorced” from the timeframe?
I do like the idea that things further away are more uncertain and under “normal” circumstances that should be true. But developing products is erratic, and new insights or market conditions can drastically change your plans. It is important to show to everyone when something even closer in time has a high level of uncertainty (or the other way around, something that you know you will build but is pushed for later releases).
Conclusion
Going back to the title, when the phase is clear, it should open the discussion to a more strategic debate related to what the team is really trying to figure out at each time.
- Instead of discussing a particular feature that is 12 months in the future, you can consider if the problem is worth solving according to your current strategy.
- When talking about a solution you are trying to figure out, you will have the elements to say why it is essential and why you don’t yet have specifics on how it would be delivered.
That’s it! An option to improve our roadmaps. I hope you find it useful and share your thoughts!
If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers of my Lean Experimentation blog!
