What I Learned From an Unscheduled Trip to Cleveland

Bob Hruzek has a new "What I Learned From..." project running, this time concerning work. Because I started my unfortunate illustrious career in product support, I learned a whole heck of a lot in a short amount of time. An MBA from the School of Hard Knocks.

One of the products I supported (yes, I was the entire product support group), was an integrated voice and data terminal. [Google search for picture was fruitless] Imagine a machine about the footprint of a laptop. Then put a 9" CRT sticking out of the right side and a handset on the left side, with a corded keyboard you could either stick under the unit or pull out to type. The devices had a built-in phone/address book and terminal emulation capability (hey, the IBM PC had just come out; who knew they would end up on everybody's desk?).

One of our beta test customers was a conglomerate based in beautiful Cleveland, Ohio. They had outfitted several of their top executives with these devices. The initial installation and training seemed to go fine, but almost immediately we started getting calls telling us that the autodial capability from the built-in phone directory didn't work. But not for every entry. It seemed almost random. We tried to reproduce the problem in our lab, but couldn't. We entered all of the entries they had into one of our machines, but every one of them worked. Worse yet, our on-site techs would create duplicate entries that worked just fine! After several days, the sponsoring client executive blew a gasket and demanded that my boss and I show up in person to resolve the problem or he was going to throw all of the equipment out the window (that's what he said anyway, and they were 14 floors up)!

So my boss and I packed up a bunch of test equipment, including some fresh-from-the-lab non-UL listed prototypes, and headed off to Cleveland. We arrived mid-afternoon and were escorted to his office, which was larger than my first house. The executive himself was out of town until the next morning, but his administrative assistant showed us to his desk and the device in question. We got into the phone directory and looked at the first two entries:


We pressed autodial on the first entry, and the call went through fine. We pressed autodial on the second one and it failed.

"It seems to be stopping at that one", my boss said.

"That's because it's a lower case L", I replied.

We looked at each other with that "it couldn't be, could it?" expression, but after another 30 seconds of checking, the pattern was clear.

"Who created the entries in the phone book?" we asked the AA.

"I did", she said. "I didn't realize they would be a problem." Sure enough. All of those seasoned assistants had learned to use L's and O's instead of numbers as a way to keep their fingers home-rowed many years ago in typing school. On paper, they work great. But those damned computers weren't smart enough to know what they were doing.

In about 15 minutes we instructed all of the executives' admins how to fix the problem, and everything was great. When we met with the sponsor the next morning, he was more than apologetic. And he went from being one of our biggest detractors to one of our biggest proponents.

So what did I learn from all that? That the old saying is true: You can never make anything foolproof; fools are so ingenious.

Actually, the real lesson is that you can test a new product every way imaginable, but that your customers will find a way to break it almost immediately. Plan to deal with it gracefully if you want to keep them happy.