How to make great products: recover like a boss


So you want to make a great product? Good, because this is exactly what every customer out there looks and hopes for when he tries your product.

“How to make a good product?” – I sense that it’s on your mind right now. Well, here is something all great products have in common:

A great product always recovers gracefully after a crash.

Once upon a time

Six people had to get together to discuss the plan for a new product. Each one was living in a different city thousands of miles apart.

Fortunately there was a video conferencing software used across the company. Thus no one had to leave the comfort of their homes or offices.


As M was talking and explaining the grand plan he put together with A, suddenly he heard C saying: “We can’t hear you!”. M checked his mic settings just to discover that there was nothing wrong with it. The video conferencing software was not able to send the sound upstream.

As A picked up the baton and continued the presentation, M tried to get back online. He tried to call in again with no success. Next, he restarted the video conferencing software and dialed in again. This turned out to be the fix. At that point M was quite upset with the video conferencing software. Nice thoughts were constantly addressed to its makers.

Why was M upset? Because he got cut out while talking with his Vice President? Maybe. Or maybe because the software failed to recover from a critical error on two big accounts: not surfacing to the user that sound was not working and not offering a quick and simple way to re-dial to the last meeting.

Errors, death, and taxes they say. How errors are handled makes a huge difference for user experience.

How should this error have been handled?

First, it should have done a better job around the code that uses the mic. I don’t have access to that code so maybe they’ve done everything possible there. OK, but how about starting a new call and still not being able to use the mic? There was no information that the mic is not usable for the app.

Second, it should have implemented the call history log using a bit of common sense. As a last resort, M decided to kill the app and restart it hoping that this will fix the sound problem. Once the app has started, M picked up the first entry from the history log just to find couple of seconds later that it was not the last number he dialed in. Basically the order in which the numbers were listed had nothing to do with the time when they were used.

Beat this is if you can. Really, think about it: for years any phone (smart or not) has a feature that shows you the calls you’ve made or missed and that list is ordered by timestamp by default. So why get creative when implementing this feature?

Bonus: it could also have thrown a message to the user filled with self-mockery: “We totally ****ed up! We have no excuses here!”.


Complex and powerful apps can be great. Simple, utilitarian software products can be great. The path to greatness starts with how you choose to treat your customers: with love, indifference, or hate*.

How you help the user to continue his flow after a critical error occurs makes a huge difference. If she manages to pick-up from right where she was with next to no effort** then you are all good. If not, then you’re failing big time.


  * More on this in a future post;
** Depending on what the user was doing, when your app crashes she might have been under lots of stress already. In this context, if your recovery flow is not straightforward it can only increase the stress and dissatisfaction with your app.

Leave a Reply