Does Simple Have To Mean Less?

Joel Spolsky has a great post about the subject of Simplicity as it relates to software development. Building simple software applications is one of the Web 2.0 mantras as small companies take on their larger counterparts, trying to compete by doing less. Many of these companies seem to believe that if you build less features into a product, the product will be easer to use, and thus more attractive to businesses and consumers that are tired of bloated software that’s too complex to figure out how to use in the first place. 37 Signals has built their entire marketing campaign around their Build Less philosophy and they’ve become famous because of it.

But… do you really have to build fewer features into your product for it to be simple and easy to use? I think that building fewer features into a product can make it simpler than a product that has too many features, but simply building fewer features surely doesn’t mean your product will be a success.

Joel says:

A lot of software developers are seduced by the old ’80/20′ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

This sounds great on paper, but does it really hold true? I don’t think so, and Joel doesn’t either:

Unfortunately, it’s never the same 20%. Everybody uses a different set of features.

I couldn’t agree more. In fact, I’ve long believed that we are the epitome of a company that sells a service where everyone uses different features and features differently. If you disagree with me, I challenge you to take any five people you know and watch how they use email. The reality is, everyone who uses email has developed his or her own personalized habits—and just about everyone uses email.

I believe the real answer lies in building powerful, feature-rich software that can be personalized and most importantly, is easy to use. This is no easy feat, which is why not everyone is successful in software development. But the reality is, in our business at least, we need to build many of the features that our customers want—and our customers have employees that all use email differently. Read more posts