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.

posted by Mike at 6:11 AM


Blogger Robert Hruzek said...

I know you're not kidding because this is just too common. Your summary is great, too - both of them. Thanks for joining in the fray, Mike!

3:00 PM  
Blogger Mike said...


Thanks for the kind words. The question is: would you read it?


3:11 PM  
Anonymous Anonymous said...

Hi Mike

You asked: "The question is: would you read it?"

To be honest: I had to read your post twice before 'I got it' !
So, twice as impressed with you're ability to have spotted the 'mistake' ;-)

Karin H. (Keep It Simple Sweetheart, specially in business)

6:07 AM  
Blogger Mike said...

Hi Karin,

"Would you read it" actually refers to this. Take a look if you like.


11:34 AM  
Anonymous Anonymous said...

Saw your comment on my entry for this project, and I thought I would stop in to take a look at yours. I'm glad I did. Very nicely written and a good "punch line." It reminds me of a Douglas Adams quote: "A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."

That made me laugh, but the second conclusion made me think. Thank you for both.

12:30 PM  
Blogger Mike said...


Thanks for stopping by. I think my "you can never make anything foolproof" was a poor imitation of Adams' line.

And having been in product support, I KNOW the second conclusion is money in the bank. I lived it. And at times, it made me pine for my roofing days! ;-)

12:38 PM  
Anonymous Anonymous said...

"You can never make anything foolproof; fools are so ingenious." Even if that line is from Adams, I'd never picked it up from his writings - hilarious!

5:34 PM  
Anonymous Anonymous said...

I like this post. My husband worked in product support for five years. I certainly agree that it is an education in and of itself.

9:29 AM  

Post a Comment

<< Home