Tag: software

I am flabbergasted. Incredulous. Blown away. Still in shock.

I  just came from a meeting of 50+ people who listened to four very bright and sincere customer service/customer support representatives from start-up companies in Portland talk about how they create the customer WOW experience when confused, disgruntled, frustrated or just plain mad customers call in because either they can’t use the product the way they want to or the product doesn’t perform as advertised or something else has gone awry between product functionality and customer expectations.

Hold the phone here, please! Why is customer support charged with creating the WOW experience? Why is top management charged with forecasting how many customer support people will be required based on sales volume? What if — and this is a revolutionary concept, I’ll admit — the product actually worked when it was delivered? What if it had a logical “idiot proof” set of controls or an error-resistant operational flow?

During the meeting I was taken back to my days in the 1970s when I taught electronic engineers how to design circuits to be easier to manufacture, test and service.  In fact I wrote the first book on that subject — Design for Testability — and later authored Managing Concurrent Engineering, a tome that proselytized the simultaneous design of a product so that it functioned as designed, could be economically duplicated in manufacturing, could be tested thoroughly to be fault free when shipped to the customer and could be serviced quickly and economically when it did fail.

When trade-offs had to be made between product functionality and the “-ilities,” product functionality almost always won out. In fact “feature creep” was one of the key problems that caused delays in getting products to market. But product functionality testing, or design verification as it was called, was held in the highest regard because the cost of shipping something that didn’t work as advertised could be huge enough to put a company out of business long before it could fix the problems in the product.

As I sat down to write this I noticed that Casey Wheeler had shared Seth Godin’s blog entitled “What’s in the box?” in the Oregon Entrepreneurs Network group on LinkedIn and that Michael Temple had commented on it by quoting Guy Kawasaki in The Art of the Start as follows: “… too many start ups try to work out ALL the bugs before taking their idea to the market. The only way to know if what you have to offer will work is to get it out there. Correct the mistakes as the feedback comes in. In time, you will perfect what you are trying to develop, but you will need the public’s help to identify what needs to be corrected.”

Well I beg to differ with Mr. Kawaski, folk hero to so many product developers as he may be. Because product development teams following his advice are the reason that four customer support people are still holding meetings like this for 50+ people audiences 40 years later! It is incredible. Shocking. Deja vu all over again for me. I’ll repeat my earlier question: What if the product actually worked?

I’ll be the first to admit that perfection is nigh impossible to achieve in a first product release. And that there comes a time when you must declare the product finished and get it out into the marketplace. But if you know it has issues, sell it initially to early adopters smart enough to work around those issues, not to the non-techie masses who need customer support people trained not only in solving product problems but in dealing with frustrated customers as well. Can we at least think about these issues early on in the development process?

OK.  Got that off my chest. I think. I have lots of stories about getting things right the first time instead of doing them over again. Including Deming’s story about the Japanese and the American companies making toast. I’d be happy to discuss my opinions on this subject anytime and welcome your comments. What do you think?