Cursor Curated
5th February 2024

All roadmaps must die

Plans without action are little more than wishes

Cursor Curated Issue 26

Daniel Westlake

Have you ever felt stranded waiting for a taxi that’s inexplicably delayed? You call the firm and they tell you ‘it’s on the way’. There’s no way of knowing if the driver’s lost or they forgot about you – you just have to wait and see what happens.

We see this kind of attitude in software and product development all the time. Instead of saying the taxi is on its way, we say ‘it's on the roadmap’; which means it might be planned but we can’t give you any more details or indeed make a firm commitment. With the best intentions, plans without action are little more than wishes. Sean Sankey summed it up best: “The purpose of a plan is never to deliver the plan. It is to deliver alignment and momentum.”

So how can we apply this to software development? Is it time to abandon the stale ‘roadmap’ model and move to something more sustainable and realistic? As we plan for the year ahead, let’s try a different approach.

What is a roadmap?

First things first – what is a roadmap? Done right, it’s a strategic communication tool for team members and stakeholders. Done wrong, it’s as useful as one of those out-of-date Gantt charts – causing problems for every stakeholder. For example, we might see sales and marketing teams planning around product release roadmaps, only to find that the expected release dates are constantly changing.

Features of a good product roadmap

Rather than an overly detailed release plan or feature list, your roadmap should focus on high-level themes. These might include:

Business strategy and objectives
How it generates value
Market context
Delivery

Your roadmap should explain your business vision with a hypothesis for how it will generate value. Consider: “We believe that ______ will achieve ______. We’ll know we’re successful when _____.” This template will outline deadlines, constraints and features. If it doesn’t have these, it’s a project plan.

Finally, plan for the unexpected. We don’t know everything at the beginning of a project, so this will help to manage expectations. Remember, without a roadmap, everybody will interpret the project differently, often going for the easier tasks first. A product roadmap looks at the bigger, strategic challenges and keeps everybody informed, saving busy teams from being taken away from their tasks.

So where do roadmaps go wrong?

One of the biggest problems with roadmaps is that they tend to be synonymous with ‘backlogs’. They become a list of features that we never get around to building. If teams aren’t aligned, this becomes a bigger issue for managing expectations.

Consider, for example, a salesperson telling a customer that their desired feature is “on the roadmap”. In reality, developers may be stacked with other work. What’s important is to maintain communications with all team members and stakeholders – otherwise, they become a list of broken promises.

The elephant in the room

Quite plainly, vision always outstrips capacity. We’re forever wanting more than we can deliver. If we’re adding features to an imaginary roadmap, then we’re essentially ignoring the available resources we have in favour of wishful thinking. It’s better to be realistic with customers, even if this results in uncomfortable conversations.

This brings us to the ICE model. It means we accept that we cannot do everything our clients are asking of us – but we can prioritise the most important tasks.

The ICE model in action

The ICE model comprises Impact, Confidence and Ease. We start by rating a feature or initiative out of 10 for its impact, then our confidence in the feature and the ease of implementation. Multiply the three numbers to get a final score. When you have several features, you can then order them by priority like so:

The true value in this is recognising your confidence in a certain feature. We can all make educated guesses about the impact and ease of a task, but if we’re not confident, then we won’t deliver. You can find out more about this with Itamar Gilad’s Confidence Meter. It illustrates the factors needed beyond people’s opinions, including:

Plans and estimates
Market data
Anecdotal evidence
User and customer evidence
Test results and launch data

Conclusion

A product roadmap is by no means something to be feared or discounted – but it needs to be done right. This starts with setting expectations and acknowledging that even the largest software development teams cannot do everything.

So, how do we set expectations? We move away from vague promises like “it’s on the roadmap”. Instead, we ask customers what impact this feature would have on their business. If they cannot answer such an open question directly, we can give them a survey to complete to back up their request.

We need to be mindful of our confidence in every new task before we get going. If you’re planning for the year ahead, one of the most important questions to ask is how confident we really are in a decision. Every change needs to be based on data, not just opinions.

This year, encourage your teams to gather evidence to support every change. Pretty soon you’ll be on the road with confidence and a real direction in mind.

Articles, tips and knowledge delivered straight to your inbox