If you’re frustrated with roadmaps, if you feel you or your team are wasting time on slide-ware, if you feel your team is failing to deliver on a vision, if you’re a product manager looking for something better, skip to the solution.

What’s a roadmap anyway?

Product roadmaps evolved in an environment where the cost of minor failures is huge and major failures are catastrophic; where the pace of innovation is slow and steady; and where close co-ordination between teams is vital.

So much of our terminology and methodology in the startup world is inherited from the sillicon part of Silicon Valley.

Pioneers like Intel’s Andy Grove transformed their companies as much as they transformed startup culture.

In the hardware manufacturing world it makes a lot of sense to plan ahead. Hardware production is capital intensive and requires exceptional planning.

When a new hardware platform is invented, a process of incremental optimisation is required to augment user value and reduce bill of materials (BOM) cost.

Intel CPU Roadmap 2013_1

The familiar time on x-axis, gridded roadmap is a useful tool in environments where it’s possible, or absolutely necessary, to predict the future. In these environments, the cost of minor failures is huge and major failures are catastrophic (just look at the global silicon shortage caused by COVID related supply chain issues).

As Intel paired up with Microsoft in the 1990s to create the Wintel Alliance, hardware and software were locked together. So it still made sense to adopt hardware oriented roadmapping practices.

But then the Dotcom boom happened (1995-2000) and as fixed line internet penetrated deeper and deeper into societety (2000-2005) and as cloud platforms like AWS started to emerge (2006), software become firmly separated from hardware.

The agile manifesto was published in 2001 and, together with the technology changes highlighted above, set the scene for the explosion of cloud based software.

Software was finally free from hardware.

Yet, 21 years later the hardware-centric view of product roadmaps is still etched into leaders’ minds.

Hardware vs software innovation

Hardware innovation is different to software. With hardware, the cost of mistakes and failure is very high. With software, mistakes are how you avoid failure.

	Hardware	Cloud Software
Organisational complexity	High - significant supply chain.	Low - small software teams deliver major breakthroughs.
Pace of innovation	Major performance and/or value delivery breakthroughs every 5-10 years.	Major performance and/or value delivery breakthroughs every 5-10 months, getting faster.
Iteration frequency	Slow - limited by physical constraints, supply chains, financing, etc.	Very fast - limited only by human production.
Cost of failure	Very high.	Very low - when managed properly.

Good reasons to have a roadmap

For startups and scale-ups, having a roadmap makes sense when you know what you need to build, for example:

You’re operating in a a highly regulated industry and your MVP has a high bar and requirements that you must deliver to.
You have already validated end user demand for a MVP or feature that has some considerable technical complexity that cannot be decomposed further.
You need to co-ordinate multiple different teams in the context of supply chains and hardware launches.

The vast majority of teams working on product in 2022 do not meet these requirements and would be better off without a roadmap (a time ordered list of features).

The problem with roadmaps

Roadmaps built the Wintel Alliance and undoubtedly many other great companies. But the game has changed. Software isn’t about incremental improvements, its about >10x improvements that come as a result of lots of experimentation, trial, error and learning.

The way that many startups and scale-ups today use roadmaps is dangerous because, from most to least poisonous:

They create a false impression that we know what we need to build.
They obfuscate and therefore discourage the team from challenging key assumptions relating the value prop and business model.
They create a false sense of certainty in our ability to deliver a feature at a certain time.

What you really want when you ask to see the roadmap

Founders, CEOs and leaders ask for roadmaps for all kinds of reasons:

To align different teams / groups (particularly common in larger organisations, especially as B2B scales)
To sell to customers
To check on their team’s productivity / sense of urgency / etc
To make sure they have a strategy in place
To give to investors

These are all good reasons to take action. But a time-ordered list of things that will be delivered is not the best way to achieve the desired outcomes.

Roadmaps drive superficial alignment

Roadmaps are really effective tools to align different groups (e.g. sales and product) around. But unless you know 100% what you need to build, the alignment is fake. When we align around features we are not sure that we need to build we miss the opportunity to align around goals that will really make a difference.

Roadmaps don’t drive sales, they drive fragmented products

Remember, if you know 100% what you need to build, then put it on a roadmap and sell it. But for the vast majority of companies out there, the roadmap that gets shown to customers is a bet both of the ability of the team to deliver the features and the desirability of the features. It goes like this

We make a commitment to 10 customers to deliver a feature, only 2 want it, so we build it anyway. We do that 10 times, then we have 20 customers each using 10-20% of our feature set, which drives down our LTV and reduces our efficiency.

Roadmaps harm productivity and disempower teams

People perform best when they set their own goals and when those goals are >95% under their control. When people and teams take on goals outside of their control, success feels like a fluke and failure feels unfair. Teams are only productive when they own and understand the outcome they’re asked to deliver.

Roadmaps focus on the least important part of the strategy

Roadmap plunge leadership into the weeds. What’s really important is driving alignment behind a singular vision, ensuring each team knows the outcome its working on, ensuring there’s a healthy culture of experimentation in place, that assumptions are called out and tested. Looking at features that might be built in 6 months time adds little value.

Investors don’t really want to see your roadmap

My bet is that investors don’t really want to see what features you’re going to build in 6, 12 or 18 months time. They want to know if, as a founder, you’re able to take a compelling vision and break it into a sensible number of component parts that validate major assumptions one at a time, whilst keeping the team focussed on the next step.

What you really need isn’t a roadmap

What you need isn’t a roadmap. It’s a document that tells you, your team, your investors, your customers, your partners:

What your vision for your product / company is. What difference will you make in the world, for whom?
What you believe your business model might look like in the future and what the key assumptions behind it that need to be tested are.
What hypotheses you have about how you’ll deliver value to the customer, then lock in the value to creating a lasting competitive advantage.
What your focus is, so that your teams can focus their efforts on a common goal.

When you get this right, alignment comes from a shared understanding of the vision

Replace your customer facing roadmap with validation

It’s common in B2B enterprise products to show customers a roadmap in order to gauge their response and decide where to place bets. My experience is that rather than do this, the team (including sales and product) is better off:

Explaining the underlying data (quantitative or qualitative) that drives a proposed feature to the customer with the goal of validating their need assumptions.
Validating the customer’s willingness to buy with a painted door test (easy for SaaS but hard in true enterprise) or with a joint development program (JDP) (great for enterprise B2B).

Replace your roadmap with a product strategy

I challenge you and your CPO / head of product to burn your roadmap and replace it with the following:

A product vision that tells a story of the impact your product will make and shows what you believe each component of the business model canvas will need to look like to achieve this impact.
A prioritised set of assumptions and hypotheses - things that need to be true in order for your vision to become a reality.
A prioritised set of product hypotheses about how the product you build will help you create and lock-in value.
A North Star metric that drives your whole team towards a single customer behaviour that increments with value delivery to the customer.
A prioritisation framework that helps your teams make the right decisions, day to day, by delivering to the, the most important business context.

When you re-direct effort away from time-based planning (the old fashioned product roadmap) and onto the impact you want to have, your key assumptions about your business model and value proposition, and a methodical way to sate, test and validate assumptions, you’ll see dramatic changes, quickly.

Get help replacing your roadmap

I developed an 8 week product strategy course that gives you the recipe you need to build high impact products that users love, without falling into the roadmap trap.

Find out more here.

References and thanks

Photo by Emily Wade on Unsplash.

Gibson Biddle’s product strategy course helped me see the light.

Marty Cagan’s books gave me the confidence to push back.

Thanks to everyone who shared their thoughts on my recent LinkedIn thread.

Why Your Roadmap Isn't Fit for Purpose and What to Do About It