After Your Software Breaks

Even if you implement Agile development methods and a best practice process for quality assurance, there is still a chance that your software product will go out with a critical defect that your customer will discover in a bad way.

This can happen to big companies like Microsoft and to smaller expansion stage software companies, especially when they’re short on both resources and time.

Once the defect is discovered, the development team should of course fix it, and then conduct a root cause analysis to find out why it happened, and put in place counter measures to make sure it never happens again.

But what about the customer?

Two weeks ago, I was on my way to a vacation. I was in Boston’s Logan Airport, having dinner and awaiting my US Airways flight — a domestic connection to a longer international leg — when my phone rang. The number was an 800 number that I didn’t recognize, but I answered it anyway.

It was a US Airways representative. She informed me that my flight out of Boston had just been delayed by 1.5 hours, meaning that I would miss my connection, delaying my trip by an entire day. She asked me if that was an option for me, and I indicated that it was not. She then put me on hold for 5 minutes, and when she came back on, she told me she had re-booked me on a completely different United Airlines flight, with different connections, that would still get me to my ultimate destination — and only 2 hours later than initially planned.

Fantastic news!

This was in stark contrast to what happened to a friend of mine, who once lost a whole day of his trip because of a delayed flight, and to a couple I met on my trip, who lost an entire day of their vacation because their first flight was delayed. They missed their connection, and their airline didn’t even call them.

What does this mean for software companies and their management teams?

First, fix the defect as quickly as possible!

But go the extra mile and turn a disaster into an opportunity to build customer loyalty and word of mouth.

Be sure to understand the implications of this defect on the customer’s business.  What pain has been caused, if any? Can you do anything about it?

For example, did your software cause the loss of data? Can you do anything to recover that data?

Is the defect preventing a critical workflow from being executed? Can you come up with a temporary work around that which the customer can use while the defect is fixed?

And so on. The key is: Be proactive in understanding the pain, and do what you can to resolve it. It pays.

I told everyone in site about my great experience with US Airways, and everyone was very impressed, especially those people who didn’t have as good an experience with their airlines. At the end of the story, people asked, “Who was your airline again?” They wanted to remember.

The original flight delay — the defect — didn’t even matter anymore!