Disagreeing with 37signals #1: Less Is Sometimes Less

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:


Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Disagreeing with 37signals #1: Less Is Sometimes Less


This is the first in a series of articles I plan to write about some of my thoughts on 37signals and their e-book “Getting Real”.  [For the record, I highly recommend the book].  Most of the advice is really good.
There has been a lot of talk on the net about simplicity and the whole principle of “less is more”.  
I must say that I agreed with a large majority of what they had to say in the book, and most of it I think is good advice for software entrepreneurs.  However, the things I disagreed with, I strongly disagreed with and felt it necessary to respond to.
Disclaimer:  Overall, I like 37signals and what they have done.  They’ve shown us what is possible in the “real” Web 2.0 world where companies can create value, charge customers and run a real business.  Further, Jason Fried (founder/director/evangelist of 37signals) was kind enough to let me interview him for some graduate work I’m doing at MIT, so I am grateful for that (thanks Jason!).  I am also a paying customer of the company and have used their products.
Having said that, I’m just getting a little weary of this “less is more” message.  I think we are beginning to confuse the simplicity message with the “less” message.  Very, very powerful things (like the Google search engine) can be very, very simple too – from a user’s perspective.
So, to be clear, there are various “dimensions” on which less can be measured:
  1. Less complexity (from a customer’s view point)
  2. Less “baggage” (more flexibility)
  3. Less features.

It’s the last item that I have contention with.  Less (features) is not always more.  So, lets dig a little deeper here.  In every technology industry that I know, customers demand more features/capabilities over time.  Whether it be software, a car or a mobile phone – as time goes, you expect more out of the technology in your life for it to continue to be useful to you.  Paradoxically, you want things simpler too – but simpler does not mean you’re willing to give up on features.  You want both.
Lets take a classic example from the software world:  the word processor.  The 37signals team might have us believe that the answer here is the simplest possible set of features are all that people really care about or want.  Basically, you write/edit text and save/print it.  That’s it.  Basically, something like Notepad.  At the other extreme, we have Microsoft Word with its 10,000+ features.  Many can (and have) argued that nobody uses more than 20% of the features in Word.  That’s likely true.  The issue is that it is a different set of features for each user, and within that set, one or more features are very important.  Not nice to have, not customers whining because they want everything, but important.  For our word processing example, we could divide the kinds of features that people might want into some simple buckets:
  1. Formatting and Printing (fonts, images, layout, rulers, etc.)
  2. Better writing features (spell check grammar check, word count, etc.)
  3. Large document features (table of contents generator, footnotes, etc.)

Now, ask anyone that falls squarely into one of the above groups as to whether “less is more” – and they’ll clearly disagree.  A journalist needs spell check and word count.  When writing my master’s thesis, I need the table of contents feature.  Sure, we crave simplicity (so we like features to “go away” when we don’t want them), but we’re not willing to give up the features we want.  Most of the most successful products in the software industry are those that were able to deliver “more” to the customer without disproportionately increasing the complexity (examples are Lotus/Excel, Word, Photoshop, Quicken, etc.)  

To be sure we're clear here, I'm not suggeesting that companies build products that try to do everything for everyone.  I'm a big believer in focus.  But, once you've picked what kinds of cusotmers you're going to focus on, the goal should then be to deliver what these customers expect.  In the 37signals case, it seems that they are picking a broad range of customers and then choosing the minimalist set of features (i.e. "lowest common denominator") that all of these customers need.  The result is a very small set of features that doesn't meet the full needs of most customers. 

Overall, I’m all for finding a  Clayton Christensen style “disruption” (See “The Innovator’s Dilemma) and playing a different game.  The issue is that in the world of software, even simple things sometimes require some planning, thought and design so that you don’t paint yourself into a corner.  Here’s the one example from the book that just about gave me an ulcer:
From “Getting Real” by 37signals:
Build software for general concepts and encourage people to create their own solutions.
When we built Ta-da List we intentionally omitted a bunch of stuff.  There’s no way to assign a to-do to someone, there’s no way to mark a date due, there’s no way to categorize ,items  etc. We kept the tool clean and uncluttered by letting people get creative.  People figured out how to solve issues on their own.  If they wanted to add a date to a to-do item they could just add (due: April 7, 2000) to the front of the item.  If they wanted to add a category, they could just add [Books] to the front of the item.  Ideal?  No.  Infinitely flexible? Yes. 
Now, let me breathe deeply and explain why I think the above example is so troublesome.  I’ve been a professional programmer for all of my career.  I’ve read the books, got a CS degree, written big apps and small apps, worked with some exceptional people (folks that Joel Spolsky and Paul Graham would like), and so on.  Not a single person that I respect and know from the software development community would likely consider the above a “good approach”.  Repurposing things as simple as a due-date and having users make up their own ways to solve the need is just asking for trouble – very soon.  This goes against so much of what we have learned (simple things) about creating great, enduring, well designed software.  We’re not saying it should be more complex, but there needs to be some minimal design that accounts for the most basic needs.  Other than the fact that the above application is web-based and Ajax-powered (which is cool), it’s just another simple data management application, with minimal structural support.  I think we’re getting overly distracted by the coolness of new technologies and taking a major step backwards.  In the above example, what happens when users want to be notified of items that are due?  How about when users want to see tasks that are assigned to them (if that feature ever gets added).  There’s no need to add these features now (though one could argue that for a task management system, these are bare essentials), but given the choice, customers are likely to want these things – once they get done with the basics.
As a final point, I’ll include another excerpt from the book:  Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else.
In my experience, the simple problems (that people are willing to pay to have solved) are both hard to find and hard to build enduring software companies around.  Even things that start simple end up becoming complex as customer demands increase.  The 37signals approach to addressing this increased complexity seems to be to build “opinionated software” (basically, push back on the customers and keep things simple).  I think this is a sub-optimal strategy.  History is replete with companies that didn’t work hard enough to meet the growing demands of their customers and ultimately got left behind.  
If you’re an aspiring software entrepreneur and have found nice, easy problems to solve that customers are willing to pay for, congratulations!  That’s great!  You too can be a huge success like 37signals.  But if not, you’re in good company.  Thankfully there are still lots of difficult, challenging and interesting problems that customers need solved in the software world.  Looks like Its poor, wretched souls like you and me that will likely have to take on these problems.  Such is life…
What do you think?  Am I off-base here?  

Posted by Dharmesh Shah on Wed, Apr 19, 2006


Actually our message is that less is less. It's not less is more because that implies more is better. Less is less and we believe less is just enough for most folks.

posted on Wednesday, April 19, 2006 at 5:58 PM by Jason Fried

"Less features" doesn't make any sense. "Fewer features" makes sense.

posted on Wednesday, April 19, 2006 at 7:13 PM by Josh

First things first:

Nice site you have here, I've recently added it to my feeds, and I'm impressed at the quality of the writing. Keep up the good work.

As for this post, although I'll concede that you may have a point overall, I think you're misunderstanding the specific example you use.

The power in letting people solve their own problems is that they will undoubtedly solve them in their own ways, sometimes in ways that simply cannot be anticipated by the designer/developer.

For example, I recently heard of a university campus that was designed and built from the ground up. The designers completed all the buildings, and conveniently "forgot" to build any sidewalks between structures.

Why would they do this? Because once the campus had been used for a semester, where the sidewalks need to be was crystal clear - the users had decided that for them!

I take 37s advice the same way. If you view a piece of software as adaptable and open to change, sometimes it's best to let the users themselves show you where you build paths, and where not to.

posted on Wednesday, April 19, 2006 at 7:16 PM by Dave P

Several points:
1) "Less is less and we believe less is just enough for most folks."- Looking at the word processor example, are you prescribing that students, doctors, journalists, and lawyers aren't a significant portion of the population (one could argue there are a number of other professions that require some features such as footnotes, formatting, etc.). Now there are some great examples that aren't as applicable to a wide population (mathematical formula formatting such as the niceties in TeX).

2) "For example, I recently heard of a university campus that was designed and built from the ground up. The designers completed all the buildings, and conveniently "forgot" to build any sidewalks between structures." - A number of the older "state colleges" were actually built this way. I know Michigan State was and I believe Penn State was as well.

3) "I take 37s advice the same way. If you view a piece of software as adaptable and open to change, sometimes it's best to let the users themselves show you where you build paths, and where not to." - With decently established problem domains what is the point of re-establishing some of the known issues? Again, look at the word processor example. There's a world of difference between a text editor and a word processor. I believe in using the proper tools for the proper job. It's not to say one can't get creative and get around 80 - 95% of the issues by using a similar tool.

It gets to the point Jason / folks bring up about the build half a product vs. a half - ass product. There are certain areas where "simple" doesn't cut it, as artificial complexity exists. Another good example would be tax software. Tax code is totally complex and sucky. Are there ways things can be simplified on the interface end to make it easier to get taxes done? Of course. But there are so many rules and conditions that one can not "simply" build something for it.

posted on Wednesday, April 19, 2006 at 7:31 PM by matt

The todo list software is a taster for a paid, hosted project management and time tracking package called Basecamp.

I haven't used Ta-da List in a while, but from what I remember it was two parts Basecamp ad, one part Rails tech demo.

posted on Wednesday, April 19, 2006 at 7:40 PM by Derik Stiller

Why not create three different Words for various sets of users? It's sometimes easy to hurt yourself with a pocket-knife.

posted on Wednesday, April 19, 2006 at 7:50 PM by maurycy

"Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. "

Yes that's right... you make $1 solving the simple problems, the guy who solves the nasty problems makes $1million.

Anyone heard of the term "Barrier to Entry?"

posted on Wednesday, April 19, 2006 at 8:19 PM by zoran gavrilovic

"Yes that's right... you make $1 solving the simple problems, the guy who solves the nasty problems makes $1million."

It's partially a question of scale and market though. If you can sell something for 20 or 30 bucks a pop to a million people vs. something for a million bucks a pop to 5 corporations...

posted on Wednesday, April 19, 2006 at 9:30 PM by matt

37S is taking the old Unix approach: a single application for a single task.

This works when your applications have a small or limited scope (eg: del.icio.us, Ta-da, Flickr) but doesn't when you're editing images, creating a spreadsheet, or doing 3D modeling.

So while 37S isn't making a false assertion, they are making a misleading one; it only applies under a strict set of circumstances and therefore becomes much less useful on any sort of reflection.

PS: Why not have different versions of MS Word for each market? That's a development, resource, marketing, and QA nightmare. Just look at Vista.

posted on Wednesday, April 19, 2006 at 10:57 PM by Charles

i agree.
you might find some of the things I've written on this topic of interest:

Sketching on Simplicity As Qualitative Perceptual Concept

Notes on What Qualitative Perceptual Concepts Are

Complexity as Qualitative Perceptual Concept

Quick Drafting on Tradeoffs Between Local and Global Simplicity/Complexity

Factors in Tool Complexity/Simplicity: Viewing Value as Additive

Factors in Tool Complexity/Simplicity: Vertical- and Horizontal- Features

Initial- and Standing- Simplicity/Complexity

You might also be interested to see this comment by Linus Torvalds on this matter of oversimplification:

posted on Thursday, April 20, 2006 at 12:23 AM by James Cole

Thanks to everyone (especially Jason) for taking the time to comment. Will read through them and plan on a follow-up post.

Don't want to try and respond via comments as this will sound like I'm being defensive.

Good discussion.

posted on Thursday, April 20, 2006 at 12:35 AM by

Fields definitely asked for in a task/todo listing interface by ALL of our customers.

Date Due
Assigned To

Anything less than that and it'd have little or no value to them. Just my 2¢

Poignant article. Thanks!

posted on Thursday, April 20, 2006 at 1:36 AM by Bert Ealzey

I just want to say that I fully believed "less was more" until my lab reports started to demand tables and graphs ...

posted on Thursday, April 20, 2006 at 6:00 AM by Aditya

I agree with you so does this guy. Also I for one would like to see you defend your position.


summarized below

I - Continuing Change
An E-type program that is used must be continually adapted else it becomes progressively less

II - Increasing Complexity:
As a program is evolved its complexity increases unless work is done to maintain or reduce it.

III Self Regulation
The program evolution process is self regulating with close to normal distribution of
measures of product and process attributes.

IV - Conservation of Organisational Stability (invariant work rate)
The average effective global activity rate on an evolving system is invariant over the product
life time.

V-Conservation of Familiarity
During the active life of an evolving program, the content of successive releases is
statistically invariant.

VI - Continuing Growth
Functional content of a program must be continually increased to maintain user satisfaction
over its lifetime.

VII - Declining Quality
E-type programs will be perceived as of declining quality unless rigorously maintained and
adapted to a changing operational environment.

VIII - Feedback System
E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must
be treated as such to be successfully modified or improved

posted on Thursday, April 20, 2006 at 7:18 AM by Dean Fragnito

I would agree with you Dharmesh. Overall, I'm a fan of the work that 37S do, but what grates with me is that they think that everyone can work their way - ergo, everyone else works the wrong way.

Their tools, and way they work, works for them *in their specific problem domain*. This works fine for a bunch of guys hacking out code, satisfying 80% of people. Heck, I bet they're making a good living out of it. But for those of us that have to satisfy 100% of our customer's needs, many Getting Real concepts fall down.

I'm all for keeping things simple - it's the backbone of how I work, but sometimes, 'less' just means a p*ssed off customer. I wish I had the liberty to pcik and choose my customers as freely as 37s, but alas, I don't. Still, I manage to make a good living too.

posted on Thursday, April 20, 2006 at 7:39 AM by AndyToo

I can understand both viewpoints. I like simplicity but applications that lack certain functionality are also very frustrating.
For example, I use a particular text editor because of its interface and it has some handy features that I haven't found in any other editor. However, it's find and replace is terrible complicated and I haven't been able to use it reliably. SO, I have a different editor with a simpler find and replace that I use specifically for that purpose. That's pretty lame. When all the other features are so well executed, is a decent find and replace too much to ask?
As far as Word goes. I find it overly complicated for what I use it for. I also dislike its auto-formatting habits. Anyhow, I can understand that different groups may have totally different uses for that product and require totally different features. Why not show/hide menus/features based on user types.
Some Macromedia products such as Dreamweaver do this when you first install them. I'm assuming they researched this ahead of time but they divided their user base up into camps such as developers, graphic designers, etc. When you install, they ask you to choose a specific purpose that then customizes menus/features for that use. At any time you can go back and change your prefence but it simplifies menus into those tasks that they deem most useful to each group.
How hard would it be for other applications to follow their lead?

posted on Thursday, April 20, 2006 at 8:17 AM by Michael Murphy

Looking solely at the complexity of a program is not a good way to measure how good it is.

First, complexity can be hidden from the user, which reduces (initial) user-shock, but makes the program unnecessarily difficult to use at an advanced level.

Second, there is such a thing as inescapable complexity and at a certain point a line must be drawn for minimum competency. If that line is drawn too soon, the program will not be powerful enough to solve the inescapable complexity.

Therefore, the best programs are those with an interface that approaches a 1:1 relationship with the complexity of the problem domain. The biggest challenge for a good developer is to not accidentally (or carelessly) butcher the hierarchy of the domain. If the hierarchy is properly preserved, the user will know what must be done without reading a manual.

posted on Thursday, April 20, 2006 at 10:55 AM by Ryan Elisei

"It's partially a question of scale and market though. If you can sell something for 20 or 30 bucks a pop to a million people vs. something for a million bucks a pop to 5 corporations..."

Perhaps you misunderstood me. I was referring to total revenue of $1 vs. $1mil.

Consider the barrier to entry concept. If the idea and the implementation are simple enough for anyone to copy... then your less really amounts to less $ in your pocket.

posted on Thursday, April 20, 2006 at 11:15 AM by zoran

Apologies. I misunderstood the point of your original post.

"Consider the barrier to entry concept. If the idea and the implementation are simple enough for anyone to copy... then your less really amounts to less $ in your pocket."

Well...then it becomes a question of market share, commoditization, etc. (typical Porter fare). By your argument, no one should be making / selling commodities as other people do as well.

posted on Thursday, April 20, 2006 at 11:57 AM by matt

I agree. Ta-Da list is a good example. It's the most worthless app that I have ever seen even though I love 37signals approach to web development.

posted on Thursday, April 20, 2006 at 3:38 PM by Hermann Klinke

The message I am taking from the book is this:

Focus on a niche. Focus on what you are good at and
Do it well... really well.

Don't try to do everything and diffuse your focus.

The key is to be THE BEST and the truth is that
you CANNOT be the BEST at everything.

This philosophy should apply not only to the applications we write but also to our lives.

You can always expand and grow once you have established yourself.

Best wishes,

posted on Thursday, April 20, 2006 at 5:58 PM by Hari

That's a great point. Having a niche is essential to getting off the ground. It's much easier to get (and show) "traction" in a niche.

Guy Kawasaki would agree with you completely. His term for it is "Niche Thyself".

posted on Friday, April 21, 2006 at 8:22 AM by Ryan Elisei

I am a big believer in focusing on a niche market (see earlier post called "Risks of The Mega Market". I am not suggesting that companies try to do "more" in the sense that they focus on larger markets -- quite the opposite.

This article is intended to address something different: After you have picked a niche, it is important to deliver the functionality that customers want/expect and to grow the product within that niche.

posted on Friday, April 21, 2006 at 9:55 AM by

There is a tactical sales element to all of this. What makes sales work for software products (particularly those sold to an enterprise-level market) is that the product or service solves a problem that is critical to the customer. This is true for markets/niches/customers of any size. If your product doesn't meet this test, it will be seen as nice to have or interesting technology, but not as an absolutely necessary purchase. In today's market, nice to haves and interesting technology aren't competitive beyond the visionary customer stage. It may be that 37signals meets this test in their target market - if so, no argument from me.

posted on Friday, April 28, 2006 at 11:05 AM by Andy Blackstone

Build Opinionated software:

Do a small thing really well. Not too many things poor. There should be atleast 2-3 reasons for including a feature. If it is a word application, give a plugin for customizability. Someone else is probably better equipped to handle customizability for journalists. Someone else for mathematicians.

posted on Monday, May 01, 2006 at 1:51 AM by Amit

Examples of poor features on this site:
* posting comment on this blog needs email. Why?
* URL doesnt show up as link in the comment. So why ask for it at all?
* On Firefox, right click on Article Navigator doesnt work as expected. Why build an another thing, for which simple solutions exist?

posted on Monday, May 01, 2006 at 1:57 AM by amit


Good points. Will take a look at the issues and make the appropriate changes in the next version.

Thanks for pointing them out. You're experiencing a "work in progress", so apologies for the issues.

posted on Monday, May 01, 2006 at 2:01 AM by

Make sure you judge the Get Real book for what it is: a manifesto for the web applications development.
Here is my take:

posted on Friday, May 05, 2006 at 5:44 AM by Harry

Of course less is more. But we are talking more about the focus beyond that of a single tangible "thing".

Think of a horror movie, where you see the monster and are able to see it's just a guy in a suit. Boring!

Now think of a horror movie where you see fleeting glances of the monster, you get to fear it.

Less is more - of an experience. Experience is life, not a feature. Any dolt who's been anywhere near a design class knows less is more, form follows function, etc. Unfortunately egotistical developers developers developers who get treated like rock stars start believing they are rock stars and pump out complete shit and demanding riders.

Why re-invent the wheel? Why try to hijack the meaning of the design classic "less is more"? Go to art school, or leave design to the designers.

posted on Friday, December 08, 2006 at 7:13 PM by Mike Peter Reed

Excellent article. The recurring problem is that when engineers add power (capability) to software they usually burden the user with increased complexity. ("oh, you want to schedule your FTP uploads? I have time to create the feature but not to make the *interface* as simple as possible).

Therefore, users often associate "increased capability" with "increased complexity of the interface".

As MS's head reasearcher ( Nathan Meyrhold?) said "it take a lot of effor to make things simple").

So, when the user asks for "simplicity" they rarely mean "less capability" but, rather, "make it easier to use". It's all the little things that help that: I'm using FogBugz right now and when I open a new Case and report the version # where the problem was found and then open another Case, it fills in the previously used version number. That's extra capability that makes the software EASIER to use.

It IS possible to add capability while making the software eaiser to use. But that is, as the mathematicians say, " a non trivial problem". But that's what usability is all about.

posted on Tuesday, December 12, 2006 at 12:03 AM by Aphasia Software

I have used a 37signals product as a paying customer as well. An inspiring user experience but I quickly found some limits or rather found myself looking for features that weren't there. Photoshop is feature-rich, has a learning curve, and it doesn't try to think for you. No instant gratification here. Just long-term utility and value. I believe there's a happy medium somewhere between the "less is more" trend of lightweight, agile-but-specific SAASs and the utility of something that provides almost innumerable common, non-specific functions to create long-term application value the way Photoshop has for me as a designer.

posted on Sunday, December 02, 2007 at 4:23 AM by Luke Smith

I definitely believe in less is more. Here's why: http://www.devamigo.com/?p=8

posted on Wednesday, December 12, 2007 at 10:38 PM by Jitesh Patil

37S are targeting a niche market...there are a lot of users out there who have had enough of using the convoluted systems and 37S's apps are basically a breath of fresh air in the clutter. You do not have to become the next Facebook or Google to be successful...targeting a niche market and managing your customers' expectations would make you successful as well and that is what I believe 37S are doing...and doing it well.

posted on Friday, July 25, 2008 at 5:47 AM by andhapp

Ironically I quoted the same passage today in my blog about opinionated software, AND included an example of how Facebook is needlessly complicating a particular piece of UI in the minifeed.  
Complicated UI invariably makes a programmer feel good about their accomplishments, but the same can't be said for how useful the software is.  
Good design is about making smart decisions for the user so you DON'T have to make choices. Amount of choice correlates positively with functionality and complexity. So ultimately, 37signals is taking away choice but increasing value.

posted on Friday, July 25, 2008 at 7:16 AM by Garry Tan

Comments have been closed for this article.