Are We Delivering Too Much?
I'm just going to come out and say it, "I think we deliver way too much functionality."
I know many people may be thinking, "I'd love to have the problem!", or maybe even, "Did Gary hit his head recently?". We have always been taught that more is better.
Most of our program management and risk management today is focused on maximizing feature delivery and when we are going to deliver. We usually reward our development teams based on the amount of output they produce, not on the outcomes generated.
So here's the thing.
There is a very tangible cost the more software we deliver, even excluding the original cost to develop a feature in the first place:
More bugs - the more features we include, the greater number of customer reported defects we are likely to going to have which means more time spent fixing these defects
More support costs - the more features we provide to our customers, the more questions they are going to have about how to use the features which means higher support costs
More technical debt - the more features we have, the more likely we will forego addressing technical debt to get another "critical" feature out the door
More complexity - as we add more and more features, the more complex our software gets because of increased "surface area" and the number of combinations of interactions between the growing number of features in our software, especially when we are also accumulating more technical debt
Higher marginal cost to add more functionality - when we continue to increase the complexity of our software, the more expensive it will be to add new features, which is bad in its own right but also a double-whammy when the marginal value of the new functionality decreases over time
More people and teams - when we have to support a large amount of existing functionality, face increasing technical debt, and have an ever-increasingly complex code base, the only way to keep up our output is by adding more people and teams. Bigger and larger number of teams creates high communication and collaboration costs, high levels of dependencies, and greater integration risk. This often forces us into very proscriptive scaling frameworks and reduces our ability to move quickly
Less focus on user experience - when we have to get new pages, screens, and link together many different pieces of functionality, it becomes harder to find the time to focus on great user experience. Furthermore, great user experiences often come from presenting a simple, intuitive interaction model for the user which is exponentially harder to do when there are so many pieces of functionality to tie together into a seamless experience
Adding insult to injury, not only have we increased our costs to produce more features, customers don't even use most of the features we deliver:
I'm sure most people have the seen the numbers from various Standish Group reports that state that only 20% of software features are often or always used. In 2019, Pendo published a report based on actual telemetry embedded into applications that 80% of features are rarely or never used. Even if you question how accurate either of the two reports just mentioned are (note that they are very consistent), I'm sure you can see it from the instrumentation in your own applications. The actual percentage doesn't really matter - we are not great at predicting what customers will find useful. If the marginal cost of producing more features was close to 0, then our best bet would be to create as many features as possible. Unfortunately, as we discussed above, there is a heavy marginal cost to adding features, so we need a different approach.
I know "Outcomes over Outputs" has become a mantra for many, as it should. However, I haven't seen much change in the way we go about planning our work, doing our work, and evaluating our work.
What if we focused on minimizing the excess features we are delivering? How would that change how we go about product roadmaps and program management?
For product roadmaps, maybe our default stance shouldn't be "How can we fit more into this product roadmap?", but instead should be "Where are we committing to producing more functionality than we need to?" Maybe we should ask the question, "What is the smallest amount of functionality we need to create to solve a customer need?" or "What is the smallest amount of functionality that will give us new information that increases our ability to determine which features will be valuable and widely-used by our customers?" Certainly we should be working in smaller chunks and instrumenting any new feature from the get-go so we can learn quickly and with the minimum upfront investment required.
If we reduce the need to scale up to a large number of teams, perhaps we can simplify program management or even eliminate the need for such a role? At the very least, it will allow us to iterate much more frequently.
One of the agile principles is "Simplicity - the art of maximizing the amount of work not done - is essential." We've worked quite a bit on reducing the amount of work done in requirements and design until we are more certain we are going to work on a feature. We now can complement that by understanding that often "less is more" when it comes to our feature output. Let's work to bring that aspect of simplicity into our product development activities. Our teams, customers, and CFOs will all thank us for it!
Blog cover image from publicdomainq.net