Pablo Fernandez asks 37signals:
Do you really think is the lack of features what makes a software better, or is it the “illusion” of simplicity (hiding the less used features, and emphasizing the common ones).
I don’t think the number of features is what makes software better or worse. One more or one less isn’t really the issue.
What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t. This applies both globally (the entire inventory of features) and locally (what someone can do on the current screen they’re looking at).
It’s not about ten features versus seven, it’s about the right four versus the wrong eight (or the right eight versus the wrong four). It’s also about the right place and the right time to reveal the right features. Every feature, widget, or interface control competes. Loading up the screen with stuff that is used 10% of the time means the stuff that’s used 90% of the time has to fight for attention. That’s not a good experience. The experience should be light, flowing, and comfortable, not heavy, clunky, and frustrating.
Software is a recipe: Too much of any ingredient can throw off the balance. The wrong ingredients can spoil a dish. Great software is perfectly seasoned—just enough salt, just enough pepper. Too much of any one thing, or not enough of another, and you’ll send it back.
When we talk about Less Software we’re really talking about balance. We’re talking about finding that sweet spot that solves most of the problem with the simplest solution. Simple for you to develop, maintain, and support, and simple for your customers to derive maximum value with minimal effort, learning, and hassle. From Getting Real, the book:
The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.
It’s not so much about consciously saying “we have three too many features here” it’s about saying “let’s solve most of this problem with less code and simpler design.” If we need to solve more of the problem later we can, but let’s solve most of it now—and quickly. And most of the time the partial solution is the plenty solution.
So remember: Good software is about balancing value and screen real estate and understanding and outcome. If it takes 20 good features to get there, then great. If it only takes eight, even better. It’s not the number that counts, it’s the balance.
Got a question for us?
We’re looking for interesting questions to answer here at Signal vs. Noise. Got one? Then send it to us at svn@37signals.com (make sure the subject line reads “Ask 37signals”). We’ll cherry pick the most interesting ones and answer them here. Fire away!
Marc
on 10 Oct 07Good question with a great answer. Thanks for sharing.
Raymond Brigleb
on 10 Oct 07Last night we were watching one of Gordon Ramsay’s excellent Kitchen Nightmare shows in which he goes into a failing restaurant, screams obscenities at everyone, and somehow manages to turn the place around. Love it.
In this episode, the stubborn chef had seventy-two (72) items on the menu. Every time he tried to pare it down, he “thought of one time someone ordered it” and couldn’t bear to take it off. With only three people cooking, they couldn’t keep up with the complexity of the menu (i.e. “software features”), and all of the food suffered greatly.
Mr. Ramsay pared the menu down to about a dozen items, and got them to concentration on timing and presentation. The restaurant was saved almost overnight.
Matt B.
on 10 Oct 07I know “looking at your competition” was addressed in Getting Real, but I thought I’d bring it up here; maybe you guys have something to add. I’m in a position right now where I’m starting a small web based business and as far as we know, there is ONE competitor out there. My partner has used that competitor’s services and as a user can easily point out things she would like done differently. From day one, while building this business, we’ve focused on implementing a nice balance of features that are easy to use while not bloating the web application with stuff not needed. We are falling into the trap of analyzing the competition’s feature set TOO MUCH. Even though we are trimming a lot of their fat away, I fear that it’s corrupting our vision and possibly inhibiting new ideas that we might of had with a clearer approach. But at the same time, it’s so enticing to look at what they’ve done that has brought them success and use those same ideas. Anyone else fall into this trap?
Josh Walsh
on 10 Oct 07In my experience, it’s all about context and software transparency.
The number of features is less important than the context in which they are placed. Often time the best placement is hidden, or not placed at all.
Software should be transparent. It should define the conventions of the business process and stay out of the users way.
Mike Strada
on 10 Oct 07Your analogies give readers absolutely no substance. Comparing software to some recipe, is baseless.
Pablo Fernandez, let me answer your question properly. The simple answer is YES, and you will learn this as you become more akin to business cycles and the “average” customer.
In the corporate world, a stagnant piece of software will not cut it. To say we have a radically redefined interface, thats pixel perfect would not entice them to upgrade. Its about sheer numbers here, we added X and X and without which your business will fall behind or likely fail.
FredS
on 10 Oct 07I’ll second the recommendation of Ramsay’s Kitchen Nightmares. I’ve only seen the BBC version, but it’s excellent. Great entrepreneurial/Getting Real type advice every episode. Plus, Gordan is entertaining as hell.
J Lane
on 10 Oct 07I think that comparing software to a recipe is a pretty good analogy. People have different tastes, and no matter how you bake it, you’ll always have those who want it spicier, saltier, sweeter (whatever).
Software is all about balance (as is cooking). I could develop the most simple application around, but if it doesn’t meet a need, it has no point. Likewise, I could develop the most feature-rich software around, but if it’s too complicated to be able to do the simplest things, then nobody will use it.
“We added X without which your business will fall behind or fail”
What? How many businesses are based off of, or so closely tied to a piece of software that they will fall apart? Even if eBay were to go offline tomorrow, all those people running eBay stores could just move over to Yahoo, or something else, and keep on going. Never put your business entirely in someone else’s hands, that’s just silly.
Matt: yes, countless times before. Think about your customer, not your competition. Who is to say that your competitor did it the right way to begin with? What would Basecamp be like if 37s just took MS Project and “pared it down”?
Matt B.
on 10 Oct 07J Lane: Good point, thanks.
James
on 10 Oct 07This is as good an explanation of your philosophy as I have read (consider I haven’t read your book). I recall you trumpeting Less is More and I hated that idea – what you have here is more to my liking. It is realistic.
One of my troubles is a narrow view. I have a particular way of doing things (approaching tasks) and I generally design software to make it easy for me to complete tasks. How does one go about choosing features that apply to a broad spectrum of users? Keep in mind that not every small business has access to or capital to purchase a broad usability report on their specific business domain.
Chad
on 10 Oct 07I love these posts, keep them coming!
@James – as simple as it sounds, watch someone use your software. Ideally a client, but a friend who is not involved in the project will do as well. Its amazing how much insight you can gain in 30-45 minutes. Buy them lunch and a beer. Check out Don’t Make Me Think by Steve Krug, it’s invaluable.
Rabbit
on 10 Oct 07Very, very nice. This is one of your best posts in a while, Jason. Glad you’ve still got it. ;)
I think I see a bit of maturation here, too. Not in your character, of course, but in the way you view software; that it’s not necessarily less that is the goal, but balance.
If attaining balance requires less, then so be it. Vice versa with more.
I’ve been thinking about balance lately, too. All things have a balance. I think the most obvious example of balance is a thing’s tolerance to temperature.
I, personally, like to be warm, so I set the thermostat at about 80. That’s probably high for a lot of people, but the summer’s here break 110 easy, so when it’s 70 I’ve got a jacket on. 80 is my balance. Maybe yours is 50 (hey, you live in Chicago, right?).
Trevor Turk
on 11 Oct 07Great post. I find myself fighting this battle quite often. It’s amazing how many times I’ve been asked to create a “features and functionality” checklist for use in comparing two or more different products.
When you boil software down to a black and white checklist of haves and have-nots, it’s difficult to find room to represent the elements of real value.
Choosing a piece of software because it has “more features” is terribly misguided. Software is a complex thing, so why would someone want to make decisions based on lists of checkboxes is beyond me.
Jennifer Davis
on 11 Oct 07I think less features is also a business strategy, as much as it is a software design methodology. In the book Blue Ocean, the authors compare the strategies of various industries and comment that the successful ones purposely don’t compete on many of the defining characteristics of their “competition.”
Compare the Cirque de Soliel with Barnum and Bailey’s for instance. Cirque has no animal acts and doesn’t target audiences of children – which is pretty much the definition of “circus,” right? Just like Basecamp has no charts and graphs, which is basically the definition of “project management software,” right? You choose to compete by positioning differently, not matching others feature for feature (and then having to compete on price, gulp).
Sebhelyesfarku
on 11 Oct 07The lack of features can be covered with hype (see Apple, 37signals etc.).
ML
on 11 Oct 07In the corporate world, a stagnant piece of software will not cut it. To say we have a radically redefined interface, thats pixel perfect would not entice them to upgrade.
I think you’re assuming a model where a “new version” needs to be release every 2 years so customers are forced to upgrade. In that case, different rules may apply.
All our products use a subscription model. The great thing about that is we don’t have to foist unneeded new features on customers in order to increase our revenues. That means we don’t need to keep inflating until we reach bloatware.
sangesh
on 11 Oct 07Well, to a normal consumer, it seems that it’s not the feature that counts first but it really is the packaging what matters.
before buying a product or even testing one, a consumer first looks in to the product (in our case, a software), if he/she sees the packaging or the graphics are attractive then the user starts clicking and hence increasing sales or use of the software.
sangesh
on 11 Oct 07Well, to a normal consumer, it seems that it’s not the feature that counts first but it really is the packaging what matters.
before buying a product or even testing one, a consumer first looks in to the product (in our case, a software), if he/she sees the packaging or the graphics are attractive then the user starts clicking and hence increasing sales or use of the software.
well, i have typed all the above not just as a bluff, but i have gone through all this procedures and have concluded this, that, if you don’t have an eye catchy product then it will take hell lot of time to convince your user.
Matt B.
on 11 Oct 07Same thing in the world of dating, at first, looks matter.
ChadB
on 11 Oct 07Slightly untrue. Software must fit on disk space and only utilize a computer’s resources such that a user is actually able to run the program. Also the software development process usually doesn’t include an unlimited amount of time to perfect the design.
Also, as to your recipe metaphor, once the recipe is prepared, those ingredients are no longer reusable. Software, on the other hand, should be highly reusable and allow for an evolution over time.
Pablo Fernandez
on 11 Oct 07Guys, thank for the answer.
Now talking not about features, but about what can users really DO with the software I still have a doubt.
Lets imagine a word processor, with the “Translation” function. It’s uncommon that it is used, someone (e.g. myself) may state: “It’s a word processor, It doesn’t need to be a transaltor, there are plenty good translators in the market, etc” and try to keep the software simple and unbloated.
But the “translation” thing can be a first grade requirement for another group of users (maybe a 2 o 3% of the total).
Ok so what’s the big deal? we loose 2% of our clients and keep the 98%, right? No, not quite. The fact is like “translation” there are a big number of “things” that our users would like to do with our soft (word counting, synonyms, online collaboration, etc.).
Maybe most of us (I do actually) would say “What? word counting? why on earth would you use that???” but to some 2% that function is the only reason for using our product.
and 2% + 2% + ... = 100%.
This is another way of saying something I read a long time ago on the Web, I don’t remember the exact words but was something like this:
“We all know 80% of the users use the 20% of the functions we provide, but that 20% is not the same for every user”.
So with this said. Do you agree? and if you do , How do you determine the best 20% of the functions to pack, like for example why did you choose to include chat in Basecamp but excluded other things.
[note: most of the features described here were taken from the most popular word processor for windows. And I was not aware of their existence until “surfed” through the menu :)]
Nir
on 15 Oct 07This “editor” (or “chef”) role sounds a lot like Mitch Kapor’s 1990 concept of Software Designer. Scott Rosenberg has a nice description of this concept.
This discussion is closed.