Outcome-based product roadmaps

Welcome to the Product Digest – our regular wrap up of the issues, trends and themes driving the world of digital product strategy and management. In this edition, we’ll discuss how following a traditional feature-based roadmap is likely to lead you to a dead end, or even off a cliff, and why embracing outcome-based product roadmaps is your best bet for getting where you want to go.

Wait a sec... how did we get here?

If you’re part of a team who are diligently following a product roadmap, but feel it might be leading you down the wrong path, your suspicions are well founded. Before we discuss how to get back on course, let’s look at the typical journey that product teams find themselves on.

When a team first adopts agile methodologies, they’re usually pretty quick to create a backlog of features, introduce all the usual ceremonies – sprint planning, daily standup, retros, etc. – and start delivering work in two week sprints. The belief is that by only ever planning work in these small increments, the team can change tack quickly – hence the name agile.

However, the product team still has to integrate with the rest of the organisation, and if the organisation is run in such a way that values certainty and long term planning, the product team will start to feel those pressures. Soon they find that stakeholders from across the organisation want to be kept informed about the development of the product, regularly being asked questions such as:

“What features do we have planned?”
“When is that really important feature I asked for being launched?”
“Can we have a budget breakdown for the next year?”

Often these questions are being asked by senior stakeholders in progress review meetings, where projecting confidence and certainty is basically considered non-negotiable. The product team quickly realise they need a method of communicating their product development plans to the wider organisation, so they create a product roadmap.

The simplest format for a roadmap is to show a timeline for the next few years, highlighting the features they hope to release and their potential release dates what’s commonly known as a feature-based roadmap. They know that the features and dates are all likely to change, but it will help keep everyone informed… and off their backs!

‍

‍

The problem is that, to everyone else in the organisation, the roadmap looks a lot like a project plan.

Pretty quickly, the features and delivery dates on the roadmap get stuck in people’s minds. Even with the product team’s best intentions, plans become rigid, budgets get frozen, and before they know it, the team aren’t working with any agility or flexibility at all. They are simply delivering a waterfall project in two week increments.

Why do feature-based product roadmaps ultimately fail?

The example above, although hypothetical, demonstrates just one of the ways that a traditional feature-based product roadmap can derail a product team.

As mentioned earlier, product roadmaps are typically created so that a team can communicate what they are planning to work on to their wider organisation. The reason that these roadmaps fail is that this line of thinking is deeply flawed.

Digital products, unlike traditional projects, are subject to so much uncertainty that a successful plan is never guaranteed; if anything, long term planning of digital products is almost guaranteed to fail.

The modern technology landscape moves so quickly that planning months or years in advance is futile; business models get disrupted, new technologies enable new competitive advantages, and customer expectations are always evolving. What was once considered innovative can quickly become irrelevant.

‍

‍

Then there’s the question about whether users will even want the features we have planned in the first place. As Janna Bastow, CEO of ProdPad, puts it, “The further out that timeline stretches, the more you’re making things up.”

Planning what features should be developed in the months or years ahead means you are not able to anticipate and solve the problems that your customers are having right now. The team’s focus needs to be on delivering features of value, not delivering features predictably.

That said, the uncertainty around how long a given feature will take to be delivered is another key reason that feature-based product roadmaps fail. We can’t say for certain how long a piece of functionality will take to deliver until it is fully understood.

‍

"The team’s focus needs to be on delivering features of value, not delivering features predictably."

‍

This is even more apparent when a team gives a delivery date for features that have not yet been fully defined. If the team hasn’t defined what it is yet, how can they possibly say with certainty when it can be delivered?

Once senior stakeholder expectations are set, the team are pressured into delivering on time, regardless of whether the feature is delivered to the fidelity they had intended. If the team decides to stick to their vision of the feature, then senior stakeholders become frustrated that the feature is late and the roadmap is slipping.

Hopefully you’re beginning to see why the ability to forecast what features are required and how long they’ll take is simply not possible.

Where are we heading again?

It’s important to note that it’s not just the features on a product roadmap that can cause problems, but also the intended destination. Often, that destination is the team’s vision of their ‘perfect’ product, which can be a dangerous path to follow – see our previous digest on the dangers of falling in love with your product.

Every modern product team should be focusing on their intended outcome for both the users of the product and the organisation.

The first step in making this transition is to change the team’s focus, from defining features to defining the outcomes they hope to achieve.

‍

‍

Focusing on outcomes

Before we go any further, it’s worth defining what exactly an ‘outcome’ is in this context. Simply put, achieving an outcome means achieving a measurable change for the better.

We can think about outcomes both for the user of the product and for the organisation. In the case of an organisation, a desired outcome might be a 10% improvement in average revenue per customer. For a user, it might be to reduce the number of steps in the purchase process from four to two.

The outcomes that the team seeks to deliver should always be driven by the organisation’s vision and goals, to ensure the actions of the product team are helping the organisation get to where it needs to go. Therein lies the real destination that the roadmap should be leading towards – not to a point in time where a list of arbitrary features have been delivered, but to delivering a meaningful positive impact for the organisation and the users it serves.

So, once everyone is aligned on what the destination looks like, how do we get there? Now is the time to relinquish the traditional feature-based product roadmap and move to a roadmap that focuses on outcomes.

The outcome-based product roadmap

An outcome-based product roadmap is a great tool to unite product teams and organisations around a shared vision. In simple terms, the roadmap shows the outcomes the team is looking to achieve in the short, medium and long term, rather than specific features.

‍

‍

Going back to our hypothetical product team, by adopting an outcome-based product roadmap they can solve the original problem of needing to communicate their plans to the wider organisation, while not sacrificing their ability to be agile.

The greatest challenge is not in creating the new roadmap, it’s in gaining trust from senior stakeholders. This new approach only works when the team is empowered to find solutions to the goals they have been set – attempts to micro-manage the team will only lead back to old ways of working. Instead of dictating what the product team should be working on, their approach should be to challenge the team’s thinking around the problems they’ve been set, and to coach them towards delivering successful outcomes.