SmoothSpan Blog

Do you have any special customers that your developers hate?

These are the customers that can mysteriously break your products over and over again, even though perhaps thousands of others report no problems.

How does this work?

First, understand the psychology of bugs.  Developers don’t consciously create bugs, they come about as errors of omission, misunderstanding, distraction, and incomplete thinking.  Sometimes they’re a result of interactions between complex connected systems that the Developer does not understand or did not foresee.  Most Developers are pretty conscientious about not wanting customers to see bugs, and about getting them fixed quickly.  At my last startup, the Developers were part of the Customer Service crew, which gave them an even keener sense of the customer’s perspective.  Believe me, they wanted their bugs to stop hurting these customers!  BTW, I use that language of “bugs hurting customers” on purpose, because that’s what it feels like to Developers when they get to experience the customer’s pain firsthand.  I highly recommend it!

Yet, we still have bugs.

Second, consider how it all looks to the customer.  The first thing you have to do before you can put Developers on the phone is to get them to quit taking bugs personally and assuming the customer is wrong.  The customer reports a problem, and the immediate assumption is it is the customer’s fault somehow.  At least that’s how it can feel to your customers.  In reality, the Developer doesn’t literally think of finding fault, but they know the customer is doing something different, something they didn’t think of, and they have to get to the bottom of that as soon as possible.  In the worst case, it feels like a witch hunt to your customers when it shouldn’t.  If customers understood why the questions were being asked and why were they asked in that certain special Developer bone headed way, they would understand more.

Getting back to those special customers, they are the ones that do things differently than the vast majority, for whatever reason.  For example, if I talk to a customer that works in IT, I always take a mental deep breath.  These are the sorts of folks that will customize their browser’s security levels, erect additional firewalls, and do almost anything else to really customize their machines to work the way they want them to.  The vast unwashed are going to run their machines pretty much as they come out of the box.  So, the IT guys see some bugs that the vast unwashed don’t, simply because their configurations are different.

If I’m in a crowd with my wife, trying to find seats, I always follow her.  She’s left-handed and she will make different decisions than the vast unwashed, who are largely right-handed.  We will magically wind up getting to a shorter line or finding the better seats that are still available.  If you know a left-handed person, try following them.  It isn’t just a matter of picking left instead of right.  They perceive all of the cues around them just a little bit differently when making their decisions.

Look for people with different hardware.  They’re travelling the less traveled road.  They will find things your mainstream may not.

I have known dyslexic people who did the most amazing things with software.  I have seen problems uncovered through random behavior.  To a certain extent, I have also seen concentrations of bugs as indicating not just that an area of a product is buggy, but that it has poor User Experience.  Why?  Because areas that have poor User Experience cause people to do all sorts of crazy things as they try to guess at how to work the feature.  Hence it flushes out the bugs.  Always consider UX as a possible source of bugs!  And while you’re tracking these bug concentrations, recognize that unnatural locuses of bugginess are either indicators of Bad UX, Bad Architecture, Bad Developer, or something really really hard that you’d better invest more systematic testing in.  Let’s call these “Areas of Special Interest.”

I unwittingly became one of those “Special Customers” for KISSInsights during the last week (cool service I will have more to say about in a later post).  I had a problem with my account they kept trying to fix and couldn’t.  I escalated all the way to the CEO.  Not only did the problem not get fixed, but problems like making me a premium customer for a month for free were apparently being broken.  Both sides were becoming increasingly frustrated.  Then we discovered the real issue–I had two accounts.  They were fixing the older one and I was viewing the newer one.  DOH!

So what’s the moral?

1. Embrace your special customers.  Reward them.  They are like gold because they’re finding bugs that others haven’t found.

2. Seek out people who experience the world differently when using software.  I don’t know if you can go to the extent of trying to make sure your testers include South Paws and Dyslexics, but OTOH, maybe it’s a good idea.

3. Keep an eye on bug concentrations as a potential early indicator of Bad UX, Bad Architecture, or an Area of Special Interest.

4. Make sure everyone involved recognizes that positives that come of an effective quality process.  Never focus on blame.  Reward progress in discovery, correction, and avoidance.