Essays & Articles


Why is 37signals so arrogant?

Andrew Park of Wired Magazine wrote a nice piece about the design philosophy of Jason Fried and David Heinemeier Hansson of 37signals: The Brash Boys at 37signals Will Tell You: Keep it Simple, Stupid. Brash is an understatement.

I was quoted in the article because of my article arguing that simplicity is highly overrated: the tasks that we do require tools that match the requirements, and these add complexity. Moreover, we purchase on features, not on their absence, and so the successful business must always face this tradeoff: the very things that customers complain about afterwards are what caused them to [purchase the item in the first place.

Now, I have always admired 37signals. Nice website, intelligent articles. But I’ve tried their products and although they have admirable qualities, they have never quite met my needs: Close is not good enough. After reading the article, I understand why: the developers are arrogant and completely unsympathetic to the people who use their products.

Yes, they are arrogant — and proud of it: “Arrogant is usually something you hurl at somebody as an insult,” Hansson said. “But when I actually looked it up ‘having an aggravated sense of one’s own importance or abilities’ I thought, sure.”

Park concludes his article by saying “Call it arrogance or idealism, but they would rather fail than adapt. ‘I’m not designing software for other people, ‘Hansson says. ‘I’m designing it for me.’ “

“I’m not designing for other people.” I think that simple phrase speaks volumes. Thank goodness most companies recognize that this attitude is deadly.

If 37signals wants to follow this attitude, I think that is fine. I’m pleased that they are enjoying themselves and that their simple applications do indeed meet many people’s simple needs. But I would prefer someone who designed software for other people. If you want a hobby, fine, indulge yourself. If you are running a business, then the needs of your customers come first. This means understanding them, understanding the activities they do, designing for them. It does not mean throwing features together haphazardly. It does not mean doing everything customers request. It still means being disciplined, having a clear conceptual model of the product, and sticking to that model. But to ignore them, to say “I’m not designing … for other people,” is an attitude that will not only lead to failure, it is one that deserves to fail.

Use Southwest Airlines as the model. When customers demanded reserved seating, inter-line baggage transfer, and food service, they refused (and only now, are reluctantly providing semi-reserved seating). Why? It is not because they ignore their customers. On the contrary, it is because they understood that their customers had a much more critical need. Southwest realized that what the customers really wanted was low fares and on-time service, and these other things would have interfered with those goals.

I once had a lively, entertaining dinner with Herbert Kelleher, Chairman and co-founder of Southwest Airlines. I asked him why they had ignored the requests of their customers. Herb looked me up and down sternly, sighed, took another sip of his drink, uttered a few obscenities, and patiently explained. His marketing people asked the wrong question. They should have asked, would you pay $100 more for inter-airline baggage transfers? $50 more for reserved seating? No, the customers wouldn’t have. They valued on-time, low-cost flights, and that is what Southwest delivers.

Land the plane, push the people out as fast as you can, tidy up quickly, with everybody pitching in: cleaners, flight attendants, pilots, and rush the new people in. Don’t use assigned seating because in its absence, customers run into the airplane, hoping to grab a good seat fast. Minimize turn-around time and you need less airplanes, less crew, less expense. Add amenities and you slow down everything, requiring more airplanes, more cost. Why would you want to slow down the turnaround time when your entire business model is based upon low cost efficiency?

Understanding the true needs of customers is essential for business success. Making sure the product is elegant, functional and understandable is also essential. The disdain for customers shown by Hansson of 37signals is an arrogance bound to fail. As long as 37signals is a hobby, where programmers code for themselves, it may very well succeed as a small enterprise with its current size of 10 employees. I’m happy for them, and for the numerous small developers and small companies that find their products useful. But their attitude is a symbol: a symbol of eventual failure. Too bad. In fact, that attitude is not so much arrogance as it is selfishness: they are selfish. A little less arrogance and a lot more empathy would turn these brilliant programmers into a brilliant company, a brilliant success.

As expected, the publication of this note has released a flood of responses, so let me use them as an excuse to clarify my writing.

One correspondent wrote: ” I think you’re somewhat mistaken in your evaluation of 37signals. To them, feature-bloat in web applications is akin to food service and seat reservations for Southwest Airlines. Application simplicity and usability are what the customers need most.”

I do not disagree with the comment: I simply do not believe that arrogance is the solution. Feature-bloat is horrible. 37signals is correct to be annoyed. But the disdain they show for their customers is not just arrogance: it is selfishness. The solution is not ignorance of the needs of your customers. Their approach is both arrogant and selfish.

The solution is to decide which customers represent your core audience, and then to observe them at work, the better to understand their true needs. (Not by asking them, not by questionnaires, not by focus groups). Rapid iterations of prototype and evaluation is the key. The iterative design method of rapid prototyping, test, and iteration (all done within the span of a day or so) is well defined in the Human-Computer Interaction community. It starts with observation and understanding. It then proceeds through rapid prototyping and test, continually refining the project scope and definitions.

The mark of the great designer is the ability to provide what people need without excessive complexity, without feature bloat. Simplicity should never be the goal. Follow the famous Einstein quote: “Everything should be made as simple as possible, but not simpler.” Complex things will require complexity. It is the job of the designer to manage that complexity with skill and grace.