One of arguments that I repeat in different contexts is that our ultimate goal should be delivering value to our customers. At the end of the day it doesn’t matter how many lines of code or features we’ve built. What matters is how much value has been delivered.
The concept seems to be pretty challenging in software development communities. In Lean or Agile communities it gets closer to stating the obvious. Nevertheless we don’t do that much with the obviousness. Product development, portfolio management or work organization on a team level are oh so often all about efficiency and not much more.
After all it is way more difficult to assess value we deliver than simply count features. The interesting thing happens when we try to define what value is exactly.
The question we should hear over and over again but don’t is: value for whom?
A common setup is: a vendor a.k.a. a software development company, a client paying to have a product built and its users. There are obviously more complicated scenarios as well as simpler, e.g. a company developing their own product. I’ll focus on the scenario with three key groups of interest though.
Let me give you a few examples.
The software development company built a product for the client. It is high quality, it does the job and paying users seem to be signing up in big numbers. The only problem is that the client was toxic thus big chunk of people working on the app left the vendor. Despite the fact that value is there for the client and users the balance of value on the software development company is negative.
If I saw such a project at Lunar Logic I would find our way out of the arrangement. By the way, it basically means that I don’t consider value for a client / users as the ultimate goal we should strive for. There has to be alignment with value on the other end as well.
There is another product for another client. Again it was delivered with high quality, users really like it except they’re not willing to pay for the service. This time collaboration went exceptionally well. On the top of that the product was fun to build for the team. It seems that the software development company got value on their end. Users, to some point, too. But the client? Not really. This business doesn’t scale.
Should I as the vendor’s representative reject to build such a project? I mean, a product idea is always a bet so you never quite know how it’s going to play out.
The value equation is again imbalanced though.
Yet another product was built in a very collaborative manner with a high quality and both the software development company and the client were happy. Except the users wouldn’t come. Why was the client happy then? They treated the product as an experiment that should verify a hypothesis. Even though the product wasn’t a success the main goal was knowledge discovery and from this perspective value was there.
Once again one of the parties – users – didn’t get value, yet it doesn’t render the whole endeavor senseless.
Of course, an ideal case is when not only is it a win-win-win kind of situation but also each win is roughly equally valued by each party. My experience is that it doesn’t happen very often.
In fact, value for money metric would differ depending on how much one values money. If a few hundred dollars for a day of work of a developer seems to me like a fortune I would expect miracles for my money. If it seems like a decent or even affordable rate my expectations of value I’m going to get are different.
When you talk about value, make it clear what value you are talking about exactly.
To make such a clarification you first need to understand that there are different sorts of value and they are driven by different factors. Then a natural next step is to ask what these factors are. Once again it will differ much. It may be profits, employee retention, number of users, knowledge discovery, solving a problem that people have, or hundreds of different things. Only if you are able to tell which factors are important in a given context you can come up with reasonable measures of value.
Without that value will be an ephemeral concept that we can’t assess in any meaningful way.
This also means that we can have a discussion on how value differs for all the parties involved and which bits are the most important for us. Because most of the time we have to choose.
2 comments… add one
Adam Smith wondered why diamonds cost more than water. Diamonds aren’t vital to life, but water is. The answer accepted by economists is “marginal value” or marginal utility. It might bring some perspective. Economic value is subjective.
100% agree! :) Also I have noticed that defining value might be.. recursive task. For example team would be creating software for internal client (users, operations), so basically task would be define what value we would be delivering to them. However, they are delivering service to company clients, so instead we could search for how to maximize value for our company and company (external) clients. On the other hand, our external clients are delivering value to their clients… and so on. Most likely iterating further and further, impact of developed increment get’s smaller. Usually we tend to define value around our internal and external clients, but you know what? This exercise changes once you would buy your client or vice verso. Then more parties are subjected in search for value. So where is really the line we should look at? Are we really driven more by the line of contract or are we honestly searching for value?