Outcome-oriented: The Secret of Successful Roadmaps
And how to overcome 5 typical pitfalls
Roadmaps are among the most controversial artifacts in Product Management. We are still far from having a standardized way of creating them, and that led many companies to develop versions that caused more harm than good.
While there are countless ways of creating roadmaps, today I just wanted to point out a few problems to avoid and why creating them around outcomes is critical for their success.
5 Typically controversial items
There are a few troublesome attributes within roadmaps that foster the problems mentioned above.
1. Time scale
Many companies use months as columns for their roadmap. The problem with this approach is that in doing so, we are setting concrete time frames to items for which effort and duration are yet uncertain. Using other timeframes like Now, Next, Future acknowledge this level of uncertainty.
2. Items intent
Are items in the roadmap specific solutions, problems to solve, or goals to achieve? There is a tendency to put solutions, binding us to build a particular feature, even when we still require discovery efforts to understand the best way to resolve a particular problem.
3. Level of detail
What level of granularity should we use? If using solutions, should we use features or broader scope items like an “epic”? We often fall into more detailed descriptions, more suitable for backlogs than roadmaps.
4. Uncertainty over time
Using the same visualization for work items that we will focus on next month, as for features we are planning for the next 18 months, hides the uncertainty that future items have. As we go further in time, items should have fewer details and probably be less granular than opportunities that we will tackle in the next few months.
5. Commitment/agreement
Roadmaps should be flexible artifacts, not commitments. Can teams easily change items or use different scopes than the ones in the roadmap? If not, we are incorrectly using the tool as project plans.
Outcome over outputs
If there is a single attribute worth focusing on, that would be outcomes. We tend to discuss what the team will deliver, and while that conversation may be useful further down the road, it is not what we should cover during our strategic roadmap definition.
You face several challenges to shift the discussion toward outcomes:
● Trust: One of the hardest shifts is encouraging stakeholders and managers to discuss outcomes and not outputs with product teams. They must trust the team to decide the best course of action to solve the problem and achieve the goal.
● Outcome accountability: Similarly, it may be difficult for teams used to receiving and shipping requirements to take responsibility for selecting what to build and to become accountable for uncertain results that they may feel are outside of their control.
● Reward results, not outputs: Most of the traditional organizational structures and processes are set up to optimize and reward delivery. Without changing these compensation tools, people will eventually fall back to focusing on shipping rather than impact.
● Embrace uncertainty: This change in perspective is based on a context where we are unsure if what we want to build will have the expected impact. Failure and learning are required parts of the process, along with experimentation and rapid iteration, adopting new insights, and increasing the chances to achieve the expected results. We need to embrace this uncertainty about the solution, and we need to feel safe to “get out of the building and learn about it.”
Outcome-orientation is the single most crucial transformation a product organization can make, and the strategic roadmap can be a keystone artifact to achieve it.
Product leaders are responsible for keeping the discussion centered on the problems we want to solve.
Conclusion
Roadmaps are tools, and as such, they can be good or bad depending on how you apply them. Furthermore, they have different structures, styles, and uses. Creating them without this understanding can lead to miscommunication and problematic artifacts. They aren’t straightforward and coming from a world of project management and Gantts, it is easy to fall into the problems described by the roadmaps opponents.
If you want to know more about creating strategic roadmaps, download a free section of Product Direction, my upcoming book, describing at length, with examples and templates, the process to successfully create and link Product Strategy, Roadmaps, and OKRs.
Read on: my next article describes tools to get from strategy to outcome-driven roadmap.
This story was originally published on LeanExperimentation.com. If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join +1500 readers!
