Basecamp just turned 8 years old. Here’s the launch announcement right here on this blog back on February 5, 2004. That’s a long time ago.
We’ve learned a ton since then. One of the most interesting lessons has been the increasing degree to which time influences change.
When we first launched Basecamp, we could iterate rapidly. We were incredibly prolific those first few months. We launched a bunch of new stuff and made rapid improvement every few weeks. Eventually it plateaued and slowed down.
Why is that? Part of it is because many of the improvements we wanted to make have been made. Part of it is that we want to keep Basecamp focused on just a few things. Part of it is that the code base gets more and more tangled over time which makes change more difficult. Part of it is that we’ve also been working on other things.
But that’s nothing new. Those concerns have been part of software development since the start.
What’s new with SaaS (Software as a Service) products like Basecamp is that legacy doesn’t just build up in the code base, it builds up in customer expectations. People get used to the way things are. Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work.
In the traditional software world, new releases were bundled up into distinct versions. And it was up to the customer if they wanted to upgrade or not. If they didn’t like the opinions of the new version, they could stick with the old, familiar version. If the new version didn’t solve any new problems they had, they could keep using the version they already had.
Not so with SaaS. When updates are deployed, they’re deployed instantly for everyone. That’s not always the case – sometimes you phase in a release – but for the most part the end game is the same: This is new and it’s making its way into the product. This means customers often don’t get the chance to opt out of changes in the SaaS world.
All of this is managable for companies and customers as long as the changes are incremental and somewhat predictable. And the younger customer base the easier it is to manage. But every once in a while a company has brand new opinions about a problem they’ve already solved before.
What then? Do you totally change the existing product to fit the new opinions? What about all the customers who are used to the way things currently work? They’re going to be upset. They’re going to feel forced and bullied into something brand new they didn’t ask for and can’t ignore. No one wants to feel like that. It’s often a recipe for a lot of turbulence.
This is why change gets really hard as a SaaS product matures. Existing customer expectations are some of the strongest forces pushing back at a company with new ideas.
This is the situation we found ourselves in with Basecamp last year. We had all new ideas about how to manage, organize, collaborate, and run projects. While some of the fundamental tools were the same, the application of these tools, the way in which they interacted, and the entire execution was different. Making the current Basecamp work the way we wanted the new Basecamp to work wasn’t possible without completely forcing huge change on people who didn’t ask for it. That wouldn’t fly.
I think there’s only one fair way to introduce significant change like this: Let people choose change. I don’t think people are afraid of change, as a concept. They’re afraid of change that’s forced upon them. That isn’t change, it’s violence. And violence is never customer friendly. Just about every time I’ve seen a big transition go wrong in this business it’s been because customers were forced to change, not offered the option to change.
This is why we decided to do the right thing. Design, develop, and launch an entirely new version of Basecamp along side the existing version of Basecamp. The new Basecamp is entirely opt-in. You can even use both at the same time, if you’d like. But if you prefer not to change, you won’t be forced to change. If the current Basecamp works well for you, you can continue to use the current Basecamp for as long as you’d like.
We’ve put in an extra months worth of work to make sure the optional transition is as smooth as possible. We’re excited to share Basecamp Next with everyone soon.