Musings from 37 Signals

I've been reading the online book Getting Real by 37 signals. It's a quick, easy read and it contains a lot of interesting lessons about product development in the new web 2.0 world. Here are some of the interesting take-aways:

1. Keep yourself as agile as possible so that you can adapt to the external environment quickly.

That means don't build too much into your product. Don't commit resources unless you must. Fail early, fail often, fail inexpensively. Failure in a startup is the only way you'll learn. You've got to keep your costs to change very low. Being small provides you an advantage over larger competitors--you are more nimble, you can change much more quickly.

"Less mass lets you change direction quickly. You can react and evolve. You can focus on the good ideas and drop the bad ones. You can listen and respond to your customers. You can integrate new technologies now instead of later."

"Nimble, agile, less-mass businesses can quickly change their entire business model, product, feature set, and marketing message. They can make mistakes and fix them quickly. They can change their priorities, product mix, and focus. And, most importantly, they can change their minds."

"Change is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead."

"What might take a big team in a huge organization weeks to change may only take a day in a small, lean organization. That advantage is priceless. Cheap and fast changes are small's secret weapon."

The book discusses the concept of emergence--"unforseen occurrence." Emergence requires the lack of complex rules.

"The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence. Keep it small. Keep it simple. Let it happen."

2. Constraints (lack of time, money, people) are good.

Constraints drive innovation ("Necessity is the mother of invention"), force you to clarify your priorities and focus on the most important things. Similarly, 37 Signals advises us to flex scope, but not time or budget. Getting something out the door--even if it's not everything that we want--is better than being perpetually in development.

3. Keep the product simple.

Every feature added has a price. Make new features prove their value before being added.

4. Use an iterative development approach.

"Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again."

"Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you'll get an active app up and running quicker since you're not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention."

"You don't need to aim for perfection on the first try if you know it's just going to be done again later anyway. Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly."

5. Hire less, hire later, and try people out before you commit to hiring them.

You would be surprised with how much you can get done with fewer people. "Whenever Jack Welch, former ceo of ge, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position."

"A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time."

Kick the tires before you commit to bringing someone on. "Work with prospective employees on a test-first basis. It's one thing to look at a portfolio, resume, code example, or previous work. It's another thing to actually work with someone. Whenever possible, take potential new team members out for a 'test drive.'"