When you start building software you generally try to solve a very precise problem you have identified. You come up with an easy and clean solution to address the problem “et voilà”, the magic happens. Some people find your solution interesting, they start using it and then you might even sign them as your first customers— and that’s where problems start.
With time you’ll have more and more customers asking for specific features they think are essentials. Some prospects will tell you that your software is great but is missing this or that and, as all software companies, you will start adding features. If you’re smart enough you will learn to say ‘NO‘, and choose very carefully the features you want to add.
Listening without filtering your customers’ requests would turn you into a bot and your product into a spaghetti plate – and even though I love spaghetti vongole, it is not what I want for software. Nevertheless, no matter how good you are at saying ‘NO‘, you will still have to add features.
Building features to software is still one of the most underestimated tasks in terms of workload. This is especially true with SaaS software that are updated live with thousands of customers, as is the case with noCRM.io our software for sales teams.
To illustrate, I will share with you an intimate part of my life with a lot of great, high-quality pictures.
As with any new feature, my story begins with a problem.
The Problem
I have an extraordinary wife (she might read this post), and that extraordinary wife had one problem with me -let’s say at least one problem- and that’s my toothbrush.
I use an electric toothbrush, which is a solution for people who are very poor at cleaning their teeth. The electric toothbrush is heavy and stable enough to stand vertically on the bathroom countertop; unfortunately it leaves a white stain on it.
Every morning my (extraordinary) wife wakes up earlier than me and gets upset by that toothpaste stain. She would clean the mark on the sink while complaining about the mess I kept leaving. However, for some reason, I couldn’t put my toothbrush anywhere else. It was a Pavlovian reflex.
After a while, my wife changed her strategy and stopped cleaning the stain off. Instead, she moved the toothbrush to the side so that I’d be able to clearly see the white stain when I’d go into the bathroom. Since then, I’d see the dried-up toothpaste every morning and wonder how I had forgotten about it again.
It’s safe to say that we had a problem that needed fixing.
The Feature
After several weeks, my wife came home with a solution (I told you she was extraordinary): a toothbrush holder. A great new feature that was a perfect upgrade for our sink software.
The new toothbrush holder was designed to perfectly fit an electric toothbrush. There was even a small hole in the front that allowed excess water to escape in order to prevent water buildup in the toothbrush holder. Overall, it was a great feature designed to solve a specific problem.
It was time to deploy the feature in our bathroom!
The Deployment
A feature designed for a product or service is rarely “ready-to-ship”. After deploying the new toothbrush holder, it was clear that there were still some hurdles to jump. The handle, which was drilled into the wall, for the previous toothbrush holder meant that the space for the new one was minimal.
My wife decided to remove the original toothbrush holder cup to create extra space for the new one. However, there was still the problem of the handle sticking out of the wall. With it being drilled into the tiles, just removing the handle was not an option.
After examining the structure of the handle, I realized that—while it couldn’t be removed from the wall—it could be rotated. Progress was being made.
But wait, there is more. We forgot about the water extraction. We had to turn the toothbrush holder around so that the water doesn’t seep into the wall tiles.
On the fourth iteration, the problem was finally solved. Gone are the days of dried-up toothpaste sticking to the sink. Everyone was happy—especially my wife.
The Complexities
Knowing that the feature was perfect, something as simple as fixing a problem surrounding dried-up toothpaste took four attempts and required multiple people to implement it correctly. Imagine the trials and tribulations involved with creating and deploying a feature to thousands of customers.
Much too often, developers tend to think that a new feature is just a set of new functionalities. They fail to understand how important it is that the feature integrates correctly into the existing product. Releasing a feature is much more than just coding and that’s something very difficult for a team of developers to understand – the same goes for other teams who too often forget to give essential feedback.
I came to this realization after the deployment of an important feature in noCRM, our lead management software for sales teams.
When prospecting, it is important to log what you have done with a prospect so that you can start the next call or meeting with all the right information and the right context. In our software, it was possible to log a comment but not to define the precise activity that had been done (for instance, a call, meeting, email, lunch, etc). The feature we built was great (it included predefined outcomes, statistics, calendar sync…) but after deploying it, we didn’t see a raise in the conversion rate, in fact, it was the opposite. We experienced a minor decrease in the rate.
When building software, you must invest time in the development of features that you expect will add value to your software solution and enhance your customers’ experience.I started digging into the app and the feature and I realized that there were several minor bugs, but mainly it was the way we had implemented it that was conflicting with the way we were onboarding users.
Basically, we were asking new users to set a next action but when they did, the information was badly displayed on the lead. It was as though the next action had disappeared from the lead card. For a newcomer, it was like the app was buggy.
Once the problems were identified, they were easy to fix. However, if I weren’t so obsessed with numbers, we might have missed the point for several months.
The Moral
First, you have understood, I have an extraordinary wife (even though I doubt she’s read up to here). Second, building features is not just adding lines of code. It’s not even just adding help articles for the feature, communicating it to users and the rest of the world, updating the website, or translating everything to every language supported. Deploying a feature is also checking:
- how it integrates with the rest of the app;
- how it disrupts the current usage of your actual customers;
- how it disrupts the way you onboard new users;
- how it could affect the understanding of your software’s core value at first glance;
- how it impacts your business in terms of numbers;
- how it impacts your technical architecture;
- the feedback of your current users;
- the usage in terms of numbers of your new feature.
Lastly, marketing and support teams tend to believe that a feature is built in a certain way and that’s it— it can’t be changed. They don’t communicate their feedback enough with the product team nor are they critical enough of the released feature (in a constructive way). Everyone thinks that they have completed their part of the job and see invisible barriers that aren’t there.
Delivering a great feature requires teamwork that will extend for weeks. It’s important to understand that there is approximately 0 chance that you perfectly deploy a new significant feature and “voila”. If you want to illustrate this in your company, feel free to share my toothbrush story with your team.
Keep in mind, a good feature takes long.
