There are thousands of pieces of work on the Basecamp cutting room floor. Here are 37 random ones from October 2011 until now.

Some of these were ideas in progress. Some of them never left the sketch phase. Some were in production for awhile before we decided to change, redesign, remove, or tweak. And others are still there.

Mig is a designer. That’s how he describes himself. We’d add “damn fine” to that description. Please welcome Mig Reyes to the 37signals crew.

He’s been making beautiful useful things at Threadless for the last few years. I’ve long admired his work, his work ethic, his interest in learning, his blossoming writing skills, and his dedication to the Chicago design scene. We’re super lucky to have him on our team.

Soon enough you’ll be seeing his creativity make its way to the surface on our sites and in our apps. We’re looking forward to seeing how he influences us.

Welcome aboard, Mig!

It’s hard to believe we didn’t have a proper calendar in Basecamp until June of 2011. Before that we had a list-based view which worked exceptionally well for nearly seven years, but people still like looking at dates and deadlines on grids. We get it! ;)

We’ve made a few calendars in our time. Backpack has a great one – it served as our exclusive company calendar up until we built this new one in Basecamp. Now we run all our schedules with the new Basecamp calendar.

We wanted to make sure the calendar for the all new Basecamp was the best one we ever made. And the best one around, period. It’s not going to launch with everything we want, but all the basics are covered real well. We put a lot of time into the interaction details so it’s fast, smooth, intuitive, and flexible. We’ll continue to improve it and refine in over the coming months, post launch.

Here’s a video peek at what it looks like and how it works. There’s more to it than this – there’s a list view inside projects, and each event has a discussion page as well – but we’ll be saving those details for a future video.

We’ve discussed, debated, decided, changed our minds, debated again, decided again, changed our minds again, and finally decided for sure just recently. Basecamp Next will actually be named Basecamp.

For marketing and communications purposes, once we launch the new Basecamp, today’s Basecamp will be referred to as Basecamp Classic and the all new Basecamp will simply be known as Basecamp.

How we got here

Originally, we didn’t really have a name in mind. We weren’t thinking about the name. The first time I presented the idea I called it BC3, but soon after that we started calling it BCX. X didn’t stand for anything other than “we don’t know what it’s going to be called, so let’s just use X”. We liked the way it sounded, too.

As we got a month or two into the design process, we started seeing it take shape. With shape, we started to toss around some names. Early on we tossed around things like Basecamp 3 (we had already called a major redesign a few years in Basecamp 2). But we didn’t like version numbers – especially since we know there wasn’t going to be feature parity between the current Basecamp and the new product we were building.

To cast a wide net, we asked the whole company what they thought the name should be. As you’d expect from a group of 25+, there were a lot of opinions.

When we started thinking about the design of the all new Basecamp, we had three key things in mind:

1. Speed
2. Big picture
3. Focus

With that in mind, and many experiments later, we came up with a unique interface that is crazy fast, excellent for big picture broad overviews, and perfectly tailored for quick focus with no distractions.

We call it page stacking and we think you’re going to love it. Here’s a brief video I just put together to show you how it works (it looks best in full screen mode, BTW).

We’re just a few weeks out from the official launch. Sign up for a chance at an early beta invite prior to launch. We’ll also use this list to announce the launch.

Back in July when we first presented the idea of Basecamp Next (called BCX internally) at our company-wide meetup in Chicago, we put together two lists: Goodbye and Hello.

Goodbye was a sample of some of the things that Next wouldn’t have that Classic did have. Hello was a sample of some of the things that Next would have that Classic didn’t have.

“Have” is a relative term. Some stuff on the Goodbye list is completely gone from Next, while other things are just executed differently enough that they don’t resemble the way things worked in Classic.

It’s interesting to look back at the two lists now and see how well our original predictions worked out. There’s some stuff on Goodbye that we ended up keeping and there’s some stuff on Hello that we didn’t do (or did completely differently than we originally anticipated). And then there’s a bunch of stuff not on either list that you’ll ultimately find in Basecamp Next.

We’re only a few short weeks away from launch, and we’re still making calls on what’s in and out and how some key features work. It’s a good reminder that lists are moments in time, they aren’t golden rules.

Anyone who builds products is familiar with the mad dash at the end of a project to add those last few features. When you’re running out of time it’s usually because you have more to add than your schedule allows.

But the more I learn about designing products, the more excited I get about the mad dash at the end to remove features.

This means killing work that’s been done and is technically ready to ship. It’s hard to do because it’s already done, but done doesn’t mean it’s right.

Killing stuff right before it ships is the sign of a healthy product and development process. It means you’re always questioning, reconsidering, and reevaluating. It never ever hurts to ask why.

What made sense two months ago may not make sense two weeks before launch. Other features may have taken its place. Newer ideas may have replaced earlier ideas. And sometimes it just takes time and use to realize that feature you built just isn’t scratching the itch you thought it would.

We’re just a few weeks out from the Basecamp Next launch. Last week we killed two features we’d already built and were initially pretty excited about. But they just weren’t right, they weren’t doing the job. And they were introducing new problems that we just didn’t feel good about.

Remember that 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. That’s why it’s so costly to let bad designs slip into products.

Just like you shouldn’t let sunk cost determine future decisions, don’t let sunk design trick you into keeping something in your product because you already put the work in. If it’s non-essential, take it out, think it over, and invest the time post launch to make it right.

“If a customer asked you why, how would you answer?” This is a question I’ve been asking a lot lately. Why could be “why does it work this way?” or “why can’t I do that?” or some variation on that theme.

I think your answer to those questions is a great way to measure your product. Are you happy with your answers? Are they fair answers? Are they clear answers? Would you be happy with the answer if you were the one asking the question?

The goal isn’t to get to “Yes” on every answer. The goal is to listen to your answer and ask yourself what it really means about how you approach product development.

If the answer is something like “well, because it was too hard for us to make it work the way it should” or “because we couldn’t figure it out” or “because we didn’t spend the time to think about the problem thoroughly enough” or “we just didn’t feel like putting in the work to make this easy for you” it may be a red flag.

Now, sometimes those are just truthful answers. Every decision involves a sacrifice. You may have had to sacrifice some thoroughness here so you could be more thorough there. But when answers like that pile up it’s worth looking yourself in the mirror and ask why you’re satisfied with answers like that.

This approach is especially helpful during product development, prior to launch, when many things are still in flux. This is the moment when you should be asking these questions repeatedly. The more you ask, the more you have to consider, and ultimately the better decisions you’ll end up making.

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.