“Getting Real” by 37 Signals: Review
“Getting Real” by 37 Signals is a very specific read, for a very specific audience, but it does a tremendous job outlining a different approach to web application development. That approach revolves around getting something ‘real’ out, usable, and able to gain traction. This is the strongest point that is made repeatedly, very similar to a Seth Godin read which constantly reiterates the same point, over and over again, until it’s become clear.
Getting Real’s initial mission is to aide anyone involved with the deployment/development of a web application to successfully get it used. It does so by beginning with having you, the owner of the application, define it’s purpose, it’s audience, and goes through all the different life cycles of the application. These include the design process, hiring, marketing, pricing, customer feedback, and more.
While each of these sections could be very well documented and discussed, what comes through the most in Getting Real would have to be it’s optimism of a minimalist approach to web development and design. This stretches from the initial feature sets, all the way through to the number of people required to launch it, and how they market/advertise this launch. Less is more in the eyes of Getting Real, and they do an exceptional job explaining why this is.
Drawing from a professional history that includes Basecamp, the Ruby on Rails framework, Highrise, Writeboard, Campfire and more, Getting Real is able to back up their claims that less features is most of the time better than the competitor with more features, through real world examples of their success and their history.
Being a user of Highrise, a lean CRM web service, it is very clear from the onset that 37 Signals, the company behind all these services, believes firmly and practices stricltly the process of less is more. Highrise has a very limited feature set compared to other CRM systems, however the fact that it is so lean is what makes it so easy to get in, and begin working. The learning curve varies from none to very little, and it’s flexibility in a few areas (eg. tagging) make it as flexible as the user/business needs.
My contribution to this discussion is something that’s taken me a very long time to understand, and something that a lot of other people could easily disregard as a cop-out: if you are developing something that has competition (everything does), figure out the reason you want to compete, that 1 specific reason, and do that and nothing else.
So for example, back in the day I created a couple networks/sites/app’s that allowed someone to post a vacation property they owned, and I would do the SEO/SEM for them (they would pay me a yearly fee to post on my site) which would then send them inquiries. A really simple directory service. Now there were many out there, and while often a reason for creating a product or service will be to make money (which I thought about too, obviously), my reason for competing was because I hated the design. vrbo.com is one such competitor, and their site is 10 times better than it used to, but still looks horrible. It’s functional, but in my eyes, was horrible and I wanted something better.
But rather than spend 95% of my time on that one thing, the aesthetics of the service, I tried to mimic all the functionality vrbo.com had, AND improve the aesthetics. Like most businesses, it failed. I made some money, but very trivial compared to the market and in no way sustainable. But over the past little while, it’s become clearer to me that if I’m trying to compete in a specific realm, that realm should be 95% of the focus. It sounds easy and obvious, but for someone starting their own business, it’s so easy to want to do everything better. You tell yourself ‘well if i do everything better than my competitors, than the custom will have to pick me’. But all this does is lead to a lot of wasted time.
Getting Real is a great read for anyone who develops sites/applications. It will fairly radically change the way you look at feature sets, deadlines, team oriented development, and more than anything, priorities for your sites/applications.