To Know
-
Through the telescope
Outcomes over output
CALL To Health
—
Apr 2021
Let me start with my favourite definition of outcome. “Outcomes is a change in human behaviour that drives business results” This description was taken from the book “Outcomes over output" by Joshua Seidel.
Output is the stuff you deliver, but delivering stuff is different from delivering value.
In short, someone has an idea, that Idea is converted into new products or new features or improvements, etc. then into specifications or requirements.
After that, someone during a period of time will deliver the outputs of that work. At the end of a sprint, if you are working in scrum, or at the end of the project. Project done. Repeat the cycle.
In 2018, I was working in a digital transformation Project, in which one of the streams was dedicated to implementing a digital ID. Someone had an idea that every customer should have a digital ID that will allow users to access all his/her information in any channel, e.g. single login in all apps and portals and access to all the information. Amazing idea. The requirements were written, the flows done, war rooms with infinite diagrams, scrum teams, dev, UX/UI, QA, everyone.
The End result:
In the end, the project was shut down with “the stuff” in prod.
Back on outcomes. Did we change the customer behaviour? Yes, but in the wrong way. It doesn’t matter how fast you deliver quality outputs. The faster you deliver the more “stuff” you’ll have.
Outcomes should change Customer behaviour to increase satisfaction, usage, buying. Which leads to IMPACT in an organisation.
If you have a happy customer who enjoys your product and says good things about it, you will increase the impact through ROI, brand awareness, marketing share, etc.
We are usually focused on measuring the wrong things. Velocity, the amount of features you deliver in a period of time (the famous triangle: scope, time, cost). And sometimes we sacrifice quality to keep the triangle... as a triangle. Make no mistake, those metrics are essential for measuring time to market, team capacity, product quality, etc. However, we shouldn’t use them to measure the success of a product.
Outcomes have nothing to do with making “stuff” - though they sometimes are created by doing the right stuff.
Product gurus used to say to reduce outputs and maximize outcomes. Our job is not to build ideas fast, our job is to build the amount necessary to maximize outcomes.
Think about a product you really like. Now think about why you like it. I’m pretty sure it is not because it was delivered on time, or very fast, or within the budget or even because it has thousands of features that you don’t know exist. Am I right?
If you search for product vision, product strategy, design, etc, you will find hundreds of templates and articles. But in all you will find the basic:
Know your customers/ target >> identify their needs/ problems >> build the necessary features to increase outcomes (solve customer problems) and that creat impact >> make sure you can measure it.
Whatever project we are, there are four possible results (by Jeff Patton)
Deliver on time - Yes, outcome - Yes, result - you rock
Deliver on time - No, outcome - No, result - you suck
Deliver on time - No, outcome - Yes, result - you still rock (mostly)
Deliver on time - Yes , outcome - No, result - you suck (but no ones tell you to your face)
Final thoughts:
Sources:
Article by Rui Coimbra
Let me start with my favourite definition of outcome. “Outcomes is a change in human behaviour that drives business results” This description was taken from the book “Outcomes over output" by Joshua Seidel.
Output is the stuff you deliver, but delivering stuff is different from delivering value.
In short, someone has an idea, that Idea is converted into new products or new features or improvements, etc. then into specifications or requirements.
After that, someone during a period of time will deliver the outputs of that work. At the end of a sprint, if you are working in scrum, or at the end of the project. Project done. Repeat the cycle.
In 2018, I was working in a digital transformation Project, in which one of the streams was dedicated to implementing a digital ID. Someone had an idea that every customer should have a digital ID that will allow users to access all his/her information in any channel, e.g. single login in all apps and portals and access to all the information. Amazing idea. The requirements were written, the flows done, war rooms with infinite diagrams, scrum teams, dev, UX/UI, QA, everyone.
The End result:
In the end, the project was shut down with “the stuff” in prod.
Back on outcomes. Did we change the customer behaviour? Yes, but in the wrong way. It doesn’t matter how fast you deliver quality outputs. The faster you deliver the more “stuff” you’ll have.
Outcomes should change Customer behaviour to increase satisfaction, usage, buying. Which leads to IMPACT in an organisation.
If you have a happy customer who enjoys your product and says good things about it, you will increase the impact through ROI, brand awareness, marketing share, etc.
We are usually focused on measuring the wrong things. Velocity, the amount of features you deliver in a period of time (the famous triangle: scope, time, cost). And sometimes we sacrifice quality to keep the triangle... as a triangle. Make no mistake, those metrics are essential for measuring time to market, team capacity, product quality, etc. However, we shouldn’t use them to measure the success of a product.
Outcomes have nothing to do with making “stuff” - though they sometimes are created by doing the right stuff.
Product gurus used to say to reduce outputs and maximize outcomes. Our job is not to build ideas fast, our job is to build the amount necessary to maximize outcomes.
Think about a product you really like. Now think about why you like it. I’m pretty sure it is not because it was delivered on time, or very fast, or within the budget or even because it has thousands of features that you don’t know exist. Am I right?
If you search for product vision, product strategy, design, etc, you will find hundreds of templates and articles. But in all you will find the basic:
Know your customers/ target >> identify their needs/ problems >> build the necessary features to increase outcomes (solve customer problems) and that creat impact >> make sure you can measure it.
Whatever project we are, there are four possible results (by Jeff Patton)
Deliver on time - Yes, outcome - Yes, result - you rock
Deliver on time - No, outcome - No, result - you suck
Deliver on time - No, outcome - Yes, result - you still rock (mostly)
Deliver on time - Yes , outcome - No, result - you suck (but no ones tell you to your face)
Final thoughts:
Sources:
Article by Rui Coimbra
Let me start with my favourite definition of outcome. “Outcomes is a change in human behaviour that drives business results” This description was taken from the book “Outcomes over output" by Joshua Seidel.
Output is the stuff you deliver, but delivering stuff is different from delivering value.
In short, someone has an idea, that Idea is converted into new products or new features or improvements, etc. then into specifications or requirements.
After that, someone during a period of time will deliver the outputs of that work. At the end of a sprint, if you are working in scrum, or at the end of the project. Project done. Repeat the cycle.
In 2018, I was working in a digital transformation Project, in which one of the streams was dedicated to implementing a digital ID. Someone had an idea that every customer should have a digital ID that will allow users to access all his/her information in any channel, e.g. single login in all apps and portals and access to all the information. Amazing idea. The requirements were written, the flows done, war rooms with infinite diagrams, scrum teams, dev, UX/UI, QA, everyone.
The End result:
In the end, the project was shut down with “the stuff” in prod.
Back on outcomes. Did we change the customer behaviour? Yes, but in the wrong way. It doesn’t matter how fast you deliver quality outputs. The faster you deliver the more “stuff” you’ll have.
Outcomes should change Customer behaviour to increase satisfaction, usage, buying. Which leads to IMPACT in an organisation.
If you have a happy customer who enjoys your product and says good things about it, you will increase the impact through ROI, brand awareness, marketing share, etc.
We are usually focused on measuring the wrong things. Velocity, the amount of features you deliver in a period of time (the famous triangle: scope, time, cost). And sometimes we sacrifice quality to keep the triangle... as a triangle. Make no mistake, those metrics are essential for measuring time to market, team capacity, product quality, etc. However, we shouldn’t use them to measure the success of a product.
Outcomes have nothing to do with making “stuff” - though they sometimes are created by doing the right stuff.
Product gurus used to say to reduce outputs and maximize outcomes. Our job is not to build ideas fast, our job is to build the amount necessary to maximize outcomes.
Think about a product you really like. Now think about why you like it. I’m pretty sure it is not because it was delivered on time, or very fast, or within the budget or even because it has thousands of features that you don’t know exist. Am I right?
If you search for product vision, product strategy, design, etc, you will find hundreds of templates and articles. But in all you will find the basic:
Know your customers/ target >> identify their needs/ problems >> build the necessary features to increase outcomes (solve customer problems) and that creat impact >> make sure you can measure it.
Whatever project we are, there are four possible results (by Jeff Patton)
Deliver on time - Yes, outcome - Yes, result - you rock
Deliver on time - No, outcome - No, result - you suck
Deliver on time - No, outcome - Yes, result - you still rock (mostly)
Deliver on time - Yes , outcome - No, result - you suck (but no ones tell you to your face)
Final thoughts:
Sources:
Article by Rui Coimbra
.png)
