Commerce, coffee, and value

According to Wikipedia, commerce is the exchange of goods and services that existed as part of the human story since prehistoric times. Before currency we used to barter, then we began to use currency backed by resources like gold, and now we use fiat money (currency backed by the issuing government).

As humans we’ve learnt that this is the way we exchange value. When I go to a particular coffee shop on a Saturday it’s because I judge that the value in the coffee given to me is better than the shop next door. I may even be willing to pay a little extra depending on the value provided. In this case, the value is the extent to which my taste buds are excited from the coffee.

An Espresso

Buying a coffee is a transaction. I pay my few dollars then get a coffee in return. Software delivery is a bit different. To deal with custom Software as a transaction is not only hard, it’s also counter-intuitive. We’ve all come across the cliche of spending hundreds of thousands of dollars on a technically brilliant software product that no one uses.
If you deem the value in a product is delivering a technically brilliant bit of Software that satisfies requirements on a spreadsheet. Then you may be able to conduct business using this transaction mentality, but be warned this is neither effective nor is it conducive to real value. Lean thinking and hypothesis driven development is a bit different than traditional commerce. As the cool kids say it’s a bit meta .

Lean development is about building the right thing. That is: to explore finding value is value itself. Explaining this to people who are new to Software can be quite difficult and sometimes as Software Delivery professionals we take this for granted. You see for many of us, we’ve be doing this Software thing for several years. So we understand that we have to learn quick and gather feedback effectively. For many people who have limited exposure to our industry this goes against the grain because it isn’t the way we have done business for centuries.

At times we need to ease into this thinking by making transparent the value in learning fast. A (probably unpopular) suggestion I propose is to document your experiments as they are done paying close attention to the result part of the experiment.This will make transparent to others what has been tried and the result of it. This way the learnings, key metric changes, tech discoveries of your experiments are made tangible, while ensuring there’s traceability. Eventually, as trusts builds within teams, you may be able to have more flexibility and freedom in running experiments and validating hypotheses. However, you won’t be able to effectively experiment without showing value in experimentation to begin with. So, go forth and try to provide _meta_value!