Outcomes Over Outputs

After reading Lean UX¹ I became convinced of the immense power of describing work to be done in terms of "outcomes over outputs." It seemed a crystal clear distinction when I was sitting in the classroom discussing it with others who had just finished the book as well… but I've found it a challenging concept to convey to someone who has not been seriously studying it.

Imagine with me that you are in your kitchen with someone who is waiting for your direction. There are a couple ways you could give direction to your little team… and hopefully I'll be able to persuade you why you may want to consider leading with outcomes over outputs.

1. Make a peanut-butter and jelly sandwich.

This is a description of a straightforward output. You just told the person what to do. No creativity or initiative required of your team.

1. Take two pieces of bread.
2. Cover one with peanut butter.
3. Cover the second with jelly.
4. Place the two halves together.

The final outcome of these actions is a peanut butter sandwich.

If you were shooting for giving your team an outcome… this is short of the mark. An output prescribes the way the goal is accomplished. Here you are describing what to do, and how to do it. A true outcome is a measurable set of goal criteria… that doesn't specify the output.

I'm hungry for two pieces of bread, with peanut butter and jelly in the middle. I, a user, would be pleased if you combined these somehow.

Closer… we are getting further towards describing a desired user outcome, but you are still cheating and prescribing an output. Try again.

I'm hungry, and I need to eat sometime in the next hour before my next meeting. I'm allergic to shellfish, but otherwise have no dietary requirements. Here's what is in the pantry, and here's a history of what I've liked and disliked for lunch in the past.

Finally… this is describing a user outcome: a set of measurable success criteria with some optional boundary conditions. When the user is no longer hungry and enjoys their meal… then the mission is accomplished. There is not a specified thing to make or task to be done, instead you describe a measurable set of success criteria, leaving your team free to creatively solve within those boundaries.

Why is this important?

It depends on who is standing in the kitchen with you. Is it a 5-year old, or a Michelin-rated chef?

Carefully detailing the steps for making a peanut butter sandwich makes perfect sense if you are working with a 5-year old… but if you are working with a talented chef you are preventing yourself from getting the best possible output by restricting the output's description up front.

If you are leading your product team by prescribing outputs, you are currently asking for a PB&J when you could be having the best meal of your life.

It makes no sense to specify a restricted output if you trust the people around you to provide creative value and diverse perspectives. If you specify an output instead of an outcome, you rob yourself of the opportunity of a better result than you could imagine alone. Worse, you insinuate that you don't trust your team's ability to solve problems.

Next time you are cooking something up in your product reflect what you are telling your team by what you are prescribing, and seriously consider experimenting with describing work to be done as an outcome instead of an output.