We're measuring software value the wrong way
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.
Physical products resist change
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.
Software products are increasingly more changeable
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.
Users expect changeable software
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.
But we often plan software products like they resist change
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.
Successful software products are built for change
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:
1. Optimise lead time
How long does it take for business idea to became a used feature? Measure and record your average lead time to help build a starting point for improvement. Regular, valuable releases are important. By focusing on improving lead time, you will naturally begin to change the way you evaluate development progress.
2. Reduce scope
Prioritise the features (or parts of features) that will yield the fastest and clearest feedback.
MVP or Minimum Viable Product is a term used a lot in software development. In theory, an MVP should launch with enough features to satisfy early adopters. However, I have seen the term MVP used to mean a product that satisfies internal stakeholders enough to be released.
This undermines the very idea of an MVP. The viability should be focused on the users, and not its creators. Instead, consider aiming for an MMP, a Minimum Measurable Product. The intention should be to release a product with the minimum amount of features required for people to care just enough to leave you feedback. (Hint: it’s not as many as you think it is).
Feedback doesn’t necessarily need to come from end-users, just any system or any group of people that could help determine if you’re on the right track.
3. Build, Measure, Learn
Once you have reduced your average lead time and understood the smallest slices of functionality you can muster, start building, measuring, and learning. The learning phase should be as much about optimising your processes as it is about optimising your product. Use this time to learn ways of improving lead time and reducing scope even further. Make people’s expectation of software change work for you, not against you.
Stop chasing a “final” product in a bid to please your users. It’s counterintuitive. Instead, aim for releases little and often in order to continuously improve. However reliant you think you are on large releases, small changes can make a big difference, and are completely in your control.
In the next blog, I’ll be taking a look at software costs. Whether you realise it or not, software development is riddled with explicit and implicit costs. Every decision you make has a cost attached to it. When you're writing code, you're making an investment, the size of which will define the costs of your future growth for a long time. We’ll explore how straight-forward design decisions and software practices are often directly connected with the time it takes to both build and evolve our software products.