As a software engineer, you spend most of your career building things.
The ironic thing is that for the last few weeks, I've mostly been unbuilding them.
At Buffer we're sunsetting Analyze, our original analytics product, now that Insights is live inside Publish. Turning something off is its own kind of engineering, and nobody hands you a playbook for it.
The code and infrastructure are the easy part. The hard part is the customers who still log in every week.
A few things I've learned so far:
💡 Feature parity is a trap. Insights doesn't do everything Analyze did. Ads and demographics data aren't coming with it, at least now. Waiting for 100% parity would mean running two products forever. The better question is: what does each customer lose, and what's our answer for them?
✂️ Split the sunset in two. First the customer-facing part: telling our customers, redirect them and remove the product. Then the technical part: services, databases, infrastructure. Mixing the two makes both worse.
🗃️ Their data matters more than your features. Customers forgive a missing chart. They don't forgive losing two years of history. So we're moving historical data before the switch and building a way to export whatever doesn't carry over.
🗑️ Deleting data can't be undone. If we stop collecting something today and decide to build that feature in 12 months, we may never get the history back. Every "we'll just turn it off" deserves a second look.
The thing is, a sunset is also on/off-boarding. You're asking someone to leave something they know for something they don't, and the new product only gets one first impression.
So I'm curious: when you've sunset a product, what made the biggest difference in moving customers over? Was it the comms, the data migration, or something else?
