The Daydream Blog

In my last post I highlighted, what I felt was, a case of poor customer service by a fellow developer. Even in the most unhelpful customer feedback, there lies the opportunity to glean a valuable lesson.

Rather than pick another whinge from IRC or Twitter from a fellow developer and risk alienating the entire Mac developer community, I am using an example of feedback for my own product, Differencia.

The following information was just submitted via the DayTime Software Internet site Contact form.

First Name: John

Last Name: Dontwantoleavemyname

Telephone Number:

Email Address: fakeemail@yahoo.com

Message:
Your program is difficult to use and confusing. Take a look at standard “diff” programs for text. This program should emulate those, because that is what users are already used to, and the programs work well. Instead, you’ve created a whole different paradigm that just left me scratching my head. Templates? Okay–a great option. But what if I don’t have a template or don’t want to bother with one? Plus, the program crashed several times on me. This needs a lot of work if you’re going to sell it.

There was no way for me to respond as no valid contact information was left. Others might complain that he did not “get” my product, or that his feedback was very unconstructive. In fact that was my first response as well, and tweeted as much.

The main point is that Differencia is not a “standard diff program”. It is intended to work with data files that standard diff programs cannot handle. A new paradigm, as he puts it, was required as other diff programs simply cannot handle the use cases that Differencia was intended for.

However I have gone back to deconstruct the feedbacl, to try and understand how he failed to understand the product.

The lessons I learnt are:

• I have optimised the site for search terms that include “diff”. This is precisely to attract people looking for diff programs that handle exceptional cases. However I do not stress heavily on the site that Differencia does not (currently) handle non-structured text files such as source code or documents.
• I have not, perhaps, emphasised enough on the site that Templates are a convenience but not a requirement for Differencia to work well.
• I have not done enough testing with source code and other file types to ensure that they do not trigger crashes.
• Not a new lesson, but I know that I need to do a mix of usability improvements and add tutorials to the website / product

Instead of bemoaning hyper-critical feedback and how useless it is, I have taken stock, assumed there is something I can learn and improve on, and worked hard to gather something positive from the feedback.

Garrett Murray, developer of Ego, an iPhone web stats aggregator, recently posted a difficult support experience he had. (Via Tim Burks on Twitter):

In summary, Ego’s Google Analytics access stopped working because Google felt too much traffic was coming from Ego’s server and blocked the IP address. Is this the customers’ fault? No.

Several users voiced their problems on a 3rd party support site called Get Satisfaction. Murray responded, on Get Satisfaction, that the problem had been resolved with Google, an update had been submitted to the App Store and was awaiting approval. Crucially Murray marked the issue as “solved”, before the update had been approved by Apple.

Murray initially complains about the length of the approval process, which, given that it’s been over a week since he submitted the update, is probably valid. Is this the customers’ fault? No.

However Murray then goes on to highlight the complaints of one user, who was unsatisfied with his response on Get Satisfaction, and created a negative review on the App Store. The App Store does not allow developers to respond to reviews, which again is a fair criticism. Is this the customers’ fault? No.

The user’s review on the App Store was:

I bought this because it claimed to support GA. It worked for me one time the day I bought it and hasn’t worked since. I posted to their support forum and was berated for not reading this long and confusing thread about how it is supposed to be working, or it will work again soon, or something. I feel like the software developer did a poor job building and testing this, and now they’re willing to blame the users for their own mistakes.

Which given the Murray’s own blog post and the situation in the Get Satisfaction thread is exactly correct. Pointing users at a separate thread, as if to say “You should have looked first” is rude and obnoxious. If your software is broken, apologise, explain and apologise again.

Murray defends setting the issue as resolved by saying:

Apparently they didn’t understand that “solved” was a relative term. Yes, sure, it’s not solved for you right now, but my resolution was pretty clear—it’s solved in the version Apple is looking at. JUST HOLD TIGHT. I thought this was enough. But no.

This is just plain ridiculous. “Solved is a relative term” is utter rubbish and a completely idiotic stance to take with your paying customers. With software there is only ONE definition of “Solved”; when the issue is solved for the customer who has paid good money for the product. . Until the fix is in the users’ hands, the problem is OPEN.

It highlights the stereotypical blinkered developer attitude that once a problem is “fixed” in code, that is the end of the matter.

I have multiple examples in my support log, where I have sent a user a response, asked them to contact me if it does not solve the problem and never heard anything back. In my support system I often wait months before marking these issues as resolved. Unless I hear from the user that the problem is fixed, then as far as I am concerned, it is not.

Murray goes on to say that:

Apple is creating an ecosystem of the kind of customers I don’t want

Well Garrett, if you don’t want them, I’ll quite happily take them off your hands.

John Gruber describes the user as an “asshole” on his heavily read Daring Fireball blog.

This is completely outrageous. Ego’s users have paid good money for the product and rightly expect the product to work as advertised. The issues with Google are not the customers’ fault. Even if everyone has done the best they can, the customer is the one least at fault, having paid for a product that DOES NOT WORK.

As for Gruber’s incendiary remarks, I personally would sue for defamation if I was described in that way.

So often as developers we fail to put ourselves in our customers’ shoes. The user had a faulty piece of software, went to the support site (many wouldn’t go that far), filed a complaint (fewer still), saw a response that belittled him and told him that the problem was solved, when it clearly was not. What other recourse does the user have other than to write a negative review?

There are several lessons to be had from this:

1. Program Defensively: the product should respond sensibly when the Google API did not work, rather then report “0 Visitors”
2. Program Defensively: provide a support link from within the application
3. Respond to every customer complaint individually. If it is a known issue, state that it is, but do not expect the customer to know that. Apologise, explain, apologise again.
4. Treat your customers with respect. A customer who has paid you money owes you nothing, whereas you owe him your livelihood.

As I have stated many times before, the customer is always right and there are no stupid users, just stupid developers.