ETech: Lessons Learned While Building Basecamp
Jason Fried of 37 Signals gave a distilled presentation of the day-long Building of Basecamp seminar that I attended in Novemeber in San Francisco.
There were four themes that he came back to throughout his presentation:
1. Reduce mass. Reduce overhead, reduce your team size, reduce code, reduce features. The more mass, the more difficult it is to change directions.
2. Embrace constraints. Don't try to remove them; embracing them forces you to look for creative solutions to turn constraints into positives.
3. Get real fast. Specs, charts, boxes and arrows all impede getting real quickly. Anything that's abstracted from the user interface slows development because people are agreeing on things that are not real.
4. Manage debt. Whether it's financial load, bad code, or bad design, eventually you'll have to pay the debt. Managing debt becomes increasingly difficult as the project gets older.
He had some good stuff to say on other topics, too:
Finding People
Finding the right people is absolutely the most important thing you can do, especially in small teams. They must be positive, as morale is incredibly important when building products in a small team. Well-roundedness is key; don't just hire a programmer or a designer. Dude must be a quick learner; getting shit done is of the utmost importance. They must be trustworthy in the sense that you can trust them to solve a problem well, and solve it by when it needs to be solved (as an aside, when I got to the stage in my career where I had to delegate, I can't say enough about those who could be relied upon to deliver when required, without my having to hold their hands through solving the problem.) Finally, and most interestingly, Fried said that he looks for people who are good writers. This is because the primary means of business communications is email, with IM and, presumably in Fried's case, Basecamp, also playing important roles in project planning and implementation.
Build Less Software
With less software, there is a lower cost to change software; there is less room for error, and it's easier to manage the opportunities for things to go wrong; less support is required, which is good, because software is expensive and time consuming; and it encourages human solutions--give people enough to solve their own problems and then get out of their way. Don't try to over-engineer a product to account for all possible uses; make it flexible enough so that your users can make it do what they want.
Build half a product, not a half-ass product.
Say 'no' to feature requests by default; listen to the product; ignore details early on--they will take care of themselves down the road; improve what you have--there's always time for new feature development, so make your product great first; decisions are temporary--make them just-in-time when you have the right information, and they can be changed if your team, product, and process is lean enough.
Transparency
When you make a mistake, tell your customers, tell them what you're doing to fix it, and make sure you fix it. Your customers will understand, and it builds trust.
There was a whole bunch more good stuff in the seminar that I didn't put up here. If you haven't attended a full Building of Basecamp seminar, I suggest you do so. It's well worth the money.
Technorati tags: etech
Subscribe by email
