The problem with talking about the “value” of software is that it is often perceived differently by people using it and people building it. Users increasingly expect software to change. However, when building software products, we (the creators) often fail to accommodate these expectations, focusing instead on the elusive “finished” product. That creates a tension between what users want and what we deliver.
To remove this tension, we need to change the way we measure software value. We must measure software value based on the frequency of releases rather than their size. We must stop trying build software products like we build physical ones.
Most of us are used to buying and working with physical products and valuing these products based on their ability to resist change. Typically, quality purchases such as a Rolex watch, a Nokia 3310, a vintage car share a common attribute: their lack of change over years of existence.
Changing physical products is easy - you can always break your Rolex. However, change to physical products usually means degradation or additional expense. Because of this, people have grown to value resistance to change in our physical products. When adding valuable features to physical products is an expensive task, releasing product with a maximum amount of features becomes a core value proposition.
People regularly using software quickly learn to value products that change a lot. When people buy or subscribe to software, they don’t treat it as a one-off purchase, they treat it as an investment. They expect this product to change with their needs, at least for a little while.
Luckily, changing software products becomes easier every day with both the exponential increase of computing power and huge improvements in software development practices. Because of this, software users are growing to value a product’s ability to change over any other attribute. When adding features to software products becomes the norm, having more releases more often becomes a core value proposition.
People get upset when software doesn’t update often. This is usually because the systems around it, change fast. If Twitter changes its API, your twitter client must keep pace. If PayPal’s integration changes, your eCommerce shop needs to change with it. And even if no single integration pushes you to make rapid updates, you can be sure that your competitors will.
If you want a poster story to show how a product, and a brand, can suffer because of its lack of change, consider Things.
Designed as a productivity-boosting app, Things quickly grew a loyal customer base. Slowly, but surely, however, Things began to lose its fans. Complaints mounted about the app’s slow update cycle and lack of progress. Updates to Things are very rare, but each release is very significant and grandiose in scope and benefits. Why then, are users leaving in anger?
More frequent software change is not only possible - it is expected by users. I know many people that deliberately check the date of latest app update before buying it from an app store. Frequency of change can become the unique selling point of a piece of software.
Yet despite the risk of losing users, a lot of businesses still project physical value perception onto software. Success is based on releasing “finished”, rather than “changeable”, products. Because if the product doesn’t solve all the problems from the get go, “we wouldn’t be able to solve them later”. Because if the product doesn’t feel like a product built for years ahead then “people wouldn’t like it”. The problem is, by packing more features into a single release in many cases, our products become bloated and rigid, effectively locking businesses from what users value most - change.
We further complicate things by how we deal with legacy software. By suggesting all the time that the software needs to be completely rebuilt instead of gradually improved, we primed ourselves and the businesses we serve to treat software products like a physical ones. Software products are treated as an expensive one-off purchases that need to be replaced from time to time with a newer version.
I often find that teams that focus on regular and valuable updates meet and exceed their customer expectations much more often than the teams that pursue “finished” or “polished” products.
Remember, releasing early is more important than releasing finished. Releasing often is more important than releasing more.
So-called ‘lead time’ is one of the most important concepts in Lean software development. Lead time measures the amount of time that passes between when the feature development begins, and when the feature finally launches.
An often-quoted part of the Lean methodology is the build-measure-learn cycle, which helps to bring the idea of speed into product development. Sadly, when people hear build-measure-learn, they often bring the wrong perception of value into the formula, making “build” something opposite from just minimally measurable. I believe everyone can benefit from a slightly more explicit version of the cycle: