Fault Tolerant

One of the best ways for an expansion stage software company to reduce its customer support calls, save engineers time in solving customers’ problems, and generally have happier customers is to build software for scenarios that is not meant for!

Now, I don’t mean developing functionality for use cases that don’t align with the product’s vision.

I mean making the product fault tolerant.

Product managers should assume that the users of the product will do things with it that the product managers and developers never imagined the users would do. And then they should build the product based on that assumption.

For instance, say there is a configuration to your software that:

• Makes no sense, i.e. a user who knows what he/she is doing would never set that configuration to achieve a conceivable goal
• Will cause the product to work incorrectly or crash

Instead of assuming that the user will never set this configuration, make it so that the user can’t set this configuration, by conditionally controlling what can go into fields, warning messages, helpful error messages, and so on.

A lighter example is a pop-up confirmation message for critical functionality, like, “You are about to delete 500 records. Once the records are deleted, you will not be able to recover this. Are you sure you want to do this?”

Remember, Agile development methods are ultimately all about making the customer happy.

Typically, product management and development teams equate making customers happy with allowing them to do more stuff with the product.

It can also mean not allowing them to do certain things that are bad for them!

And saving a ton of resource on resolving preventable customer issues is pretty good for the overall product management process and your company’s bottom line.