Keep it simple, it may lead to a love story!

We need to keep our products simple. Simple is better. Simple is easier to use. Simple is easier to change and adjust. But most importantly, people just LOVE it when it is simple.

I am not saying that we should build a dummy product that only does simple tasks. I am saying we need to think hard how to answer the usecases in a simple way. And we need to carefully choose the usecases we want to tackle.

“The road to hell is paved with good intentions” – no one wants to end up with a product that feels like hell. We need to be aware of complication that will eventually make our customers miserable. By trying to answer ALL usecases of ALL users, we tend to add more and more tweaks to the feature. One more button, one more option, one more step to the wizard. Sentences I hear a lot are “but this way we will also gain usecase #3”, “But there was a customer that we met that wanted to have it this way” etc…

We must remember - every time we are giving our customer more than one option we are making him choose. Every more step in the wizard is more work for him. Every time the customer needs to try and figure out why something just happened in our product, or what will happen if he will push this button – he is wasting his valuable time.

Think of yourselves when you are using your day to day products. What is the one thing that really makes you happy? That delights you? Simplicity! Whenever we are using a product that we do not need to think in order to use – we are happy. Whenever it does exactly what we expected and we didn’t need to give it a second thought – we are thrilled. We want it to be easy, simple, and predictable. Will we ‘forgive’ the product for not having one more complicated feature? In my opinion, if we love it, we will forgive many things. That’s what people do when they are in love.

But, what should I do if there is a super important customer who really need the complicated scenario?  you can have a very simple, easy to use product, which allows also complicated scenario’s but there are never interfering with the main simple usecases. The advanced user will be able to use them but the other ones won’t pay the price for it. I still recommend to avoid it whenever possible, but this is a way to keep your product delightful while answering an important user usecase.

We should also consider code simplicity. I know you will say it is the R&D job, but we have a role here too. Complicated code will always come back to haunt us. It will probably produce many bugs, will be hard to change and adjust and will be hard to maintain. All of these cost time and money, which we could have spent on some new, cool and simple features. When we are keeping the code simple, we are investing in the future. We are investing in quality. Quality is crucial for our customers to LOVE our product.

There is a price here. We might not answer all of our customer’s usecases. We need to make peace with it. We need to accept that in the name of simplicity, we might be giving up flexibility. We are not going to make all dreams come true. It is OK. It is our job.

I am more than aware of the pressure. I am living it. Customer requests puts a lot of pressure on the product and sometimes on the management to get a new feature. We have to keep our eyes on our goal. We want customers to LOVE our product. We want it to be as simple and predictable as possible, with high quality. We will add a feature to our system as long as it doesn't ruin it. When we are ‘sacrificing’ a feature – we are doing it for a good cause. Keeping our product simple. Making our customers fall in love with it.