3. Saying No to Product Expansion for Focus
- Pallav Nadhani Ex-Co-Founder & CEO, FusionCharts
In this snippet, Pallav emphasizes the need for a clear framework to manage feature requests, helping focus on core product strategy.
When you’re working toward product-market fit, you’ll have many customers who will request that you build various features. You have to build a framework to say no. That is your product expansion strategy.
If you keep on building everything for everyone, you will be nothing for no one. You will build a custom services company, not a product company. Your philosophy of saying no and product expansion will help dictate the decisions to avoid becoming complex SAP-type software with 40 different tabs and subtabs.
At a high level, one way to think of these decisions is to consider the combination of your onboarding process, buying model, and the pricing tiers you sell at.
If it’s a high-touch onboarding and a high value per account, you can still service some custom requests from your large clients.
Say you’re getting accounts between $10,000 and $40,000 or even more, and you have to do high-touch onboarding remotely. The economics still work out. But if you have to travel to the US and then do it, then your number here changes to maybe $100,000.
The super sweet spot is if it’s a low-touch onboarding and high value per account. This is very rare, but with more remote onboardings after COVID-19, we are seeing this happen.
Low or no touch onboarding and high value per account are software like your midsize ERPs or Salesforce. In these cases, your account value is high for large, big teams, but you use a standard set of features, so the onboarding is heavily automated.
Low value per account, low, no touch onboarding is something like a Notion or Atlassian. That’s mainly the self-serve, product-led GTM motion.
But if you have a low value per account and high-touch onboarding, that’s a losing proposition in the long term because your cost to service per customer would be much higher compared to the revenue you bring in.
Knowing our product expansion philosophy and what to say no to was also super important for us at FusionCharts. We had 28,000 customers worldwide and a lot of free users. People would come and ask for random things. To solve this, we created an internal framework based on two pillars - the severity of the request and how many people are requesting the same feature.
Then, we set a basic criteria for ourselves. We’ll only consider a feature request if a hundred people have called for it.
The exceptions would be unless it’s going to impact more than a couple of hundred thousand dollars in revenue from existing large-ticket clients. But a broad framework, which you can use, is how many people are requesting it and what percentage of the time.
Let’s say if all of the people are requesting a feature all of the time, then you should prioritize this. These should be the things you say yes to by default.
You can easily refuse the things that very few people request or only very few times. Because these requests are so rare, they will likely be very niche and irrelevant to your product strategy.
If you think they are, you can reevaluate this. But as a quick rule, why are you building something that only a few people request very little of the time?