Sunsetted a Feature and Only Got 6 Angry Emails: Here's What I Think
I recently stumbled upon a fascinating account of a SaaS founder who decided to pull the plug on a feature utilized by a seemingly significant portion of their user base – around 8%, or 340 monthly active users. What's even more interesting is that they declared it the best decision they made all year, despite the inevitable handful of angry emails. This got me pondering the delicate dance between customer satisfaction, crippling technical debt, and the long-term viability of a SaaS business. It's a high-wire act, without a doubt.
The Compelling Case for Feature Sunsetting
At first blush, eliminating a feature that's actively used by a chunk of your customers might seem like business suicide. After all, aren't we told to obsess over user happiness and cater to their every whim? Well, yes and no. The reality is far more nuanced. Sometimes, the bravest and most strategic move you can make is to kill off a feature that's become a drain on your resources and a drag on your development velocity.
Think of it like this: you’re a chef running a popular restaurant. You have a signature dish that everyone raves about, but it requires a rare and expensive ingredient that's becoming increasingly difficult to source. The dish also takes up a significant amount of prep time, diverting your kitchen staff from other, potentially more profitable, items on the menu. At some point, you have to ask yourself: is this dish worth the hassle? Is it truly contributing to the overall success of your restaurant, or is it holding you back?
In the SaaS world, features can become like that troublesome dish. They might have been brilliant ideas at the time, but over time, they can become technical albatrosses, weighing down your development efforts and preventing you from innovating in other areas.
Technical Debt: The Silent Killer
Technical debt is the bane of every software developer's existence. It's the accumulation of quick fixes, workarounds, and poorly written code that builds up over time, making it increasingly difficult to maintain and update your software. Features built on shaky foundations can quickly turn into technical debt nightmares, requiring constant attention and consuming valuable development resources.
The founder in the story mentioned that the feature in question was built three years ago and had become a "codebase spaghetti." Every update risked breaking it, and they were spending 12+ hours per month just keeping it afloat. That's a significant amount of time and energy that could have been spent on building new features, improving existing ones, or addressing other critical issues.
The 80/20 Rule Strikes Again
The Pareto Principle, also known as the 80/20 rule, states that roughly 80% of effects come from 20% of causes. In the context of SaaS, this often means that 80% of your revenue comes from 20% of your features. While the exact numbers may vary, the underlying principle remains the same: some features are simply more valuable than others.
If a feature is only used by a small percentage of your users and is causing a disproportionate amount of problems, it might be a prime candidate for sunsetting. In the founder's case, the feature was used by only 8% of their customer base. While that might seem like a significant number, it's important to consider the cost of maintaining that feature versus the revenue it generates.
The Art of the Sunset: How to Kill a Feature Without Killing Your Business
Sunsetting a feature is not something to be taken lightly. It requires careful planning, clear communication, and a healthy dose of empathy. Here's what I think are the key steps to doing it right:
1. Announce Early and Often
Don't surprise your users with a sudden and unexpected feature removal. Give them plenty of notice – at least 60 days, as the founder in the story did. Communicate the reasons for the sunset clearly and transparently. Explain why the feature is being removed and what alternatives are available.
2. Explain the "Why"
People are generally more understanding when they know the reasons behind a decision. Be honest and upfront about the challenges of maintaining the feature, the impact on development resources, and the long-term benefits of removing it. Don't try to sugarcoat it or downplay the impact. Acknowledge that some users will be disappointed, but emphasize that the decision is being made in the best interests of the business and all its customers.
3. Offer Alternatives
Whenever possible, provide users with alternative solutions or workarounds. This could involve suggesting other features within your product, recommending third-party tools, or even offering to help them migrate their data to a different platform. The goal is to make the transition as smooth as possible and minimize the disruption to their workflow.
4. Reach Out to Heavy Users
Identify the users who are most heavily reliant on the feature and reach out to them personally. Offer them extra support and assistance during the transition. Listen to their concerns and address their questions. Show them that you value their business and are committed to helping them succeed.
5. Provide Export Tools
Allow users to export their data in a usable format so they don't lose their information. This is especially important for features that involve data storage or processing. Providing export tools demonstrates that you respect your users' data and are not trying to lock them into your platform.
6. Monitor the Impact
After the sunset, monitor the impact on your users and your business. Track customer support requests, churn rates, and feature usage. Use this data to refine your sunsetting process and improve your communication strategies for future feature removals.
What I Would Do Differently
While the founder in the story seems to have handled the feature sunset reasonably well, there are a few things I might have done differently.
More Granular Usage Data
Beyond just the number of monthly active users, I'd want to dig deeper into the usage patterns of the feature. How frequently are users accessing it? What specific tasks are they using it for? Are there any power users who are particularly reliant on it?
This information would help me to better understand the value that the feature provides to different users and to tailor my communication and support efforts accordingly.
A/B Test the Sunset Announcement
I might consider A/B testing different versions of the sunset announcement to see which one resonates best with users. This could involve varying the tone of the message, the level of detail provided, or the types of alternatives offered.
By experimenting with different approaches, I could optimize my communication strategy and minimize the negative impact of the sunset.
Offer a "Sunset Support" Package
For the heaviest users of the feature, I might offer a "sunset support" package that includes personalized training, dedicated support, and even custom development to help them migrate to a new solution. This would be a more expensive option, but it could be worth it to retain valuable customers and prevent them from churning.
The Bigger Picture: Focusing on What Matters
Ultimately, the decision to sunset a feature is a strategic one that should be based on a careful assessment of costs, benefits, and risks. It's not about being ruthless or uncaring, but about making tough choices that are necessary for the long-term health and success of your business.
By focusing on what matters most – building a sustainable business, delivering value to your customers, and innovating for the future – you can make the right decisions, even when they're difficult.
And who knows, maybe you'll even get away with only 6 angry emails.