I have said it before, but to meet peers at Lean Coffee in Stockholm is always very inspiring! My last visit was no exception. The question I brought to the meeting was the following:
”Value vs. Cost – How can we focus more on customer value than on cost?”
Actually this will be my third blog post on the topic of value, you can find the other ones here and here. This one will basically be my extended notes from the Lean Coffee discussion. Let’s get started!
A gentleman with beard and glasses started with referring to the work of Donald G. Reinertsen. His book ”The Principles of Product Development Flow” was mentioned to seek deeper knowledge. It was recommended to be read in short iterations for best enjoyment, apparently it is quite ”heavy”. You can also search for speeches with ”Don Reinertsen” on YouTube. I did, and I found this one that I watched and liked.
Cost of Delay
Back to the question about value. How can you ”see”, i.e., quantify value? One thing that Don Reinertsen suggests is to use ”cost of delay”. What is that? I’ve found this short three minutes introduction, that has this good summary: ”Put simply, cost of delay is a way of communicating value and urgency”.
The gentleman continued to say that you should test hypotheses to seek value. Form the hypothesis and try it out in a small scale to see what value it brings. This is often call to make a MVP (Minimum Viable Product).
To see what value something brings, you should have data. Preferably data that measure something before, and after you introduce the ”value adding thing”, for example in the form of a MVP. Now you can compare to see what happened, and also tweak the model you have for making hypothesis if that is needed.
Low hanging fruit
Some things are obvious that they bring value. For example by fixing bugs that customers have reported.
Big aha moment
I’ve saved the biggest aha moment (for me) to last. There are so many things you can do before you even start to write any software! Being a developer from the beginning ”write some code” is always the easiest option to go for. Please don’t do it! Instead you should try out the ”value adding thing” on your peers. Discuss with them, what they think. They don’t understand? Maybe you need to formulate yourself better by doing some written text, or some wireframes.
One question you can use to ”see” value is the following:
”If we had this function/feature today, what would that mean?”
That could give answers like: ”X % more users” or ”Y % better response times”. Get two to three of those answers for each feature you are discussing and you can start to compare and prioritize between them. The answers don’t have to be the same for all features, the human brain can see patterns anyhow, even if it’s not a quantitative comparison.
Hopefully you now have some more ideas on how to work with value, at least I have! A huge thanks to the gentleman that kindly shared his knowledge. Do you have any other ways to work with value? Don’t be afraid to get in touch and share them!
All the best,
Tomas from TheAgileist