Over the past 8 years, millions of people across every imaginable industry have used Basecamp to manage over 8 million projects. In total, they’ve shared over 275 million to-dos, messages, and files.

What started as a side project in 2004 has become the world’s most popular web-based project management and collaboration app. 96% of our customers say they’d recommend Basecamp to a friend, colleague, or co-worker.

The Basecamp business is booming.

But too much good news is a formula for complacency. And honestly, we have grown a bit complacent.

That’s about to end.

We’ve gone back to the basics and made them better, faster, clearer, easier, and smarter.

In early 2012, 37signals will introduce Basecamp Next and change the way people collaborate all over again.

We’ll initially be launching by invite only. If you’d like a chance at an invite, visit the teaser page, scroll down, and enter your email address at the bottom.

Over the next few weeks we’ll be revealing more details about Basecamp Next. Stay tuned.

Last Call for Entries
December is the final month for the Basecamp Tell a Friend Contest. We still have 4 brand-new 32GB iPads and a MacBook Air to give away. The grand prize of $5,000 USD will be awarded at the end of the month!

How to enter
Entering is easy, all you need is your 37signals ID information (what you use to log into Basecamp). You’ll get a special code to send to friends. We’ll keep track of your referrals. You’ll have a chance to win some great prizes. Get started in seconds.

Winners around the world
We’ve been surprised by the winners so far. They’ve stretched across the globe from places in the US and Canada all the way to Australia and Ukraine. It’s truly amazing how far Basecamp has come—all through word-of-mouth!

Nick Quaranto joins 37signals as our eighth programmer today after impressing everyone during his trial month. Nick is not only a manager of one, but also eager to leave everything better than he found it. That’s a valuable instinct when you’re working with applications old enough to talk back!

Nick’s work on creating the modern-day rubygems.org was certainly no minus either. I’m constantly amazed at how easy it now is to create, distribute, and update Ruby libraries and frameworks through the gem system. It almost feels like cheating after living through a former era of zip files, rubyforge, and other more manual approaches.

So we welcome Nick to our small troupe of programmers and hope he’ll stay long. He’ll be in great company. Sam Stephenson just celebrated his sixth birthday with 37signals today. Jamis Buck has been here for close to seven years. Jeremy Kemper for almost five years. As a company, we’re in this for the next twenty years and beyond, so it’s wonderful to have a crew to grow old together with.

We’re working on something new over here. We’re stuck on the design for a certain screen. Over many months we’ve probably been through a dozen concepts with dozens of minor tweaks to those concepts.

In all this work, and all the usage, and all the trials, and all the tweaks, I’ve spotted a pattern. Things that look good at the end of the day often don’t look good the next morning.

The end of the day has a way of convincing you what you’ve done is good. The next morning has a way of telling the you truth.

And that’s fine. Design is a process of experimentation and elimination. You should be excited to have your mind changed and throw things away.

This isn’t news, of course. “Sleep on it” has been great advice since forever. But it’s been a good reminder that the next morning isn’t just a block on the calendar, it’s a great design tool in itself. Use it to your advantage.

Much of the tension in product development and interface design comes from trying to balance the obvious, the easy, and the possible. Figuring out which things go in which bucket is critical to fully understanding how to make something useful.

Shouldn’t everything be obvious? Unless you’re making a product that just does one thing – like a paperclip, for example – everything won’t be obvious. You have to make tough calls about what needs to be obvious, what should be easy, and what should be possible. The more things something (a product, a feature, a screen, etc) does, the more calls you have to make.

This isn’t the same as prioritizing things. High, medium, low priority doesn’t tell you enough about the problem. “What needs to be obvious?” is a better question to ask than “What’s high priority?” Further, priority doesn’t tell you anything about cost. And the first thing to internalize is that everything has a cost.

Making something obvious has a cost. You can’t make everything obvious because you have limited resources. I’m not talking money—although that may be part of it too. I’m primarily talking screen real estate, attention span, comprehension, etc.

Making something obvious is expensive because it often means you have to make a whole bunch of other things less obvious. Obvious dominates and only one thing can truly dominate at a time. It may be worth it to make that one thing completely obvious, but it’s still expensive.

Obvious is all about always. The thing(s) people do all the time, the always stuff, should be obvious. The core, the epicenter, the essence of the product should be obvious.

Beyond obvious, you’ll find easy. The things that should be easy are the things that people do frequently, but not always. It all depends on your product, and your customer, but when you build a product you should know the difference between the things people do all the time and the things they do often. This can be hard, and will often lead to the most internal debates, but it’s important to think deeply about the difference between always and often so you get this right.

And finally are the things that are possible. These are things people do sometimes. Rarely, even. So they don’t need to be front and center, but they need to be possible.

Possible is usually the trickiest category because the realistic list of things that should be possible will often be significantly longer than the list of things that should be obvious or easy. That means that some things on the possible list might be better off off the list completely. Instead of making them possible, maybe not making them at all is the right call.

Coming to know the difference between obvious, easy, and possible takes a lot of practice, deep thinking, critical analysis, and, often, debate. It’s a constant learning process. It helps you figure out what really matters.

But once you’re able to see the buckets clearly, and you begin to think about things in terms of obvious, easy, and possible instead of high, medium, and low priority, you’re on your way to building better products.

If I hear one more Silicon Valley type gush over a computer science graduate from CMU, MIT, or Stanford, I’m going to puke. Yes, yes, I’m sure these are mighty dandy nice schools, but you’re letting the stench of superiority and shallow whiff of superficial judgement pollute my airways.

The fantastic thing about programmers is that we don’t have to give a fuck about where they were trained because we have something much better available: We can look at what they actually do! We don’t need the indirection of pedigree to guess at their skills, we can look at their code and know it.

Here’s a list of the top tier schools that helped shape the fine band of programmers we employ at 37signals:

• Lawrence University
• Rochester Institute of Technology
• Brock University
• Washtenaw Community College
• California Institute of Technology
• Copenhagen Business School
• Brigham Young University