Version 1.0

Version 1.0 IllustrationI have to say that the number of comments I’ve received about my posts about the WOW customer experience has been gratifying. Some comments have related to the need to get things to market now and letting quality and functionality follow, which I find incredibly short-sighted in the majority of cases, while others have agreed with me about the need to get things right the first time if you want to avoid headaches in customer support down the road or the actual failure of your company due to bad product reviews.

The best comment, however, came from my good friend Peter van Geijn in Munich, Germany. His company sponsored my seminars and workshops in Germany in the 1980s and he recently reminded me of the story I used to tell about Version 1.0.  It goes something like this…

Did you know that the only people who never miss a development schedule milestone are software design engineers?  That’s right, software engineers. If today was the day they were supposed to deliver the product, today is the day that they will deliver it. It will be called Version 1.0.

It will be missing a lot of the originally specified functionality, of course, since there was no time to implement it all during the unrealistic management-dictated, all-too-short schedule, but it will be delivered today.  As Version 1.0.

It will also like contain a large number of “undocumented features,” known in the old days as “bugs,” that will have to be addressed in a future version release. But it will be delivered today. As Version 1.0.

Marketing and sales people hate Version 1.0 because it makes selling the product successfully more difficult and causes customers to complain to them — a lot. It also makes it difficult to get early testimonials and delays the purchase of large quantities of the product until the bugs are worked out.

Designers don’t mind. They keep cranking out new code and patches for the bugs. Sometimes it’s great job security and other times it isn’t. If it isn’t there’s always the next product for the next company to be developed.

Customer support managers love it for the job security reasons as well — subject to the risk of no job at all if the product can’t be fixed in time to save the company.

If the product was developed with OPM (other people’s money), top management will get rich in any case and move on to start another company where they can dictate another unreasonable schedule for a product that must do everything, cost nothing and be done yesterday. It is called Version 1.0.

I’d love to hear your experiences with products that fit this mold. Please share them and thanks for reading.

 

Creating the Customer WOW Experience

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?