Getting to simple: How to create products with the least amount of complexity

Apple’s market cap is currently around $700 billion, a number that’s higher than the gross domestic product of nearly any country on the planet. Apple is the largest publicly traded company by a wide margin. And the secret to its success can be summed up in a single word: simplicity.

Building simple and intuitive products is very much in vogue for tech companies. But while many brands are trying to prioritize simplicity, few have developed reputations for it. Why is there a discrepancy? And how can we, as product managers, build truly simple things?

Defining the problem

To understand simplicity, we first need to define it. Simplicity isn’t purely about minimalism or the number of steps needed to accomplish a task. A simple product is one that creates the least mental overhead for its users. Sometimes — as counter-intuitive as it seems — that low overhead ends up meaning more clicks, more text, or more menu items.

A truly simple product is built around a deep understanding of the problem it’s meant to solve. This is challenging because it requires us to set aside our way of thinking and develop empathy for our users’ thought processes. When our customers ask for a feature, we need to understand why they want that feature. Getting to the real problem is key before we can figure out how to solve it. Without this understanding, we build things for the wrong reasons, which makes it difficult — or even impossible — to remove the unnecessary parts.

Solving the problem

Once we have clarity around the problem, we try to find the simplest solution that completely solves it. This is often challenging because different people use our products in different ways. How do you make something as simple as possible but no simpler?

Our strategy is to keep the first iteration intentionally light on functionality. “When in doubt, leave it out.” We build less on purpose initially, and let early feedback guide us to iterate accordingly.

The problem with the alternative — overbuilding — is we rarely get feedback to take something out. A small percentage of people will find the functionality useful and say they can’t live without it. But over time, the sum of this incremental complexity will result in a product that generates massive extra mental overhead for even simple tasks. We’d end up with a product that’s bewilderingly confusing for the vast majority of users. We’ve found that starting off by building less saves us time and tends to result in simpler outcomes.

I witnessed this firsthand when working on an account transfer feature for Dropbox for Business. When we first designed the feature, we took it for granted that users would want transfer capabilities on a per-file basis. The assumption we made was that customers wanted to pick and choose files belonging to a departing employee, then transfer them to someone else. We were wrong.

What our customers actually wanted was the ability to give all of a user’s files to one person; usually the former employee’s manager. They weren’t interested in cherry-picking files to transfer because they didn’t have the time. It was too much mental overhead. There were exceptions of course; what we built didn’t make everyone perfectly happy. But it was a good balance point that generated the least overhead for most of our users.

This is why we place so much importance on maintaining separation between the problem and the solution. We heard from our users that they wanted a feature, and we made assumptions about what that meant. Our assumptions were wrong because we didn’t completely get into the minds of our users.

Now when a feature is proposed, we work backwards to understand the root of the problem, and then forward again to solve that problem in the simplest way. The result is a solution that succeeds not by what it gives our users, but by what it leaves out.

Anand Subramani is a product manager at Dropbox.