Product Roadmaps - In the Self-Driven Car Age

Leandro Pinter, Head of Software Engineering, Tyro Payments

Leandro Pinter, Head of Software Engineering, Tyro Payments

Where did Products Roadmaps come from?

The first time the term Roadmap was used was back in 1890’s. At that time bicycles were the mains from of transportation between cities so in order to move from city to city people needed some sort of a map. The first Roadmap was then created to help people to move around New York.

When using a Roadmap people always knew where they were (current location) and where they wanted to go (the destination). With a Roadmap in hands they could find different routes to get to their destination faster. “Product Roadmaps should work just like that, but they don’t”.

It was in the 1980’s that organizations began using the term roadmap in the format we still see in use today. The roadmap was a tool used to align technology and product development efforts with the purpose to inform customers and stakeholders about releases of new products or enhancements of existing products.

The main components of a Product Roadmap were and still are in most cases:

• Deliverables – Features, Solutions, Hardware etc

• Dates – normally months and quarters and in some cases very specific dates

• Priorities – the order to which the deliverables would be released

In essence, Product Roadmap became a tool to help organizations plan and communicate in advance, when they would be releasing new products or upgrades. It was also a way to ensure the team’s focus was on the highest business priorities and a way to track commitments.

This model has worked well for about a decade when things started to change quite rapidly. The rise of the internet and the adoption of lean and agile practices along with the ever-increasing pace of change in technology have made the traditional roadmaps a cumbersome and inefficient tool in many, if not all circumstances. However, the way most companies still create Product Roadmaps haven’t changed.

The annual cycle for Roadmap development started to clash with the rapid release cycle enabled by agile/lean development methods. (Figure 1)

What is wrong with it?

I have come up with a list of things that I believe to be the key problems with traditional product roadmaps:

• Output focused

• It implies certainty

•Date seen as hard commitments

• Misused as release plan

• Tied to annual planning

• It doesn’t embrace learning

Most of the organizations are still developing roadmaps, focusing on the output they plan to deliver. Output takes the form of features, system implementation, activities planned; however, they are not in any way an indication of progress towards the company goals and vision

Another key component of traditional product roadmaps is the dates. In my view, they are still one of the most misused components. Although they are not meant to demonstrate precision or hard commitment, they in most cases see just that.

The fact that most Roadmaps are tied to companies’ annual planning cycle is also a fundamental problem. This assumes that companies know exactly everything they need to build in order to achieve its objectives and goals but this is in most cases not true. This premise has been proven wrong many times.

Lastly, I would say the most important issue is how static roadmaps are. The fact they are built annually and rarely updated, reduce the chances of adapting and learning new things about the problems you are trying to solve, hence, its chances of success is reduced.

All of this would not be a problem if we were living in the scientific management theory - Taylorism age (Frederick W. Taylor) where:

• Senior Management of organizations knew what they need to build and how;

• Measures of success were simply quantitative output such as efficiency - the more they produce, the better;

• Management was responsible for measuring and improving the entire process;

• The premise was that the workers knew and cared nothing about the organization, what it was doing or why.

An alternative to traditional Product Roadmaps

“A Product Roadmap describes how you intend to achieve your Product Vision”, is a definition from the book - Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty.

It focuses on the value you propose to deliver and is used to rally support and coordinate effort among stakeholders. It is more than a list of features with some dates.

Vision, Goals and Themes

Your company or product vision should always come first – is intended to be your high level, the ultimate view of where the company is going.

Its primary purpose is to communicate this vision and inspire the teams and stakeholders to support and get behind it to make this vision a reality.

Company or product vision should be more a long term view. If you are thinking somewhere around 3-5 years, you are probably in the right ballpark. They will normally set the leadership and the good ones are typically inspiring and ambitious.

Next comes the goals. That should be the first business goal you have in order to achieve or get closer to your company vision. Here we have to start getting a bit more quantitative, and timeframe would be somewhere between 1-2 years. OKRs (Objectives and Key Results) are a great way of describing those types of goals with clear measurable outcomes.

Finally, we have what I call themes. Themes are the key areas the teams decided to explore to achieve the Company Goals. This could be a specific customer problem, needs or jobs to be done.

Two parts of the theme:

Hypothesis/Problem Statement – it we solve this problem or prove this hypothesis we will be closer to achieving our company goals

Outcomes – the key part of the roadmap – it describes quantitatively what we hope to achieve by solving this problem

I find that a quarterly cadence works well for this level.

Now - Next - Later

Once you vision, goals and themes have been defined you can then start thinking about how you are going to communicate when things will be done.

There are many ways to do this but my preferred option so far has been the “Now”, “Next” and “Later” format.

At the same time this gives the information you need to align expectations with stakeholders and customers. It also leaves space for changes, particularly with things that are not yet started. I encourage the use of broader timeframe to avoid creating a false sense of certainty about dates at that stage.

So when thinking about building a Roadmap for your organization I would recommend a few things:

1. Always tie your product Roadmap to your company vision and goals

2. Commit to outcomes rather than outputs

3. Favor the use of broader timeframe over precise dates

4. A product roadmap is not a project plan