Not everything is bloat. Some features are meant to be rarely used.
Let’s talk about feature usage and adoption.
What is common across these household products?
That’s right.
These are items you rarely or never need and yet you need to have them handy. Pray there is never a fire and you never have to use the fire extinguisher. Or an alarm system. But when you need it, it would be invaluable. You cannot apply the standard metric of usage to these items. By design they are meant to be rarely used.
In fact look around your house for products. Doubtless, you can Mary Kondo some stuff around your house. I know I should. But look for things you cannot do without it. Or check your kitchen cabinets.
You need certain items in the house even for those rare occasions. The cost or hassle of not having that item even in the least probable of event, is high.
The same thing happens in Enterprise products.
There were some posts recently that showed a report from a prominent software analytics company. The report suggested that 80% of the features are rarely or never used by customers. The report goes on to calculate the lost opportunity of where the time and resources could be spent on building something of more value.
Granted, the software company was promoting its own product to allow product managers to measure usage and adoption.
The reality however is a bit nuanced. At least in Enterprise B2B SAAS.
It is true that in Enterprise software, especially in platform software, roughly 50% of the feature sets are consistently used by a majority of customers. But the rest of the features exist for a variety of reasons. If you apply your standard metric of usage and say that less than 5% of customers use a particular feature then we should sunset the feature. And many companies do that quite often. Sometimes entire products are shut down e.g. Picasa from Google.
So why does this happen in the first place? Why the feature bloat? Or is it really bloat?
There are several reasons for having these multiple features hanging around your product.
Emergency or Infrequent use
Some features are just meant to be used in emergency or in one off situations. Think about backup recovery. You hope you would never lose data but when you do, this feature is a life saver. When you do an audit of your least frequently used features, consider if they will ever be needed by a good chunk of your customers. What might be a potential scenario where the user might need that feature. What is the probability of that happening.
And if the scenario happens, what is the impact to the customer. For example, if there is a data corruption and the customer cannot recover from a backup, it could mean loss of business operations. This is critical.
Now, this sounds like an extreme scenario and I used this to illustrate why such features exist. But there are many such examples of features that are life savers.
In the west, mobile connections are quite good but in the rare instance you lose a connection, you can use the offline mode on your app. A rarely used feature but a life saver in such situations.
Look through your product and see which rarely used feature are life savers. Keep those features.
It made sense when built
When you are a startup, you are still discovering features to add for your ideal customer. In that process, you end up building something that made sense then. Perhaps you want to win over a certain type of customer segment who needs a specific feature but later that feature was superseded by some other functionality. Or maybe that customer segment is not important to you anymore.
In Enterprise SAAS, there are numerous corner cases and edge cases. Let’s say an edge case happened and you build a feature to prevent that case again. Now you have fortified your software even if that feature might never be used again.
The code still exists.
When you do the audit of your rarely used feature, consider the context of why it was built in the first place and for which persona/segment. If the use case is still valid, then you may have to continue supporting the feature. Otherwise, you can make a call to remove the feature.
Users need something in a pinch
Yesterday I broke a button on my shirt. Thankfully I had a sewing kit handy and could repair it. I believe I use the kit maybe once a year.
Likely, our software has many such features that you need in a pinch.
An example would be the ability to export data. Let’s say you want to export user data to another software to run say campaigns. It’s something you might do occasionally. Not having the export feature is costly. You will likely have to ask a tech person to do a query.
When looking at rarely used features, consider if the feature helps in the jobs of the user at any point. It might just be something needed once a year e.g. at year end. If there is a potential for operational disruption because a feature is not available, then keep it.
Enterprises are ….well, too varied
All the above reasons sound quite obvious. After all, no one expects to just remove a feature without understanding the repercussions. At least the good PMs will not do so.
However, there is another reason for the feature bloat.
Enterprises are just too varied. No two companies are alike. Even mundane jobs like closing accounting books, managing sales opportunities, forecasting are all done differently. Even within similar industries.
As a startup, we start with the core use cases in our chosen segment. And most of the what we build is then used by our early customers. Obviously, you don’t have a lot of features initially. Then you start to scale. More customers are added. They may still be within your ICP but they will likely have some nuances you need to take care of.
I was once doing an integration with Outlook 365 and encountered a large customer who had a version of Outlook that was quite old. (Outlook has over 30 variants. You can google it.) We justified that there might be other customers with similar versions so we built that integration.
And this continues as you expand and add more customers. I am not suggesting you build something custom for your every customer. But the reality is every customer has some uniqueness and you have to build a product to adapt to them. Otherwise, it is really hard to get to your revenue goal with just features that everyone will use.
That’s the nature of Enterprise SAAS. As opposed to B2C where all users are homogenous. AirBNB or Uber does not think of a set of users and build a specific feature for them. They will build for the market they are operating in. Enterprise is a bit different in that regards.
The challenge for the PM is to determine if these additional requirements are a pattern or one off. You might think this need is a pattern, but later determine this was a one off. You fall into the trap of #2 above.
How to address the bloat?
Despite the points above, most enterprise SAAS has bloat. And managing the bloat is important.
It improves the code base, reduces dependencies. You have to do less testing. It also reduce overall risk in the product.
But not everything is bloat. Don’t start with just the usage metrics and start to take action. If something is low usage, then look at the context behind it. Look at the history of the feature. Then make a judgment call.
Is this ever needed in an emergency? Is this mission critical feature when required? For how many customers?
Is there an alternative to the feature?
And if in doubt, announce to your customers that you will be sunsetting the feature in say 6 months. This gives any potential users time to reach out to you.
Bottom line, do not dismiss rarely used features. The reasons they exist in the first place might still be relevant.
