Thinking Subtractively

In some news from my backyard, UVA researchers at the Batten School and the school of Engineering recently published an interesting paper in Nature: People systematically overlook subtractive changes.

The gist is that when people are looking at a problem and thinking about solutions, we typically think of adding something to solve the problem – even when removing something is an easier, simpler solution.

This six minute video from Nature is a good explanation:

When considering two broad possibilities for why people systematically default to addition — either they generate ideas for both possibilities and disproportionately discard subtractive solutions or they overlook subtractive ideas altogether — the researchers focused on the latter.

‘Additive ideas come to mind quickly and easily, but subtractive ideas require more cognitive effort,’ Converse said. ‘Because people are often moving fast and working with the first ideas that come to mind, they end up accepting additive solutions without considering subtraction at all.’

They tested this through a variety of experiments, including stabilizing Lego structures, optimizing travel itineraries, improving essays, submitting ideas for improving life on campus, and flipping tiles to make patterns. The findings were largely consistent across experiments: subjects were much more likely to add something rather than take something away.

Applying to Product Development

That’s fascinating, to me, probably because it confirms my view of the world. 🙂

Learning to think subtractively is one of my hallmarks of a great engineer.

One of my most productive days was throwing away 1000 lines of code.

Ken Thompson, creator of Unix

It’s something I’ve witnessed personally, and I think it’s a common experience among senior engineers. As you get more familiar with a codebase, it’s surprising how often you can solve a tricky problem by deleting code or removing pieces of functionality rather than writing code or adding new functionality.

Problems are often the result of complexity. The default solution should not be to layer on even more complexity.

You see the same theme in design also, represented by the famous (translated) quote from Antoine de Saint-Exupéry, which is a favorite of many designers I know.

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.

Antoine de Saint-Exupéry

We naturally think about nice-to-haves vs need-to-haves when grooming a backlog and evaluating what features should be prioritized, but that thinking often falls away once a product is built. We tend to assume that once a feature is built, it should live forever.

As product leaders, it’s important to remember that features are an asset and a liability. Too many features will make your product unfocused and create a system that is unreasonably expensive to maintain.

Fostering Subtractive Thinking

The good news is that we can change our default behavior.

One of the interesting parts of this research is they found small nudges could dramatically improve the results. If they merely mentioned the option of removing something in the instructions, the number of subjects who suggested a subtractive solution rose by 20%.

An easy way to apply that to product development is to simply include a question in stakeholder check-ins: Are there any features that no one uses?

A more sophisticated way to apply subtractive thinking could be supported with metric collection.

For example, if your engineering team keeps a history of continuous integration builds, that can be a rich source of information. If a test hasn’t failed in years, is it still worth having?

Maybe, it depends on many factors. But if none of the tests for a specific component have failed in years, maybe it’s time to consolidate tests. They might not be providing the same value.

Or if you keep good traffic analytics, you can show that a specific feature is only used once a month by one customer. If you keep categorized support tickets, you can show which feature cost the most to support. If a feature is rarely used but costs a lot, should it be cut?

Maybe, it also depends on many factors. Removing code or features – or anything that took effort to create – will always depend on many factors.

You’re effectively deciding an item has crossed the threshold to become more of a liability than an asset. That’s a high bar, but if you have metrics, you have something to guide your search. You have an idea where to start looking for pieces of your product that can be removed. You have something to remind you to think about this at all.

Remember this the next time you have a problem and start to add a new feature or process to solve it. The best solutions often start by considering what can be removed.

To attain knowledge, add things everyday. To attain wisdom, remove things every day.

Lao Tse