Basecamp has this really unique policy for their software called Until the End of the Internet. It reads, in part:
The day you become a Basecamp customer you can trust that Basecamp will be around. In the event that the Basecamp product you’re using enters a legacy phase you’ll be free to keep using it as-is indefinitely, assuming you continue to abide by our terms of service and keep your subscription active.
Co-Founder David Heinemeier Hansson wrote a post about this policy several years back, before they made it official, where he said:
But, but, but isn’t that expensive? Isn’t that hard? What about security? What about legacy code bases? Yes, what about it? Taking care of customers — even if they’re not interested in upgrading on our schedule — is what we do here. Cost of business, as they say.
They also published a piece How to launch software changes without pissing people off.
I’ve been thinking about this a lot recently. It seems like one of the primary ways to enrage customers is to force something new and different on them without letting them continue to use the old version. Or, to just simply shut something down, like Google did with Google Reader. There’s no way that the ill-will that still persists towards Google for shutting down Reader was worth the cost savings. Google in particular has earned the reputation for pulling the plug on things that people rely on, and it absolutely makes people think twice before relying on Google.
If I was starting a software business tomorrow, I’d absolutely trust Azure over Google Cloud Platform, in part because Microsoft has proven themselves over decades to support legacy products. The fear is always that Google will pull the plug on something critical and leave you scrambling. In fact, when they shut down their Shopping API, they killed a nice little profitable business that we had with SportsLizard. Thankfully, that wasn’t our primary source of revenue at the time.
On a personal level, one of the software updates that angered me the most was a Pocket Casts update roughly a year ago. One day the UI completely changed and my playlists were gone. Thinking I must have missed something, I took to Twitter, only to find a thread explaining that they had removed playlists in the new version. I exported my feeds, uninstalled the app, and reinstalled my favorite podcast app Antenna Pod (which I had only moved away from due to a few bugs that had since been fixed).
We’ve made this mistake too. When we launched our responsive redesign of Detailed Image in 2013 we made the mistake of removing the left nav too soon. We removed it at the 1024 break point, thinking that most users at that width would be on an iPad. It turns out that we still had a reasonable number of users on old 1024 x 768 monitors (remember this was 2013!), and we heard from them almost immediately. We restored the nav within days, and improved the touch nav shortly thereafter. People weren’t upset that we refreshed our design, they were upset that we took away a feature that they relied on. It was a good lesson learned.
A few months ago I finally had a chance to put this lesson into practice. Our internal admin, where we do everything from process orders to create newsletters, manage products, and view reports, had never had a UI redesign since its inception in 2008. Navigation was cumbersome, and screen space was wasted for those of us using large screen monitors. I sat down with Mike and we came up with a list of needed improvements. The temptation was to just do them all as quickly as possible and release the update to our team. However, we know that all thirteen of us use it slightly differently, and that all of us relied on it daily to get their work done.
Rather than risk disrupting someone’s work flow, we decided to build a theme system. We support both the original theme and the new theme, with the default being the original. When we launched, I sent out an email to everyone highlighting all of the improved features in the new theme, but also reiterating that switching was optional and that we’ll continue to support the old theme as well. Everyone ended up switching, but some people took a week or two. They did it on their own time when they were ready.
It’s disappointing that Basecamp is so unique. If supporting old software were a standard practice, software would be much more enjoyable and we’d have a little more trust in the companies we work with.
- How Twitter, WordPress, and Google Contacts Influenced Notify My Team’s UI
- PageSpeed vs reCAPTCHA and YouTube: Will Google Ever Get on the Same Page?
- PHP Localbox – an easy way to test email on WampServer or XAMPP
- Our Warehouse Package Cutoff System Wasn’t Designed For This, But It Is Saving Us Right Now