Shared: Is the Distinction Between Outcomes and Output Overdone?

In about half the conversations about agile, I hear someone make the point that “teams should focus on outcomes rather than outputs.”

It’s gotten to the point that I’m tired of hearing it, especially because I somewhat disagree with it.

I know that’s blasphemous to say, but hear me out. To start, let’s be clear about the difference between the two words.

An outcome is a result. It’s something a team or product has achieved. An output is something produced along the way. The output isn’t always important in and of itself, but it leads to the outcome.

Mike Cohn: Is the Distinction Between Outcomes and Output Overdone?

What a timely post by Mike Cohn (who I received product owner training from way back in the day – a great course by a great trainer and practitioner.) I was just harping on talking about this with our technical product management team at work the other day. My take was that we were too focused on outputs and spent little time focusing on outcomes. Examples of this behavior were spending most of our time discussing team velocities, sprint commitments vs. delivery, and celebrating success as completing something on time and on budget. None of these areas are bad to track. Team velocity is important to know for planning and as one indicator for determining team performance. Sprint commitments vs. delivery can be one input in determining the health of a team. Celebrating success when things are delivered on-time and on-budget is good, as long as that is not the only thing being measured and celebrated.

To Cohn’s point, outcomes are a trailing indicator, while outputs are a leading indicator. It would be foolish to only try to measure based on outcomes. We don’t need to pick “sides”. But overemphasizing outputs can lead to missing the real impact we’re trying to deliver with our software development efforts. I’ve seen this happen time and time again, especially in Agile/Lean software dev teams where they are optimized to deliver software but not necessarily measure the outcomes. The number one reason I hear for measuring outputs and not paying much attention to outcomes is that getting the data on outcomes is difficult. Gathering data on outcomes is normally difficult because it is not prioritized. We want to build the new feature, fix the bug, launch the new product and in order to do that ASAP, we remove “superfluous” items like ensuring we have ways to measure the outcomes of our work. This is a mistake.

Yes, there has been a lot of emphasis on measuring outcomes over outputs, and, yes, it has been overstated at times. However, my theory is that if you asked most agile software development teams how they measured the success of their work, a majority would have little to no outcome-based measurements. And the danger in placing so much emphasis on outputs over outcomes is that we deliver things that don’t really matter for our customers and businesses.