Through the telescope

Outcomes over output

Call To Health — Apr 2021 by Rui Coimbra

Understanding the difference between concepts and the benefits. 

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. 

Now, what is an output and where does it come from?

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: 

  • Testing with real Customers  - 90% of the users couldn’t register, the other 10% finish because they were a tech segment, however they would’ve given up had they not been in a controlled environment.
  • Even with the above results they insisted on going live, which led to increase of abandon during login, decrease of users and unhappy customers, decrease of online sales.

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?

How do we define what to build? 

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:

  • Why do we assume that we know what customers need without validating with them?
  • Why do we take so long to inspect what we are developing?
  • Why do we keep following the plan and don’t adapt the change whenever it is required?
  • Why is it so difficult to identify and measure value?

to-know-throughthetelescopes.jpg

Sources:

Escape the build trap – By Melissa Perry
Outcomes over output (Why Customer behavior is the key metrics for business success) – Joshua Seiden
User story Mapping – Jeff Patton