Less, Eventually

From the reader's perspective both did the same job, which is letting someone send me a message. From my perspective the mailto: was strictly better because it had no moving parts and never broke.

That small move kept showing up in my work across years and projects. Subtraction as a habit, applied a hundred different places.

Less stuff to maintain, less surface area, less weight on the next thing I wanted to do. It became one of the more useful disciplines in the way I build, and it took me years to recognize it as a discipline at all.

The Shape of Addition

Most product writing assumes you're going to add something. New features, new tiers, new integrations, new dashboards. Ugh.

The whole genre is shaped around the next thing you'll ship, and the implicit question is which one to pick. Removing things sits outside that frame entirely.

The shape of that framing produces a particular kind of product, which is one that accumulates.

Every feature added stays added, every integration added stays integrated. Every dashboard panel ever created is still there, even when nobody opens it anymore.

Over a few years all of this builds into the cruft we complain about in other people's products and quietly tolerate in our own.

Unshipping a feature doesn't earn you a celebratory tweet or a launch post.

Simplifying your pricing doesn't get retweeted the way a new tier does. The work pays off in maintenance and clarity, but the payoff is quiet, which means the work almost never gets prioritized unless you decide to prioritize it on your own.

What Removal Looks Like

Removal works at different scales, and the smallest scales are usually where most of the gains live.

• At the trim level, you might replace a contact form with an email address, collapse a three-step signup into one step, or strip a sidebar from four widgets down to one. None of these decisions show up in a launch post, but they each take cognitive load and maintenance time off your plate.
• At the feature level, you might kill an integration that two users relied on and that took disproportionate maintenance attention. You might put a feature behind a flag, watch nobody complain for six weeks, and then delete it. You might notice a dashboard panel that nobody ever opens and quietly remove it from the layout. 
• At the layout level, you might cut a homepage from five sections to two, reduce footer columns, or settle on one call to action per page instead of three competing for the same click. Visual cruft is its own category and tends to be the easiest to remove because nothing technical breaks when it goes away.
• At the product level, you might sunset a side project that hasn't been pulling weight, close a free tier that's been attracting the wrong audience, or discontinue a feature that's on the marketing page but has no actual users.

Each of these is a small decision. The cumulative effect is a portfolio that's easier to maintain, easier to explain to new people, and easier to add to deliberately when you do choose to add.

The Things That Don't Need Building

The strongest version of removal is the one where you didn't build the thing in the first place.

Anti-addition is more valuable than subtraction, and once you've removed enough stuff over the years you start recognizing what you would have removed later anyway. That recognition starts to change what you build now.

Some of the products I respect most have stayed simple not because they kept removing things, but because they never added the things in the first place. One email a day instead of three, one pricing tier for a year instead of three at launch, a single CTA on the homepage instead of stacked options competing for the same click.

The restraint adds up across years in a way that's pretty hard to see from the outside.

You can't predict every feature you'd later regret shipping, but you can notice when a new feature feels like obligation rather than necessity, and the obligation features are usually the ones that show up in the removal queue six months later.

They get shipped because the industry says you should have them, or because a competitor has them, or because three customers asked.

They rarely justify their maintenance cost.

A useful question before adding something is whether you'd honestly be willing to maintain this thing for five years, support it through migrations, write docs for it, and explain it to new customers. If the honest answer is no, the feature usually isn't worth shipping.

Quiet Cost of Carrying Everything

Carrying features that mostly work has a real cost, even when nothing is obviously broken on any given day.

Every feature is something to remember, something to test through major releases, something that might break when a dependency updates, and something that constrains future decisions because it interacts with what you'd build next.

Twenty features that mostly work cost more to operate than twelve features that all work well, even if none of the twenty has a bug today.

The mental load is the part you can't actually show on a dashboard. You feel it in how slow it gets to ship the next thing, how cautious you become about touching old code, how much you dread the support email asking about a feature you forgot exists.

Removing things is one way to get that time back. Not the only way, and not always the right answer, but a tool worth having available.

When To Remove, When To Wait

A few prompts that have helped me think about this, offered as prompts rather than rules.

• If a feature has clear users who'd be hurt by removal, wait. Removal works as a tool toward a healthier product, not as a goal of its own, and breaking the experience for people who rely on something is the opposite of what you're trying to do.
• If a feature has no clear users but takes up maintenance attention, flag it. Hide it for a few weeks. If nobody notices it's gone, you have your answer.
• If a feature exists because it seemed like a good idea at launch and never found its job, kill it. The longer it sits unloved, the harder it gets to remove without a story.
• If a feature is loved by ten percent of users and confusing the other ninety, ask whether the ten percent could be served differently, or whether the confusion is worth the loyalty. There isn't a single right answer, but the question is worth asking once a quarter.

Following these prompts exactly matters less than running them at all. Once a quarter is enough.

A Smaller Move Than It Sounds

The things that have stayed clean in my own work stayed clean either because I removed something along the way or because I didn't build it in the first place.

Both moves are useful, and neither one looks like progress from the outside.

The thing that does look like progress, which is constant addition, is also what produces the cruft we all end up dealing with eventually.

If you have something to ship next week, ship it. If you have something to remove, consider that as a separate option worth scheduling. The removal is rarely the urgent thing, which is exactly why it never gets done.

See what would happen if you took something out next week and watched what changed.