Dan’s Chocolate Adventure

A lot of people in the business world ask me what software they should buy or install to make their companies more productive. I generally give them the same response - there are few products that they don’t already know about that will get outsized productivity gains. Instead, they should do two things:

1. Get rid of all of the fancy stuff. The “tailing costs” of software are huge, when you consider all of the support and training expense. Get everyone on one simple, free IM program. Switch everyone to Gmail. Old licenses of installed software are often fine, don’t succumb to the “I need the newest stuff” that the software industry constantly pushes. Teach people how to file emails in a well organized way.

2. Most importantly, focus on getting everyone in the organization to change their behavior with their tools. Even a slight change will increase productivity. For example, make sure everyone logs into IM automatically. This makes people much more productive. Ask people to follow-up to emails saying “This is done” or “This will be done tomorrow.” Even 10 minutes at the end of every day and midday makes communication that much more efficient. Ask people to respond to their email once in the evening, to create an evening “loop cycle.”

Human behavior, communication, and diligence are much better investments than more software products at this point in the cycle of the industry.

About a year ago, we dropped Amazon.com as a partner. Their API was so huge and complicated that it was absurd to deal with, and not worth the small number of sales they were sending us. They actually wanted us to hire a consulting firm to come in and integrate their beast with our lean, unix system.

About ten years ago I interviewed with Jeff Bezos for an engineering job at Amazon. I would have been engineer #14. I would call Bezos at home and he would call me in my dorm room in college. I went out to Seattle and kicked the tires, and the engineering team was definitely reflecting Bezo’s super-geek personality. They were trying to solve problems that were a long way from critical. I passed on the job (though largely for other reasons, maybe the topic of a future post).

In any case, I discovered years later that the API with external merchants reflected many of the characteristics I had observed in those early days - it was overbuilt, had too many features, and was designed to handle every possible scenario in this known universe, at the expense of actually being usable by 99% of small businesses.

I pointed this out to Amazon, and showed them a well-designed API,, but they just shrugged it off. Note that they may have updated their approach in the past year.

The reality is there are not that many fields that need to be passed back and forth to ship a simple package. This could have been done with a very small xml file to the vendor, such as Dan’s, and a very small file passed back.