The secret sauce

37 signals arguably wields the most influence over web developers and designers of any other company. And they’re only five people. They began as a small web development shop in 1999 focused on simple usability and clarity of messaging. I was first introduced to them in 2002 by a colleague and immediately “got it” when I read their original manifesto for how they approached design & development. Their blog Signal vs. Noise is one of the most commented blogs on the web. Their BaseCamp, Campfire, Highrise, Writeboard, BackPack and Tada List products are wildly popular. Their lead programmer, David Heinemeier Hansson innovated using an obscure language at the time and then abstracted what he had done and donated it to the community igniting a programmer revolution with his release of the Ruby on Rails framework. And their book Getting Real which is now freely available online proved that an eBook summarizing their philosophy would sell in spite of the ease of acquiring a pirated copy. These guys have amassed an enormous reservoire of loyalty from fans and customers. So how have they done it all?

The French writer Antoine de Saint-Exupery said “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” This thinking is the core of the 37signals philosophy. While Microsoft is busy trying to cram another feature and button into their already-cluttered interface, 37signals is working to eliminate features figuring out how to strip the application down to the barest possible form that makes it most useful and straight forward. From an excerpt of their Getting Real Book: “The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made.”

Another internal tool turned product

37s followed the path of Blogger, Hotmail and Bloglines in that BaseCamp emerged as a product after having evolved as an internal tool for solving their own problem of project management. They carved out one third of their time from client work and devoted it to refining and abstracting the application they used themselves in-house to collaborate on projects and then sold it as a subscription-based service to other developers. “It was just a flow of the application coming together and the feedback we started to get from people we respected saying, ‘I want this too!’ We thought, ‘This is something that it would be selfish to keep to ourselves.”

The value of embracing constraints

Hansson says, “We only had a quarter of a programmer dedicated to the development and no funds really for doing this… The whole constrained development model really focused our view on what we needed, and it forced us to make tough decisions about making less software all the time… It wasn’t necessarily that we were great programmers and designers, but because we embraced the constraints that forced that upon us.” This sentiment resonates through many of the stories: the scarcity of resources focuses a startup to run lean and make their offering potent with only the necessary features. Conversely, when massive teams and dollars are thrown at a problem, it produces a bloated solution that is burdened by feature creep and the confused identity of trying to be everything to everyone.

The birth of Ruby on Rails

The Rails framework was an abstraction layer Hansson created ontop of the Ruby programming language to make his own life easier. Like Basecamp, it evolved under extreme resource-constraints and therefore represented pure productivity. “I built Rails on top of Ruby to allow me to build Basecamp and drive this project in the way that we wanted to. Because we didn’t want to bring on more programmers. We wanted to keep those constraints that we had and so we just had to make tools that allowed us to do that. And I think that’s also a big explanation for why Rails is having the success that it is: it was born in an environment that was so focused on productivity and was so focused on being able to deliver within constraints. I’m building Rails while I’m building Basecamp- rather, I’m building Basecamp, and every step fo the way, I’m extracting Rails.”

We have a special place in our hearts for Hansson - our entire JumpBox platform is based on the Rails framework and has allowed our tiny team of five people to develop something that would have otherwise required a massive team of programmers. The Rails mindset is at the core representative of the JumpBox philosophy of a minimalistic, “purest productivity” approach to software.

On updating frequently

“We always give a major update within 30 days after we launch a new product. Because that’s really something that reinforces people’s feelings about the project. If they buy in on day one and then they see a major new update after 2 weeks, they’re really pleased. So for us, one of the secrets about how we market the product is to make sure that launch is not the end.”

On the tug-of-war between acquiescing to the client and sticking to your guns

“It’s good to be market-driven in the sense that you should know what’s going on, but you can’t let your customers drive your product development. You need to be able to innovate on behalf of your customers, but they often don’t know what they want.” We get pulled in various directions by requests in our support forums on JumpBox but we always view the suggestions against the backdrop of our vision for bringing Open Source apps within reach of the non-technical user. I recently wrote about this notion of “how do customers express their needs when they don’t even know themselves what they want?” Our Stone Soup Seminars and ability to deliver Innovation Games ® help us to get at this very problem.

Alone time

The concept of “alone time” was something they devoted an entire chapter to in their Getting Real book. It surfaced again in Hansson’s interview. He began working for 37s while he was still living in Copenhagen, Denmark so he had a 7-hr offset in time difference which meant there was only a small window during business hours with which he could communicate with the rest of the team. This actually proved to be a blessing in disguise as it imposed yet another constraint (communication time) that forced them to become hyper-productive with the time they had. They found that by having staggered development schedules and limiting communication to brief windows (like the Viaweb guys) they were able to get much more done.

37s continues to run as a private, profitable company though they took a minority-share private equity investment last year from Jeff Bezos, CEO of Amazon. Though it’s not entirely apparent why they took this investment, they no doubt have a plan and we can expect to see more great things to come from this tiny powerhouse startup.

This entry was posted by Sean Tierney on Wednesday, May 23rd, 2007 at 2:00 pm and is filed under Blog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.