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.
Josh Pigford
on 07 Feb 12Very true that users end up wanting to “protect” even the things that are broken, only because change is scary.
But what about the long term (in Internet time…a couple of years)? Will you guys keep maintaining two separate code bases? Or will Basecamp Next be the only thing that gets love?
Just seems like a lot of overhead to maintain two separate apps on this scale.
Michael
on 07 Feb 12Well said. This does make me wonder if someone would invent a standard, manageable way to ‘version’ SaaS. Perhaps it’s happening now with BN the way so many SaaS innovations from Basecamp became standard.
Jace Richardson
on 07 Feb 12I agree, it’s a slippery slope of versioned web software. This seems like how conversations around regular software got versioned. Let’s hope “Basecamp” original doesn’t become the IE6 of the web.
TVD
on 07 Feb 12From Jason Fried:
Revolutionary.
That must’ve been a gut wrenching decision. I can just imagine the passion on both sides of the aisle. So many questions must’ve ran through each Signal. How long will we support both versions? What if no one ever completely transitions? What does this mean in support costs?
It takes courage to run both Basecamp and Basecamp Next side-by-side. In the end, it will be the principle of the matter:
One could wish for no simpler a message.
Matt Radel
on 07 Feb 12It’ll be realllly interesting to see how this plays out. I’d love to know more about exactly what tipped the scales to develop an entirely new product, and what will tip them again.
Tadas
on 07 Feb 12I think you guys are becoming softer :) Lots of times users don’t know what’s best for them and their opinions are closed in the cage of awareness about current features/processes only. Let people decide whether to upgrade or not and you’ll have IE 6,7,8… Don’t loose the momentum of incremental changes and you’ll have… Google Chrome?
James
on 07 Feb 12Looking ahead, I think 37signals will eventually retire basecamp, it may be 2-4 years in, but when that time comes, they’ll be able to say 95% of our users changed, and over time, as we launched the new product and improved it, we were able to make sure all the functionality required to move was gradually introduced (in a better way). Then when it’s a minority they’ll cut it off for that last 5%. In the process they’ll have let people make the call (the vast majority) and hedged bets against a bad launch of their next product (if it’s missing key features or new features flop). I think this will work out great long term, though it will be costly for 37 signals initially in terms of hardware and programming time. I’m betting they think of it as a longterm investment, which feels very Apple-y to me. Can’t wait to see it!
SY
on 07 Feb 12@37signals
Why do you feel like you’re different than everyone else?
Facebook, which is also 8 years old, just like Basecamp, makes significant UI/UX changes monthly and still does to this date – without users yelling/complaining.
Facebook doesn’t have a problem making significant user interface changes, adding major new features, etc … so why do you?
JF
on 07 Feb 12SY: For one, our customers pay us. Big difference. Forcing change on people who use your product for free is not the same as forcing change on people who pay you every month for something they depend on for their business every day.
David Andersen
on 07 Feb 12@SY -
you really think FB users don’t complain when the UI changes? They complain loudly and often. I don’t know how you miss this.
Emil
on 07 Feb 12SY: Facebook users yell and hates new changes. But that doesn’t change anything.
SY
on 07 Feb 12@David Andersen
Some users will always complain.
How did you not miss that?
MDX
on 07 Feb 12This idea is intriguing, but I’m curious how the branding for this will play out. Will I go to 37signals.com and get a chance to signup for Basecamp or Basecamp Next?
Cam Collins
on 08 Feb 12You draw some interesting distinctions between “traditional” software providers and SaaS. I own one of those traditional software companies and we are migrating our customers (albeit slowly) to the cloud. In preparing them for this migration, we’ve been encouraging our customers to upgrade to the latest version of our product.
Our software maintenance agreements are written such that we only have to “officially” support the most recent version and one version preceding the latest. From a practical perspective we will support older versions as its just the right thing to do.
This has been a multi-year effort for us, but we now have 90% of our customers are on the latest version of our software. So we believe (hope) that the transition to SaaS will be a relatively smooth one because a majority of our base will be on a common version.
Would love to hear comments/opinions from readers who have been through a similar transition from server-based to SaaS.
jayasimhan
on 08 Feb 12Glad to see 37Signals follow this principle. I have been having a similar thought for sometime.
Curious to know: Do you keep both the versions on a common application stack or are they completely separated?
Line Atallah
on 08 Feb 12We rely on Basecamp for all our projects, and recently we started feeling that it was very “unflexible” for us, so we started looking for new solution. The news of the Basecamp Next thrilled us. We are wondering though how long till the launch? Is it a matter of weeks? months? year?
JF
on 08 Feb 12@jayasimhan Completely separate.
Jimmy Chan
on 08 Feb 12Why don’t you follow if it ain’t broke, don’t fix it?
Separate two completely different code-base should cost you more.
Eric Tarn
on 08 Feb 12Such a simple and great idea. I think if companies who acquired other companies did this, there would be less resentment, cancellations, and negativity from the “forced violence.” For example, Rackspace’s current process to switch all Slicehost users to Rackspace cloud. I’m sure Rackspace cloud is great, but forcing me to switch just sucks. See also Assistly/Salesforce.
On a semi-related note, Foursquare’s API allows you to pass in the exact date you wrote your code so they can try to provide the same API offered on that date so you aren’t forced to work with newly deprecated stuff. Google also lets you pick the “old version” for a while…
[email protected]
on 08 Feb 12Wrong. Wrong and wrong. People love change.
Change is considered as forced only when it decreases the value of the product (migrating an as400 application to the web only because the web is trendy and without adding new fonctionality) or when the perception of value is lower than reality (Facebook launching the newsfeed).
In both cases the source of the issue is not the user but the company.
Jonatan Littke
on 08 Feb 12I think change is natural to us but it has to be employed efficiently. In the larger system in which we exist (the world), change is constant but transitional. It’s step by step by step.
I think software development should be the same.
Pedro Colaco
on 08 Feb 12I think this is a radical departure from SaaS and forking into two separate releases may indicate a more traditional software development methodology. Once you cross this line, what will preclude you from changing things around a bit for a large customer? At the end of the day, this indicates that the SaaS model (and therefore development cost structure) is much closer to traditional software than we expected.
I must say that we at GuestCentric have made the decision not to go this route, and to offer the exact same interface to all users even if it forces them to change behaviors. We believe this is the way to drive innovation. Let’s see how long we can stick to it :-)
Damien
on 08 Feb 12I disagree. Look at applications like facebook, which has been changing parts of it’s interface every six months. And is now implementing the timeline feature, which changes, again, a lot for users.
And their users are complaining every time yes. But they adapt and they just keep using the application, like they did before (or a bit differently).
Don’t consider your users as idiots, they can adapt to change.
Merle
on 08 Feb 12Is Basecamp Next just the mother of all kludges?
DHH
on 08 Feb 12Merle, hu? Next is a green-field code base. The best written software we’ve ever created. Basecamp Classic is an 8-year old code base that is still nice in the larger picture of legacy software, but is still 8 years old with lots of embedded decisions that we no longer love.
Josh, we’ll continue to make Classic run great, but no, it won’t have the focus for new feature development. That focus will belong with Next. Also, if Basecamp Next is so successful that 95% of Classic users jump ship, then Classic will be cheap to run for the last 5% and not a problem. We still run Tada list, even though we haven’t added features to it in years.
Adam Wride
on 08 Feb 12Could the future of SaaS be that everyone hosts their own apps and data? Make it easy for me to load it up on my own Amazon EC2 instance and make it easy for me to upgrade to new versions as they are made available.
Then I own my data and can stay on version 1.0 for as long as I like.
Damien
on 08 Feb 12@Adam : that’s not called SaaS anymore then.
Adam Wride
on 08 Feb 12@Damien
Sure – not as we understand it now. But it could be simplified to such a degree (for the user) that the user wouldn’t see a difference.
Merle
on 08 Feb 12You’re right DHH, that was harsh. Sorry. Still, I’d like to see some painless migration ability. In my view that’s essential… and an interesting problem to solve.
Bartley Doyle
on 09 Feb 12I think this a great approach. Businesses have moved to SaaS usually for bottom line reasons, but unless seismic change in new functionality is managed with focus the SaaS user base will be eroded by diminishing adoption. In your approach the customer can choose between the options just like when they chose to move to the Saas model in the first place. It’ll be important to communciate with the same passion how this new functionality will help them improve their business. You’ve really listened to your customers!
Adam Wride
on 09 Feb 12They don’t say it outright, but it looks like Atlassian’s cloud offering of JIRA is just a bunch of virtual machines, each running a different customer’s copy: http://blog.newrelic.com/2012/02/08/atlassian-selects-new-relic-java/
TC
on 09 Feb 12Boil the frog slowly. Do not throw it into boiling water!
We the forward-thinking companies with all our ideas want to be moving forward, while our customers just want their solution to do the job, which it may well already be doing.
We, the companies, have pride in our product and are aware of how our competition is advancing and want to make sure we are too. We want to continue to have pride in our market and not be envious of our competition. At the same time, we want to stay relevant in our market.
Our customers like what they are using, except what they tell us they don’t like. Our customers are not telling us they don’t like the look of the buttons or the graphic details. We’re telling ourselves that. They are not telling us they’d like quick-edit or a new file manager or slicker interface. We’re telling ourselves that. They are not asking for the latest usability paradigm. We’re thinking we need it.
Part of this is to stay relevant among the candidate customers who, looking around, have some inkling of what is more modern among software and what is less modern. In a new purchase decision, they may opt for what is more modern feeling thinking it is better, and that may not be our less-modern, but “more comfortable to our existing customer base” software.
How do we stay marketable to potential customers and stay usable with little upset to existing customers? For us, we call it “baby steps”. Even when we’re ready to tear the whole thing down, where we can, take baby steps instead.
Slow boil.
TC
on 09 Feb 12Yes, FB users do complain, but you know what, we get used to the change also. You know why? We’re human. We adapt, though uncomfortably sometimes.
This discussion is closed.