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 EA wisdom goes back to "WHY" on the KRAs if there is an Outcome. So started to frame the KRAs based on Outcome.

The frame needs to be based on the outcome. This article calls for an Outcome-Driven than an output based.

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 future articles' uncertainty. 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 rather than 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, and it is easy to fall into the problems described by the roadmaps opponents.

About Author

M Senthil Kumar is Program Head of Digital Solutions & Presales for Continental Europe at TechM. In his role, he is responsible for designing and architect digital solutions for large enterprises utilizing nextgen digital solutions with AI/NLP/ML/AR/VR/IoT/RFID/QR, etc. Spearheads Enterprise Architecture, carries 20 years’ experience in IT infrastructure Service Strategy, Service Design, Services Support, Engineering, Systems and Software Architecture, Consulting, and Presales. Truly focused on customer service excellence, enable continuous improvement by assessing and identifying customer business needs.

Disclaimer: The opinions expressed on this site are mine and do not represent my employers (past or present) or any other entity. I give no warranty or guarantee whatsoever regarding the accuracy, reliability, or completeness of the information provided on my article/website. I will not be liable to you under any circumstances for any loss or damage arising from your use of such information. Users are advised to check the accuracy of the information on this article/website.?