Learn from Churn #3 - Feature Request Data vs Feature Fitment

Okay, I'm back with my 3rd volume of Learn From Churn stories - all from the trenches of my last SaaS startup.

In my last post, I discussed how Ticketing vs Product Usage data predicted possible customer churn. You can read it here.

So, let's see the next mystery: The Case of Feature Requests and Fitment

This was a largish customer with an ACV of around $60,000. They were using our system well and all parameters looked healthy. There were some issues here and there but overall no red flags. And then, unexpectedly they called our customer success person and mentioned that they were frustrated with our features.

This was astonishing. They had logged a few pending feature requests with us - but it was nothing out of the ordinary. There were other customers who had far more pending feature requests who had no issues and were happy.

Sample the data set below:

None of the feature requests were of critical nature. And we had communicated to them when we will deliver them and both of the customers were ok with the delivery timelines.

Our customer success team interviewed the customer and found the underlying sentiment that became the key to resolving the issue. The unhappy customer reported that they “thought that our product did not seem to fit their feature requirements that well”. The keyword of importance here was “seem to fit”.

After a little digging, we found the answer.

Here is a quick comparison of the 2 customers. See if you can spot the customer issue?

As you can see, from the Churn Threatening Customer’s perspective we were only delivering 9 out of a total of 12 features (9 already using +3 new features requested) they wanted to have in the product. That is a feature fitment of 75%. Compared to that the happy customer was getting 88% of what they wanted from the system.

The lesson was clear. It is not enough to just look at the number of feature requests, their resolution state, and their SLA met KPIs.

It was important to see which customer has a higher feature fitment gap.

A customer who has most of what features they want already provided by the system would tend to be happier. A customer who has less of what features they want to be provided by the system would tend to be unhappier.

So, we added one more customer health KPI of feature fitment of a customer. The product management and the product development team started looking at this KPI and it resulted in identifying customers who had less feature fitment and prioritized their features to retain them better and deliver a better customer experience. We also learned which customers were better off to churn as their feature fitment looked hopeless. That triggered a whole other ICP (Ideal Customer Profile) discussion that I will discuss sometime later.

Learn From Churn: Lesson 3

In my next post, I will be giving an example of a churn threat where the customer’s product usage data showed us something vitally important. Stay tuned.