Jason Fried over at 37signals has a good post with the above title. (Via Daring Fireball.) Its such a good title I thought I would, as they say in the movie business, pay homage to it by using it myself.

Having spent over a decade both building and selling enterprise software (in my case a Learning Management System called TopClass), I can say that at least in my experience Jason has it right. Except its even worse than he thinks.

One of the single biggest challenges in building enterprise software is the inherent conflict caused by the fact that the economic buyer (i.e. the person that makes the decision to buy) is usually not the primary user and often not representative of most users. Typically the decision makers are the senior executives in the line of business or function making the purchase and if they are users at all of the product, tend to use reporting functions more than typical day-to-day functionality.

Combine that with the fact that the purchasing process is artificially skewed towards buying features rather than usability (through the use of everything-and-the-kitchen-sink RFPs) and the net result is enterprise software companies inevitably end up focusing on being able to check lots of feature boxes (”Yes, we do that”) and its no real surprise users end up frustrated and wondering if anyone ever actually tried this thing out before inflicting it on them.

This problems becomes even more insidious inside the enterprise software company itself too. Sales people are compensated based on, you guessed it, selling stuff. So Sales and Marketing groups will both frequently push for more features. Many Sales and Marketing folks understand the benefits of investing time in better usability, more robust architectures and greater performance and scale but when push comes to shove, they need to sell stuff and they believe (usually correctly) that features sell.

Sales people (and often most of the company) think in terms of this quarters results. Some of them even think about next quarter but they are often considered to be a bit touchy-feely by the rest of pack for allowing themselves to spend time on something so far away.

On the engineering side though we don’t get to just blame it all on the Sales guys. Engineers, typically under pressure to get more stuff done, faster, have a tendency to declare victory once the functionality simply works. For example, “the functionality you wanted was to be able to add users to the system and now you can.” This might miss the fact that often we need to add 100 users at a time and the new functionality only allows us to do this one at a time. So it technically works, but in practice is frustrating at best and unusable at worst.

Until enterprise software companies begin to take a longer term view (and in the long term, great usability creates loyal customers even if the product does not have every bell and whistle) things are unlikely to change.

Given the capitalist system in which we all operate, the most likely way this will happen is when customers start demanding it and focusing on the usability of the product for your real needs today and in the near future and stop worrying about possible requirements many years out.

Of course that brings us back to the economic buyer problem…