Skip to main content

Outputs and Outcomes


What's the difference? Is the difference significant? And what should you focus on first?


An output is what we do. Words you see are the output of my process of writing. An outcome of my writing (if any exists) is what you'll learn after reading the words.

Outcomes are the difference made by the outputs 

And how is this relevant to a product development? 

Think for a minute how many things in our work environment is output focused. Number of hours worked, user stories delivered, number of releases, bugs fixed...etc. In business as well: number of unique visitors, ad campaigns, number of sales calls, customer support team workload...etc. And on a personal level: number of meetings we've been involved last week, number of documents we've produced, number of lines of code we've written... All those might seem important, yet focusing on them we very often forget about the outcomes. Does the number of meetings matter if you go out of them without completing the objectives? Oh, you still go to meetings that don't have objectives?... Does the number of lines of code matters if nobody uses the produced functionality? And yes - nobody reads your documents.

Everyone probably had one of those examples in their daily work. Why is it so easy to focus on outputs? Because outputs are in our field of control. Most outputs we can do on our own. While to achieve some positive outcomes we usually need the help of the other people. Rarely something great is created by a single individual. Even if your outputs are top notch, it's still not enough for some significant outcomes.

It's easier to monitor outputs as well.

  • How many lines of code? 
  • How many meetings? 
  • How many documents? 
  • How many hours? 
It's easier to monitor those outputs rather than the outcomes they produce.


But how about outcomes? 

Those should be the high level results of our work. The real value. The difference. Yet how often do we pretend outcomes are not measurable or not applicable to us? And the reason for that is pretty simple as well: it's very hard to admit that your hard work didn't make any difference. That all those hours, lines of code, meetings, documents... all that are wasted. We prefer to not measure outcomes or find/made up reasons to not link our outputs to the outcomes.

The relation between outputs and outcomes? 


  • Outputs of a sales person is a number of sales calls done. 
  • Outcomes are the number of closed deals
  • Outputs of a developer are the lines of code she's written.
  • Outcomes are solved problems for a user of a software. 


  • Outputs of a designer are the designs she's made.
  • Outcomes are satisfied users who get value from it. 


Outputs can predict outcomes but never can guarantee them.  There is always uncertainty regarding the relation between outputs and outcomes.

Measure both

One is certain - both outputs and outcomes should be measured. Why? Because knowing and understanding your outcomes shows where the most value being created. And by who. While measuring outputs tells a lot about how the value is being achieved. Therefore you can aim for more productive outputs to reach better outcomes.

Outputs are probably best measured on an individual level. While outcomes  on a team or a company level. Relations between outputs and outcomes also could be measured. It's better to measure this relation on an individual level. Personal effectiveness makes a huge difference. While for one employee 3 meetings needed to solve a problem, another one could solve the same problem with a 15 min. chat.

Wrap up

Output is what we do. Outcome is what we achieve. The difference we create. Outputs can predict outcomes, but cannot guarantee them. Both outputs and outcomes should be measured. Outputs on an individual level, outcomes on the team or company level. Understanding your outputs and outcomes you can better identify who creates the most value and how it's being done.

Learn More

Comments

Popular posts from this blog

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions. But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior?
BJ Fogg, from Stanford University, has created simple and powerful behavioral model for persuasive product design.


7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?