Dateline April Fool’s Day – Austin
I was in a meeting recently where a vendor was trying to save an account from moving to a competitor. The big issue was the usability of the software. Counterintuitive interface, frustrated users – classic anti-productivity tool. We’ve all been there. As a marketing person, I tend to notice phrasing, especially when it’s intended to cover obvious product flaws. (Remember Audi’s “unintended acceleration” as a way to describe an unsettling number of Audi owners somehow driving through their garages, store windows, etc?) The phrase in this case was “user experience challenges”. It made me smile and wince at the same time.
The vendor plan to help resolve the user experience challenges included a consolidation of support information, help, forums, knowledge bases enthusiastically named Customer Central. It’s going to have federated search capability to help users find all the answers they need to solve the problem they’ve got with the software. It’s great stuff, including the roadmap with the slides describing how the user experience is going to be fixed.
Unfortunately, all that effort is totally missing the point. The problem with the vendor’s product was not a lack of support, lack of available information or inexperienced users. It was a fundamental design flaw – or group of flaws. This is a tool used by marketing people, built by engineers and documented by technical writers. Massive perspective mismatch. Describing this mismatch as a user experience challenge and fixing it by aggregating a huge amount of content to be accessed with a nifty search engine won’t fix the basic problem. It sounds good and might even look good. Still lipstick on a pig. Expensive and time consuming lipstick. Still a pig.Support Shift
There’s been a shift over the years in software product support. Long ago, when Zippy was a just a gleam in his great-great-great grandfather’s eye, you could buy a support contract that would deliver a person to your site to fix whatever was wrong (or even have them live there). You also got great big, detailed manuals. Costly but effective. For less money, you could call someone on the phone – marginally less timely but lots less expensive. Then came email support, built in help, online help, knowledge bases, community forums, social networks, and next…tweets (although I haven’t seen Twitter used for support yet, it's coming). The sources of support have become so diverse that a federated search engine is a “feature” to help users to get what they need. The important issue with this shift is that the burden of support has moved from the vendor to the user. That’s backwards and ridiculously expensive in terms of man hours required to deal with product problems.
To be fair, high speed networks, user forums, terminal services, etc. have all greatly improved the quality and lowered the cost of support for just about anything we use on a daily basis. Wouldn’t give any of it back. But…it has allowed companies to claim progress on improving their product when all they’re really doing is making it more fun for you to solve problems on your own. Success by Design
I grew up with an architect as a dad. He definitely made me appreciate the value of things that were thoughtfully put together. The key to success, Dad always said, is to get the fundamentals right. Don’t just engineer, design and engineer. Think of some complex technology that’s been successful – it’s typically because the complexity was masked and great engineering made sure the design was well executed and the end product was reliable. My favorite examples are the iPhone and of course Pervasive PSQL. Huge Customer Base, Tiny Support Staff – How do they do that?
Pervasive PSQL has thousands (maybe 10’s of thousands) of developers and literally millions of users. (This is what happens when you’ve been shipping a product for 25+ years.) We’ve also got active community forums, a great knowledge base and thorough documentation. Care to guess how big our support staff is? Six. Yep – just enough for a basketball team with one sub. A staff of 6 supremely talented support people who can answer the most arcane PSQL question faster than Zippy going after a breakfast taco. Most of them have been with Pervasive for 10 years and some for much longer. They’re also a pretty relaxed and friendly bunch – not the stereotypical antisocial “this product sucks, my customers are idiots, and I hate my job” employee accidents waiting to happen. That means the customer to support person ratio is something like (being really conservative here) several hundred thousand to one.
Believe this is possible just because we’ve got six smart support veterans and a great customer site with a federated search engine? I didn’t think so. That ratio only happens because Pervasive PSQL is a well designed, well engineered, constantly refined product that the vast majority of customers never worry about. For the developers who do work closely with PSQL and the end users who have it running their business applications, PSQL just works, and keeps on working. And that’s why, thank goodness, I don’t have to spend my time thinking up ways to put lipstick on a pig. No foolin’.