Guest Blog Post by Krish Subramanian
Explosive user growth.
Backing from the venture capital elite.
Seemingly, never ending interest from media entities.
They’re rocketships of the startup world.
Startups like Hubspot have seen unbridled growth.
For startups that cater to the needs of other businesses, it is a dream to serve customers who’ve attained exponential growth.
For fairly obvious reasons.
Their growth could easily translate into increased usage of your product and thus higher revenues, their name in your clientele could spark massive media attention.
Though, there’s a flipside.
These startups didn’t always wield such command over growth. They started small. Many SaaS startups take a fairly long time to achieve product-market fit and some figure the formula for success through various experiments.
Now, as the high growth customer of yours transcends the growth curve, they are likely to max out the potential of your offering. If their business objectives aren’t met, they’ll abandon your service and move on.
How does one retain such customers and continue to have bragging rights of the brand?
Is there a way to meet the growing needs of very few “star customers”, while staying honest with your product roadmap to address the market?
How do you avoid being sidetracked?
The simple advice from most guys is “learn to say NO”, but that is not always ideal if you want to retain such customers. Because you will be inhibiting these fast growing startups and they will try to find a way to build things themselves, with or without you.
In the last three years, we’ve encountered this problem time and again. Have we discovered a surefire way to solve it?
Not quite yet.
But, we’ve tried a few things that have worked for us. The intention of this post is to share those tactics with you.
1. The curious case of scale
Scaling to match up the accelerating needs of your fast-growing customers can become complex, could prove to be expensive but if you intend to retain them, it’s unavoidable.
What happens when a customer wants to do thousands of transactions per minute, that you haven’t tested yet?
Here is something we did: we spun of couple of additional servers just of the customer and tested this at scale to ensure we can meet their growing needs. Once we were convinced this tactic will hold-up for sometime, we bought ourselves some time before we could identify any potential bottlenecks for horizontal scaling.
We are hosted on Amazon AWS and we could leverage this for couple of hundred dollars in additional spend, but most importantly the engineering team stayed focused on whatever features they were working on without switching to product optimization.
2. The case of the product roadmap
It’s easier to base product decisions on your “ideal” customer’s requirements, but your fast growing customer will be outpacing your roadmap timelines. This is when prioritization becomes a challenge.
Most B2B startups deal with this dynamic.
More often than not, requests from such customers will not fit with your product roadmap and your ideal user’s requirements. Owing to their growth, the frequency of such requests would be higher as well.
If a feature doesn’t add much to the ideal customer’s product experience, one way is to decline the request altogether. We did that for some time. Until, we found the following ways to tackle this issue.
If a project like reporting / business analytics can’t be taken up immediately, but your star customers need it “yesterday”, the only way to deal with it is to give them all the raw data and ask them to crunch it.
– But even better, we started doing it ourselves as a service.
We hired an accountant to sift through the financial data and crunch the required statistics in an excel spreadsheet. And it worked.
As we surveyed other customers and found out, they had always wanted something similar. To our surprise, we had stumbled upon an additional service we could monetize – a customized reporting service on top of our analytics platform.
This feature has since become a major product differentiator for us.
– Go Stealth / Build Privately
Another way of repeating this process is by actually building out the feature for these users. Yes, solely for them. You could call it a private version of a minimum viable feature.
We’ve tried to do this by building private APIs, they can be developed and delivered with pace.
When we are not exactly sure about the complete use case and how to bake it as part of mainstream product, we have taken this approach to build private APIs. They don’t need extensive documentation and versioning challenges typically associated with public APIs.
But they meet urgent needs of our users. They don’t eat up a lot of time.They don’t move us one cubit away from our product roadmap. A win-win for both of us.
Have you been in such a situation? What all tactics have worked well for you?
About the author
Krish Subramanian is the co-founder and CEO of ChargeBee, a subscription billing platform for recurring revenue businesses. You can reach out to him on twitter to discuss about SaaS, Ecommerce and all things startup.