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.