From feature roadmap to outcome roadmap

It is not the features that determine the success of a product, but the outcomes that are achieved with it.

These outcomes should also reflect the roadmap of a product. However, in my work with experienced agile product managers, I often encounter roadmaps that only contain features. To change this, the following 6 steps have proven successful for me. They provide concrete guidance on how you too can transform your feature roadmap into an outcome-based roadmap. In this way, you put the customer benefits in the foreground and at the same time remain meaningful to the stakeholders.

Step #1: Start with the desired business outcome

The path to an outcome-based roadmap starts with the correct application of the Logic Model.

We use this impact model not from left to right, as is traditional, but from right to left.

The first question you need to answer is: “What business outcome do you want the product to achieve?”

The business outcome – the impact – is the result the company wants to achieve by developing the product. It could be, for example, improving the Net Promoter Score, increasing the retention rate, reducing the churn rate or increasing sales.

Having defined a business outcome, the next step is to identify the user and customer behaviours that contribute to that business outcome. We refer to measurable user behaviours that influence business results as outcomes. Therefore, the next step is:

Step #2: Describe the outcomes for the users

This is often very difficult.

My tip is to look at how users are currently using your product. If there is no product yet, then look at how and with which tools potential users are currently achieving their goal.

To do this, work out the customers’ contact points with your product or service. Go through all the stages of the product and record in yellow how users interact with the product or what things they do to achieve their outcome. This overview now represents a very simple model of how users use the product.

Now mark in red the things that make users unhappy or that could make the product a failure, and in green the things that make customers happy and that could make the product a success.

The experiences that users have that make them happy and unhappy, those are the outcomes!

Step #3: Prioritise the outcomes

The next step is to prioritise the outcomes. What are the behaviours you want to see more of from users in the next year? Which behaviours do you want to reduce and in what order should you work on them?

• HR staff are more likely to find suitable candidates during the initial screening of the candidate profile.
• Shorter response time to queries about vacancies.
• More employees refer their acquaintances and friends.
• The specialist department conducts more specialist interviews.

Step #4: Create a roadmap for one and a half years

The prioritised outcomes now form the backbone of the outcome-based roadmap.

It is important to note that the time horizon of the planning should always cover the next six quarters. In this way, you are able to provide annual forecasts to stakeholders from the budget, finance, project management or HR departments at any time.

The features that were on the old feature roadmap can now be assigned to appropriate outcomes. Only features that are in the near future should be assigned to outcomes. No features should be on the roadmap in the distant future. Since the future is characterised by uncertainty in product development, there should rather be open questions or problems that you still have to answer.

Step #5: Formulate initial hypotheses

The problem with impact models is that they suggest that there is an obvious relationship between feature and outcome.

Predicting this relationship in advance only works in very few cases. In most cases, connections can only be explained in retrospect. Therefore, you should understand the connection arrows in the Logic Model as hypotheses. The features that can be developed are first of all assumptions about how an outcome can be achieved with the user. These assumptions need to be tested with experiments. A hypothesis could be something like this:

We believe that the business department will appreciate the value of HR more if HR staff are more likely to find suitable candidates during the initial screening of the candidate profile. They will be able to do this if they have attended an overview course in machine learning (ML) and AI.

The hypotheses arise when trying to answer the questions on the roadmap. The concrete formulation of hypotheses now enables the product teams to drive the discovery and development work through the outcomes for users.

Step #6: Make progress measurable

How much outcome is enough to improve the business result and when is an outcome achieved?

These are the most common questions in my Professional Scrum with UX training. This is also the root of why it is more challenging to work with outcomes and why many shy away from it. Measuring the success of features, the output of development, is simple. The answer is binary. Did the team get the feature to market on time? Within budget? That’s easy to measure and easy to determine.

But if we go by outcomes, we are dealing with a wide range of possible outcomes. Have we reduced the response time to queries by 50%? What if it has only been reduced by 38% to date? Is that good or bad? I don’t think we can always pinpoint this in advance. We would be better off making decisions based on the evidence we gather over time. These are also hypotheses that need to be formulated:

We believe that reducing the response time to queries by 50% will lead to the professional department being 25% more satisfied with the work of the HR department.

In summary, the basic idea of an outcome-based roadmap is to determine the success of the product by the outcomes of the users, to take these outcomes as a basis for planning and to understand everything as assumptions that can be formulated as questions and hypotheses.

Notes:

If you liked this article and don’t want to miss another one, follow Simon Flossmann on LinkedIn. A new article by him about agile product management and Scrum appears there every Monday (in German).

Here you will find more information on the topic of the roadmap.

Simon Flossmann has published two more articles on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.