Error management: treat it as just another essential part of functional requirements

TL;DR. If you don't, your competition will accelerate revenue faster and leave you behind.

Why it's important - better yet critical

Why is it so important to treat error management as just another category of critical functional requirement?

Because when the errors occur, it’s an opportunity to delight the customer – despite the very situation when the customer may be at risk of losing faith in the product.

Cryptic or confusing error messages can create significant doubt which can become its own fuel of further doubt.

Just imagine when the customer asks …

– “If this simple functionality is not working, what else may fail tomorrow?”

– “What’s the status of my payment? I submitted the order and have no idea if the payment has been accepted”

– “What does ‘unknown error’ mean? Who writes this stuff”

Or – the customer may react to a confusing error message and decide to take steps that may make matters even worse.

Let me paint another scenario that every Chief Revenue Officer does not want to see.

It’s a customer that provides a poor reference to a potential customer because they are very unhappy with the quality of the software. The length of the sales cycles just doubled or tripled, delaying the sale and revenue recognition milestone (let alone cash).

Or - customer attrition rate is now greater than customer acquisition rate. Without any meaningful feedback.

That’s why it’s important to recognize error management as a critical functional element in design activities and subsequent design reviews. Is the depth / complexity of the functional problem properly reflected by the error management approach? I suggest to ask this question during the next design review.

I already hear some rumblings in the distance. 🙂 Who has time to do this? Well – the cost of not doing this is even greater. One of my former clients was spending more than 60% of total engineering capacity on looking for the root cause of reported problems, instead of developing customer facing functionality.

Let's do simplified math together. 220 engineers at $100K per year = $22M annually. 60% of their time - or $13.2M annually - was spent on diagnostic efforts, with a lack of meaningful error messages or misleading error messages being the primary concern.

In other words, $13.2M was not invested in building new functionality and retain or win new customers.

The competition was more than happy to turn win-loss ratio in their favor and almost succeeded.

Conclusion

This story does end well.

Within 3 years, my former client accelerated product roadmap and became a clear leader. The private equity company which owned their main competitor approached my former client to acquire the company for a fair price.