The false dichotomy of output vs outcome
3 min readHello, not terribly avid readers, long time no post! Ironically in a blog post about outputs and outcomes I’ve really been awfully lax posting to this blog. Put it down to my in-progress MSc and juggling more than a circus cephalopod. However, a tweet caught my eye today and I felt compelled by the power of the internet to respond.
The tweet in question is similar to many I’ve seen (tweet omitted to protect the innocent) where a product manager extolls the virtues of outcomes vs output. Optimise not for output (velocity) dear friends but for the outcomes (value).
Now, these are words I’ve uttered myself from time to time and felt pretty good about it too. I’ve guided the unenlightened to the righteous path of value delivery. But as you may infer from my tone and the title of this post, that somewhat gives it away, I’ve come to a more nuanced perspective.
This perspective has been solidified by watching several teams struggle to ship anything! So obsessed with the value that nothing gets done or the cycle time to delivery rivals that of the big bang waterfall projects of old.
When challenged about the lack of actually shipping, the old saw of outcome over output is normally invoked. We have to do more research, internal tests, iterations and so on because we’re optimising for an outcome. We have to ensure we get the outcome we envisage.
Part of the problem here is the need to get the “outcome you envisaged” as if the outcome is ultimately knowable. But of course to know something we must have the thing in front of us so that it may be knowable. We cannot know things that don’t exist, we can only infer their existence.
The code is just a text file until it is run, and only in its running do you find the bugs in the code (or its outcomes) or its effectiveness. The code until running is not knowable in a material way. The materiality of the object emerges from the running of the code.
And there we have it, the rub, the outcome is nothing without output. The issue is that they are mutually dependent. You cannot push one without the other. They are in correspondence and more than that they are slippery and complex. Not suited to a binary opposition at all.
So the next time you or someone else invokes this false dichotomy, stop for a moment to think – has the talk of outcome just become a hackneyed old refrain used to justify a lack of output. Because, and here’s the kicker, your outcome is utterly dependant on you actually shipping and you cannot know the outcome until it has been output.