Outcome-Driven Roadmaps
I was defining KRAs and KPI for my team’s Solution Architects and Solution Integrators. The existing ones were all based on output; the output was not value-centric. The question of “WHY” was not coming up in the KRAs. My Architect wisdom goes back on WHY KRAs if there is Outcome. So started to frame the KRAs based on Outcome. Thoughts I played for an Outcome-Driven Roadmap were captured in this article
Roadmaps are among the most controversial artifacts in Product and Service Management. We are still far from having a standardized way of creating them, which led many enterprises 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 making them around outcomes is critical for their success.
Five typically controversial items
There are a few troublesome attributes within roadmaps that foster the problems mentioned above.
1. Time scale
Many enterprises 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 acknowledges 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 specific 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 few months, hides the uncertainty that future articles have. As we go further in time, items should have fewer details and probably be less granular than opportunities we will tackle in the next few months.
5. Commitment/agreement
Roadmaps should be flexible artifacts, not commitments. Can teams quickly 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 helpful 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 most challenging shifts is encouraging stakeholders and managers to discuss results and not 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 groups 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 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, experimentation and rapid iteration, adopting new insights, and increasing the chances of achieving the desired 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 and service 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.
