What the heck is value? Obsess with it, but then forget about it...
Note: this is a two-part series. The first one is here, where we started with some basics on how to estimate value. Here comes the sort of plot twist though…
Now that we, with the previous post, learned some of the basic discipline of grounding value on more concrete terms, to be able to answer questions of funding and ROI, I have to break it for you: it actually matters less than perhaps you thought about. After you went through the ropes – to be clear, which I still encourage doing because of how it can change conversations on whether we should pursue something or not – from an execution point of view, you can just forget about it.
There. I said it – obsess with value, but then forget about it!
I know you might be looking at this now and thinking I'm crazy or something. Bare minimum sounding counterintuitive, if not contradictory. I only ask a bit of benefit of the doubt, and allow me to explain myself bit by bit.
Here's a short story. I know someone whose part of the job used to be following up after some investment was made in a big corporation, including changes in operations as well as technologies used. The company wanted to understand whether there was return on the investment just in line with when the original idea was pitched, and there was a kind of business case supporting the prioritization, typically alluding to hundreds of thousands of money per year of gain, when not already in the range of millions.
Very healthy thing to do which many organization skip, by the way. But can you imagine the leaders face when they found out that more often than not, the business case justifying prioritization was largely inflated? (And that's likely the understatement of the year, but let's be gentle.) I'm talking about the difference of hundreds of thousands or even millions of estimated value, against a few grand (in the low thousands range) at best of value realization.
So that's the first point – whenever we estimate upfront the expected value of something, we need to be humble and approach it as a probabilistic thing. And we will often be wrong about it.
That brings me to the next point, the other fundamental assumption we tend to make, and again we will often be wrong about it, is duration (how much time we think it will take us to to finish something; technically also known as cycle time).
Let me make a small bet here. Whenever I started talking about estimating value and alluded to using that to ground decisions on priorities, chances are that in your mind you were doing the connection: we now know about value, we can know next about how much time it will take us (or a proxy of it like an idea of effort), and that's what we can use to frame decisions on priorities – value weighted by time / effort.
It's logical thing to do. And it would absolutely be fine IF (big assumption) only we could confidently upfront "put our fingers on" estimating those two dimensions: value and duration.
But let's be honest – when was the last time things played out that way? I told you the short story about how often we can be wrong in estimating value. And for duration, perhaps you already have a good grasp on base on your own experience. In case not, you might want to look at the illustrated example of a simple simulation game I shared before, as I can almost bet that you are not doing one thing at a time, all the time.
Once we accept those uncertainties as a reality we need to deal with, a couple of fundamental things may start "clicking" on our minds.
The whole game becomes about how can we learn faster whether we are wrong.
That's why to me anyone responsible for optimizing for value (like some responsible for a product) needs to obsess about flow. It's the best chance we get to increase our chances to deal with those inherent uncertainties in ways that enable us to learn faster and our way to actual realized value.
In case only words won't convince you, perhaps another little simulation game can help out (for a more robust simulation, you can check out Drunk Agile – Don’t be a Ditka).
Imagine we have 20 options (deliverables) we could prioritize for the next 40 weeks of work. They all have been estimated on value (for the sake of this simulation, randomly between 0 and 10,000 "moneys per unit of time"). We also have estimated duration (ramdonly assigned for the simulation between 1 and 20 weeks of work). We initially prioritze on the basis of value per duration.
What happens in different scenarios with varying one or both dimensions (value and duration – afterwards, as actuals)?
Simulated data
Results
Using the prioritization schema of value per duration, and assuming both our estimated value and duration were sound, we would be able to accomplish the first 7 options in the ordered list, which would translate into a little over 41,000 "moneys per unit of time" realization of value.
First we make duration uncertain by re-assigning it (ramdonly, with the same parameter as before, between 1 and 20 weeks of work) across 20 test runs. That changed the expected realized value (assumed as the same as estimated upfront in this case) towards ~16,500 "moneys per unit of time" in average. That's to say, the uncertainties in duration alone had an impact of 60% on value realization (in this case, for the worse, hypothetically in reality it could go in our favor).
Next, we can make value uncertain by re-assigning it (ramdonly, with the same parameter as before, between 0 and 10,000 "moneys per week"), and repurposing the same 20 simulations of before on duration, we got a slight increase on actual value realization towards a average of ~17,500 "moneys per unit of time". So in this case, the uncertainty in value played in our favor (but it could have gone the other way).
Finally, we completely forget about value for prioritization, and just focus on finishing the shortest option first (essentially following the hypothesis that what maters most is to be able to learn faster). That was done by using the actual duration (re-assigned randomly between 1 and 20 weeks of work). In our simulation, that nearly doubled our value realization towards ~34,000 "moneys per unit of time" (so that,s nearly doubling).
What to make out of this, then!?...
So, there you have it an illustration of the idea that what truly matters in the end is learning faster whether we are wrong. But there's one more thing…This wall also alludes to what else can we do in attempt to optimize for value, which is the idea of right-sizing.
By making sure things are small enough (while still being considered as potentially valuable) to flow smoothly and fast through our delivery, we increase our chances to get more value realized.
To be clear – right-sizing is not something you do once, before pulling something to work, and then forget about it. It's something you can actively work on as part of prioritizing WIP: if something was deemed small enough but still is taking longer than we'd want to, is there anything we have learned along the way that could lead us into further review the scope (so a sort of continuous right-sizing approach).
The way I like to think about it is by "working backwards" from value towards more controllable inputs that are in our realm of direct influence. Just like illustrated below.
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.