Eyes on the prize — outcome over output

By Jakob Wolman (originally published via Medium, April 2017)

Lately I have been thinking about why so many software development teams are focused on creating new functionality in a product, but know very little about how the product is actually used or what problems they are solving.
Inspired by Jeff Gothelf’s article on managing projects for outcomes over outputs I would like to share some of my thoughts on the topic.

Outcome vs. output
First, let us define what the difference is. Outcome is what customers are after (sometimes without knowing it). Most people do not want to buy a drill, they want holes. Most people do not want to buy a camera, they want photos taken. Applied to software there is (should be) a purpose with the software. “We want to use this website to sell more of our products,” “We want to use this software to run our business more effectively (by making data driven decisions),” “I want to keep up to date with what is happening in my community (by accessing social media on my phone).”

These are outcomes the customer is looking for. But we often focus on the output: the website, the app, the software. Even if we create a beautiful website, deliver it on time with state of the art technology — but it does not help the customer sell more of their products — we have failed to deliver value. Therefore, we need to focus on the outcome.

Focusing on the output

What I observe most teams do, especially in larger organisations, is focusing on the output. Their definition of being done is usually things like “code delivered” or “deployed to production”. In rare cases teams will actually have access to data telling them whether the feature they built is used. Even rarer, they will have seen their feature being used in the wild. The feedback loop stops with the product owner receiving the feature, and the team happily moves on to implement the next item on their backlog. This isolates the team from the real world and makes them live in a black box. Requirements go in, software comes out. The team starts focusing on writing code rather than solving problems.

Shift — focus on the outcome
What would have to change for teams to focus on the outcome instead? Here are a few ideas.

Outcome teams

What if teams were formed around outcome rather than output (feature, component, architect layer etc)? What if we had a team that was responsible for “making it possible for customer to sell more products” and gave them the freedom experiment with different solutions, learn more about this space and get a better understanding of how the customer currently does this.

Get to know the customer

Valuable to any team that builds software is to know their customer better. In larger organisations the distance between a customer and a software developer can be huge, especially if the software is not a consumer product. There are many easy wins here. Go out and meet customers. See how the software is used in the wild. Interview users about their pains and gains. Go looking for the outcomes your software enables.

Cross functional teams

By now most teams consist of everyone needed to create the output (developers, testers, designer etc.). We should extend this to include everyone needed to create the output (legal, marketing, sales etc.). This will enable the teams to go all the way, and close the feedback loop all the way from customers.

Definition of done

A feature is not done until it is being used. We should give teams a way to back this statement up with data, and even go further. When customers use this feature, what are they able to do that they were not before? Let the teams participate in user testing and customer interviews to get a better understanding of this.

Slice with outcome in mind

When we slice work we should make sure a little part of the outcome is in there. How can we slice work in such a way that we are able to deliver a tiny piece of value all the way to end users? Make sure that single piece of work goes through all instances (legal, marketing, etc) to learn as much as possible before starting the next piece of work. I really like the way design sprints are approaching this by making simple prototypes and testing them on real users in just a few days.

Gold at the end of the rainbow

I truly believe that working with a focus on the outcome will bring huge benefits. Team members will be strongly connected to their work. Buying in to the purpose and start solving problems. It is so much easier to give teams autonomy when they have bought in to create a specific outcome. With this comes the possibility of high work satisfaction and getting the full potential from every team member.

By focusing on the outcome team members will also be closer to innovation, being able to understand what Clayton M. Christensen calls “Jobs to be done”. By including the whole chain of events that leads to delivering value, the organisation will learn much faster, and fail faster.

What is your organisation doing that helps software teams focus on the outcome? I would love to collect more examples of how organisations achieve to keep a focus on the outcome.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.