Your customer expects your product to work, to solve their problems, especially when they’re paying for it. While most customers can forgive a small kink in the machine once or twice, repeatedly seeing the cracks in your product will affect their confidence in it, in you. Incidents happen, what matters is your reaction to them.
Bugs should not happen, it goes without saying. Like most truisms, it’s easy to believe, but hard to apply. Even in the best of conditions, with strong testing frameworks and adequate quality assurance, bugs, human error and system failures do sometimes happen.
In such situations, rather than playing the blame game, or getting lost in hindsight, you have to think about the present, and the future.
A bug should never happen twice
When a customer is impacted by a bug once, it’s mostly fine. You can work with them to mitigate their loss, compensate them for lost time with a discount, and assure them that the problem is fixed. On the other hand, if they face the same issue after you promised them that you fixed it, they will get mad, and reasonably so.
Whenever you correct an issue, you must ensure, by any way possible, that it will not happen again. Write a regression test. Collect as much information on their specific case, assert the exact circumstances. Plan for edge cases.
A bug is a chance to demonstrate great support
There’s a silver lining. The difference between good software providers and great ones is their capacity to react quickly to customer issues, and demonstrate above and beyond support quality.
I’ve had relationships with customers improve after they experienced a bug, several times. When a customer has a problem, take the issue head on.
Don’t wait for it to go away. Don’t hide behind corporate/legalese speech. Do not bullshit your customer.
You, or someone on your team made a mistake. That’s on you, it’s almost never the customer’s fault. Take responsibility.
Explain to the customer what happened, why it happened and what you are doing to fix it, in layman’s terms. If it’s gonna take a few days, tell them. Don’t let them simmer and wait for an answer. Their imagination will run wild with what if’s.
A bug is a chance to review your workflow
An error making it to production is a clear sign that something went wrong along the line. Again, the point is not to find who to blame, but to understand what circumstances led to this situation.
You might be working under unreasonable stress or deadlines. You might have inadequate communication between teammates. Someone might be physically or mentally unwell.
The vast majority of bugs aren’t because of a lack of competence. They don’t happen because the engineer doesn’t know how to do his job well. They happen because of a non ideal environment.
The quality of your work, and the productivity of your team both depend on a rewarding environment, and a smooth workflow. It’s easy to forget things or cut corners while under heavy stress or distraction.
Even if you work alone, you should create tight workflows. Make checklists of everything you need to verify before shipping a feature. Even if it seems redundant, go through them every time.
Customers experiencing bugs always feels bad, but it’s a chance to grow as an engineer, a product owner and a person. Don’t take it personally, rather take the opportunity to improve your circumstances, your work environment and your methodology.
Your customers will appreciate your dedication with renewed faith in your product and ethos.
You will end up better prepared for the future. Remember, it’s not what happens that counts, it’s how we react to it.