San Diego (click to enlarge)

I wrote about Basecamp a few days ago. Jason Fried, president of 37Signal, the company behind Basecamp is talking about the lessons he learned building it. Brian would like to get Jason out to Utah to give one of these.

The right people. Its not about their skills beyond the basics. It's about finding people who are positive, well rounded, quick learners, trustworthy, and good writers. Well rounded, in this context means that they aren't just an architect, or a DBA. "I'll take someone who is happy and average over a guru who is frustrated and discontented."

Embrace constraints. Look at the problems and come up with creative solutions. Don't sweep them under the rug. Constraints are where creative solutions happen. Here are some of the constraints Basecamp faced: Prior commitments, 7-hour time-zone difference, lack of proximity, self-funding, and small teams.

They put the constraint of building less software upon themselves because it leads to a lower cost of change, less room for error, and requires less support. Further, it encourages human solutions. "Give people just enough to solve their own problems their own way--and then get out of their way." Look for usage patterns and then add features you need.

Build half a product, not a half-assed product. Some principles:

• Say no by default
• Listen to the product
• Ignore details early on
• Improve what you have before you add new features
• Decisions are temporary

If you can't make any change you need to on your product, your competitors will do it and leave you behind.

Get real and start with the API. Build something for the customer to use as soon as possible. Start with the user experience. There's nothing functional about a functional specifications document. They are merely an illusion of agreement. Let the design drive the experience:

• Start designing
• Start prototyping
• Start experiencing
• Start changing
• Rinse and repeat

Make decisions just in time. Example: don't overbuild for scalability. Increase hardware and system software as necessary. Make decisions when you have the real information.

Feel the hurt. Don't outsource the customer support too early. You need to know what annoys people. Builders should support the product.

Add feature food to grab PR. iCal support brings Macheads, RSS gets buzz from the blogosphere. He references the yellow fade technique as something that got a lot of buzz.

Plan on a 30-day major upgrade. Hold back on the initial release and 30-days later push a major upgrade to show users you care.

Manage debt. This refers not just money, but commitments to other people and companies. Also, hacking bad code, doing something that's not correct or pure is another example of debt. Its OK to do this from time to time, but be sure to pay it off.