Subtraction over Addition
Simplification and reduction as a valid solution to new problems.
Not long ago, I read about research that showed humans generally default to adding vs subtracting things when faced with a new challenge. As a science nerd, I enjoyed the article partly because of the science, but also because I saw some parallels to patterns (dare I say anti-patterns) in how many R&D teams develop products. Even more so in organizations working with long-lived systems and evolving them to support new goals and functionality. Consider this finding in the study:
“the reason their participants offered so few subtractive solutions is not because they didn’t recognize the value of those solutions, but because they failed to consider them”
In product development teams we use product bloat, scope creep, and other terms to think about this sort of anti-pattern. But that is usually focused on the requirements side, rather than more holistically on the entire product development approach. How often do we ask teams and ourselves to explore subtraction approaches? Instead, we add “just one more control”, “just one more data field”, etc. Even when we decide to replace existing systems we generally look at the current solution as a requirements list. While each individual decision is defensible, this more additive mindset may result in sub-optimal solutions. We then reinforce this by celebrating these additions as exciting new opportunities. If we considered and celebrated a subtraction mindset, would we open up an entirely new set of solutions that lead to better results with less complexity?
My previous team inherited an old but critical component that supported many different user groups, including external users and internal operations teams. It had organically grown over many years, extending features and expanding its user base. However, it was built on unsupported technology and had usability issues that made it difficult to maintain let alone continue to expand. Users felt it was a powerful tool, but it was clear to the team that we needed to explore replacing it.
To kick off the project we decided to explore how we would rebuild the product. We started with discovery work to figure out the different features, collated these into a single place, and described how they were used. This resulted in a list of users and features that we would need to replicate. The plan was to explore each use case to find optimizations in user flow and could use this to create a new more extensible foundation to build upon. While we knew that simply being new would not be better, we assumed that by having a full team focused on the new solution, using a supported stack, and these optimizations we would build a more extensible solution. However, this was also with a very “additive” mindset. Even the idea of “rebuilding” was based on assumptions that everything there was still providing value in an optimized way.
We needed to shift our mindset and look at the existing solutions as learnings, not as a requirements document. While the prior art was important to our understanding, we wanted to also avoid it limiting our thinking. In the time that the original product was created the industry had changed, the needs of the system changed, and importantly our understanding had changed. Attempting to replicate the features would have discounted that learning, we needed to expand our thinking to consider subtractive approaches as well. To that end, we took that list of features and flipped it around to focus on the use cases. Some of these were well supported and others were accidental use cases, where our users found interesting and novel ways to extend the product in ways we did not intend. This led to a list of use cases we needed to support and importantly showed some things that were no longer important. This combined with the learning from the tech team on the complexity of trying to manage disparate workflows in a single application, allowed us to develop a strategy based on divide-and-conquer.
We developed a tool that was externally facing which had less complexity, higher auditability, and greater resiliency. Focusing on the most important use cases for one user segment, allowed the team to reevaluate user flows and remove features that were not providing value. The result was a streamlined application that was both more efficient to use and had reduced features to support. Not only was the product more impactful, but reducing the complexity led to the product shipping more quickly and less time/cost to maintain. If we had not expanded our thinking to consider a subtractive, less is more, mindset we would not have been as successful.
Our initial impulses are to build upon existing solutions and try to replicate the prior successes, but we need to push past that to consider subtractive approaches that may bring more value to the business. This takes effort and work to retrain natural inclinations and reinforcement mechanisms in place. Looking ahead I am working to remind myself and the teams I work with to:
Dig past our assumptions about requirements/solutions and think about jobs to be done and the business’s goals. Be concrete on how both new and old requirements ladder up to the current goals.
Look for opportunities to reduce and reuse (to be cliche). As we create new value let's also look at places where we can consolidate or reduce our footprint. Over time the same problem may have been solved in multiple ways which creates maintenance costs and potential vectors for bugs.
Create the space to take stock of our current state and identify places to simplify. Whether this is tech debt, org debt, or just plain "I don't know why this is here", raise that up and remove it when appropriate.
Celebrate subtractions like we celebrate additions. If you find yourself simplifying a system, refining a process, or deprecating a product, that's a great time to recognize that work, demo it, write about it, or simply shout it out. Add reinforcement mechanisms to this subtraction thinking.
Teams have new and exciting opportunities ahead of them and we need to broaden our thinking about how to approach them when we’re working with existing solutions. By doing this we might turn up novel new solutions that have a far greater impact on our products, fuel our goals, and free our teams to tackle other problems.