2 / 10 · 4 min read

Simplicity

Why removing things is harder than building them, and why, for anyone making a product, it turns out to be the whole job.

Open the settings page of almost any product that has been alive for a few years. Forty toggles; maybe three you actually understand. The rest is scar tissue, options that were shipped, defended, and then never removed, each one added by someone who was sure it mattered. Products, left alone, only ever grow.

The storefronts in the last chapter softened because someone was finally brave enough to take things away, not to add beauty, but to remove noise until only what mattered was left. Carry that same instinct past the surface and into the thing you actually build, and it earns a harder name: simplicity. The reason behind it never changes, less to wade through is simply easier to live with.

And it is the most misunderstood word in building products. People hear it and picture emptiness, a thin app, a short feature list, a product that doesn't do much. But emptiness is easy; anyone can ship less by simply doing less. Real simplicity is the opposite of lazy: a product that does exactly what it should, with everything unnecessary removed, and not one feature more.

There's an old story about Michelangelo. Asked how he had carved David, he is said to have shrugged and answered that he simply removed everything that was not David. Whether or not he ever said it, every product engineer knows the feeling. You do not arrive at a simple product by starting simple. You arrive at it by building too much, watching people use it, and then finding the courage to cut.

Subtraction is the hard direction

Shipping feels like progress. Every feature you add, every option, every setting, is something you can point to in a changelog, proof that the quarter was not wasted. Cutting feels like loss. Killing a feature looks, from the outside, like you spent weeks to deliver nothing.

This is why most products bloat. Not because more is better, but because adding is rewarded and removing is invisible. The team that ships ten features looks productive. The team that fought to ship two of them and delete the rest looks slow, right up until you compare the two products in someone's actual hands.

The user never sees the roadmap you resisted. They only see what shipped. And what shipped is the product.

Every feature asks a question

Picture each feature in your product leaning toward the user and quietly asking: Do you need me? Am I for you? What happens if you turn me on? A product with forty features asks forty questions. A product with three asks three. The user has to answer every one of them, even the ones they dismiss in a second, and that answering is a tax no one itemises and everyone pays.

It compounds for you, too. Every feature is something to build, then document, then support, then keep alive through every future change. Simplicity isn't only kinder to the user; it's the only version of the product you can still move quickly inside of a year from now.

So simplicity is not a style or a smaller ambition. It is a kind of mercy, and a kind of self-defence. It is refusing to make a busy person carry choices that were yours to make for them, and refusing to make your future team maintain decisions no one really needed.

What it costs

When a product feels obvious, when it does the one thing you came for and gets out of the way, understand what went into it. Somewhere, someone argued to cut the feature they had championed. Someone chose the clarity of a user they would never meet over the satisfaction of seeing their idea ship. That quiet, unglamorous discipline is the engine underneath everything we have been calling soft.

Simplicity is not what's left when you run out of ideas. It is what's left when you run out of things you are willing to make someone else carry.

But here is the trap. A product can be built from exactly the right features and still overwhelm. You can ship only what's needed and then pile it all onto one screen, five buttons of equal weight, a banner, a promo, a tour, so the person who arrived to do one thing has no idea where to look. Deciding what to build is one battle. Keeping each moment pointed at a single task is the next one.

That battle isn't about the shape of the product anymore. It's about the experience of moving through it, whether, at every step, the product makes the one thing obvious or leaves the user to fight through the noise. So that's where we go next.