In this article, we will discuss the challenges one faces when working with roadmaps and what techniques such as OKRs and GIST can be used to achieve defined roadmap goals.

The use of roadmaps and its challenges

Benefits of roadmaps

When developing software, we all come to the elaboration of a „roadmap“ and there are many reasons why an organization should start using it before going into the execution phase of a project:

• it helps to coordinate activities across different teams
• as a communication tool, it is informative and provides transparency
• it provides motivation to the teams and inspires them
• it helps to prioritize product items
• it makes decisions understandable for everyone in the organization

Nevertheless, working with roadmaps is a challenge and one can easily fall into traps that an agile organization must avoid.

The 3 common traps using roadmaps

1. Sequential vs iterative approach

Coming from waterfall product management, one will have the tendency to plan the software development into phases, where each phase will focus on a specific feature:

• Phase 1 = development of feature 1
• Phase 2 = development of feature 2
• Phase 3 = development of feature 3
• etc

The problem here can be that we are focusing only on the delivery of features that probably won’t generate any value until the complete product is shipped.

Moreover, the linear approach of dividing the product into features on a timeline goes against the agile principle of building the product (and therefore generate value) incrementally in different iterations.

2. Deadline and non-respected promises

Having a linear approach of the product development, we will tend to commit to certain delivery dates and give a deadline to the final product shipment. After we planned all the features on the timeline, it is properly estimated and we commit to a deadline – What could possibly go wrong?

Well, the greatest majority of projects fails in being delivered on time, because deadlines were agreed ahead of the project start and according to a linear plan.

Considering this aspect, digital product development cannot be linear but should be iterative, aiming at generating value as soon as possible in order to reduce the time to market.

3. Output vs Outcome

With the goal of delivering features in a sequential manner, the organization is unfortunately focusing only on the output. What matters is:

Delivering Feature X on day Y

However, the feature alone (the output) is only one aspect of the tactic and the value (the outcome) it will generate is the key factor to define success.

In order to be able to focus on the outcome and not the output, one can start working with strategic roadmap where the mission and the strategy of the organization plays a key role in the product management.

Strategic Roadmap implementation

Pre-requisites

Before jumping in the implementation of a strategic roadmap, it is essential to understand what it requires to be efficient. When looking for a definition of a strategic roadmap, one will quickly realize that it cannot be established without the following pre-requisite:

A mission for the organization

The mission is defined by the management board and is conveying the purpose of the organization as a whole entity. Having a specific and genuine purpose transports a message that will federate the organization around its values and help to differentiate itself from other organizations.

A Strategy or a Vision

At all levels of the organization, whether we are directly dealing with the customers, improving the IT Infrastructure or coordinating people relations, we are to define our goals (also later on described as tactics) as per the implemented strategy.

Strategy Definition

A strategy is a long-term plan on what to do to achieve a certain goal

https://simple.wikipedia.org/wiki/Strategy

Though we are evolving in an agile environment (at least, where it makes sense, such as IT), the strategy is not meant to change regularly, and should provide by its nature a stable and long-term plan to which we can refer to when the team is working on their „tactics“ or strategic roadmaps.

Nevertheless, when the applied strategy proves not to be efficient to reach the organization’s goal, then it is common to review and adjust it.

What should not be neglected when elaborating a strategy is that it should provide a vision and inspire people to work around it.

Unfortunately, a „we want to make more revenue“ strategy is not enough to inspire people.

A clear set of goals

Given the strategy in place, every team has now their fate in their own hands to elaborate a sub-set of goals that will fit in the strategy of the organization. Every team is contributing to the organization in different ways: whether their focus is building a B2C website, ensuring the exchange of data with B2B partners or improving the security of our IT infrastructure. They will define their objectives for their respective product, that will eventually help to reach the common goal of the organization.

In our case, we use the OKRs (Objectives and Key Results) framework in order to establish goals on all levels of the organization. Our OKRs follow this rule:

• The Objectives define where we want to be in a given point of time
• The Key Results define how we will know we got there

The Strategic Roadmap or „Tactics“

Tactics Definition

Tactics is the detailed steps which are used as our progress is opposed by the opponent. For this reason, tactics are short-scale and flexible.

https://simple.wikipedia.org/wiki/Strategy

In our area of work, we are also talking about strategic roadmaps.

One thing that is important is the analogy between the characteristics of agile methodologies and the definition of tactics / strategic roadmap:

Implementing a plan that is short-scale and flexible

Define your timeframe

First, we need to define a point of time when we want to reach our objectives. In the same way we set sprint goals that must be met at the end of the sprint, we do the same with our objectives on a longer timeframe (usually a quarter, but can be longer).

Define your plan

In order to define the plan, we use the GIST Framework. It is a framework inspired by lean principles created for product planning. Our implementation of GIST is inspired by the work of Itamar Gilad (more info: https://itamargilad.com/gist-framework/)

GIST stands for: 

• Goals:
  • Where do we want to be?
  • When should we be done with our goal?
  • How do we know that we have reached our goal?
• Ideas
  • Hypothesis that are saved in an idea bank and prioritized according to their ICE Score
• Steps
  • Steps are not longer than 12 Weeks long and are the different phases a project / idea can go through
• Tasks
  • They represent the steps break-down and mostly composed of the product backlog items

Implementation of GIST

Ideation Phase

Once we have defined our goals, we can start with the ideation phase. It is basically the gathering of hypothesis that will help the team reach their goals. This collection of hypotheses is called an idea bank and can appear in the form of a table in a shared file or a Database, as in this example:

These ideas are then prioritised using a scoring method: the ICE Score. As anyone can submit an idea, we are at this stage focusing on the quantity rather than the quality. Through the constant re-assessment of the score, the priorisation of an idea is constantly evolving before the quarter but also during the quarter itself.

ICE Score

Three factors are taken into account to calculate the ICE Score: Impact, Confidence and Ease and it is calculated as per this formula:

Impact, Confidence and Ease are evaluated using a scale from 0 to 10.

Steps

Once we have our ideas prioritized, we will start to break the ideas down into steps. The point is not to start a long and costing implementation of the idea but to experiment the idea and get more confidence around the idea itself. We are aiming to have small iterations until the idea is fully implemented.

Here is an example of the different steps an idea can go through:

Tasks

The „Tasks“ phase simply refers to the implementation of the product backlog items that are necessary to implement in order to make the idea concrete. These are the user stories, technical improvements or prioritized tasks in each sprint.

From theory to practice

In order to validate the assumptions above, we need to put that in practice. Does this method really help to focus on the goals defined? Are the teams really focused on the outcome and not the output as promised?

Let’s find out in the next article 😀