Outputs v Outcomes

We know software development industry is focused on solving problems. Customer problems. User problems.

Better, faster, cheaper.

There is a great article in the Harvard Business Review on Outputs v Outcomes:

https://hbr.org/2012/11/its-not-just-semantics-managing-outcomes

Outputs are features.

Outcomes is true value delivered.

We aim for our outputs to deliver outcomes, its treated as an abstraction. The problem in most cases is, development teams treat outputs as the end goal, and build release plans, and sprints on getting that “feature” out.

We don’t talk enough about the problem we’re solving, the outcome we’ve aiming to achieve, and even more so, measure whether we achieved the outcome.

I am not a fan of measures such as “Increased usage”. Thats not an outcome.

An great example I’ve seen in building Recruitment software is Time to fill (TTF). TTF is the time it takes to fill a vacant seat from when the request is made. TTF directly translates to Cost to fill, which is a measurable impact to the company.

For a recruitment team, Time to Fill is THE KPI they are measured on.

So rather than building a feature or product we “think” will improve TTF, measure it, try different ideas, and keep trying until you find something that gets your outcome.

None of this is groundbreaking, all we’re doing is ensuring we connect our problem solvers (product teams / developers) to our users. It is fundamentally Agile.

Leave a Reply

Your email address will not be published. Required fields are marked *