Product Roadmaps - In the Self-Driven Car Age

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