First, it essential to establish the difference between outcome-driven product management and output.
Output focused product management has very linear roadmaps with features planned throughout the quarter or worse the year. Usually, there is a quarterly planning meeting, where stakeholders suggest feature ideas for the roadmap. In this product development style, the issue is that it often leads to a growing backlog and features that don't add value to the business—leading to waste in time, effort, and value.
Output-focused product management comes from manufacturing physical products with a uniform design between each production run. To affect business revenue in this situation, the variable that can be changed is producing more of a product. Therefore, output product management tends to focus on delivery efficiency.
The alternative is outcome-based product management. Outcome product management removes the focus from talking about features. Instead, what outcomes the business would like to achieve.
It is necessary to clarify what is meant by an outcome.
"An outcome is a measurable change in customer behaviour that adds business value."
Now what is often problematic is coming up with outcomes. "Let's increase revenue this quarter". This is not an outcome; there is a measurable component to the statement but not a change in customer behaviour. This instead is an endstate or business impact. An outcome would be " When customers visit the website, we want 40% of them to upgrade to premium membership." This statement has a customer behaviour component and a measurable component.
To build a roadmap, the impact - outcome chain can be used.
This is where we start with an impact and work our way down to outcomes.
First, we start with Impacts.
Impacts tend to come from leadership which is appropriate for that level as they are focused on the larger picture and not concentrated on the minutia. For this, we will go with "Let's increase revenue this quarter".
Next is the challenge:
This is an outcome that will deliver the measurable part of the impact. The challenge can come from the product team or product leader. for this, we will go with " When customers visit the website, we want 40% of them to upgrade to premium membership."
After the challenge its outcomes
The product teams come up with outcomes that will deliver the challenge. These outcomes are more hypothesis around changing customers behaviours and will require experimentation to validate.
To identify customer behaviours, the method of user journey mapping is a useful tool. Customers behaviours are mapped out in different paths towards the desired challenge. What can be taken from this method are positive behaviours and negative behaviours. These will form the basis for the outcomes that teams can work on changing.
How this all fits into a roadmap is what you are probably wondering by this point. Well, first, we must acknowledge product development is more of a journey in this style. In the diagram bellow the circle represents the current knowledge field a team will have. Within this field are the outcomes the teams believe will move them towards the challenge state.
As the teams work on an outcome, an prove or disprove a hypothesis, their knowledge field increases. This keeps happening until they reach the challenge state.
The roadmap is therefore made up of outcomes that teams wish to work on. Remembering that "An outcome is a measurable change in customer behaviour that adds business value." When the team complete an outcome, they move on to another outcome.
There are challenges with this style if the rest of the business is working in a more linear fixed feature date approach, often seen in sales lead organisations. If this is the case, then an alternative product development approach might be required initially.