The 37 Signals Way

I remember 37 signals vaguely as the company that the Ruby on Rails guy works for and they seem to generate quite a buzz from time to time with bloggers, for reasons that I have never cared to investigate. That is until I listened to a podcast - "Lessons learned while building BaseCamp" by Jason Fried, the founder of 37 signals recorded at the O'Reilly emerging technology conference earlier this year. What blew me away was the refreshing approach to software development these guys have and how cogently it was articulated. While Jason Fried himself admits inspiration from Agile programming, I think it deserves attention on it's own merits, and for being able to set out a bunch of actionable items. Putting a new spin something that many people might know or might be obvious to others is not without merits, there is always value in re-packaging good 'old' ideas.

The semi-transcription/notes from the talk:

The talk revolves around four main themes :

1. Reducing Mass
2. Embrace Constraints
3. Getting Real
4. Managing Debt

Reducing Mass
Mass could be people, high overheads, long term contracts etc. It's difficult to change with more mass, and being able to change is extremely important for any product development process. Find the right people -we look for people with certain level of skills. But, beyond a certain point it is not about skills alone, it's not about how many years experience you have with PhotoShop, it's not about bullet points. You need to work with people that are positive most of the time. In a small team of four one disgruntled person can bring down the whole team. Morale is incredibly important when building a product.You have to have people who are excited about what they are doing and are positive about what they are doing. Jason advocates hiring people who are well rounded, and can do multiple things. Don't hire someone who is just a programmer, or an information architect, or a designer, or a marketing person, especially on small teams. Hire people who can learn quickly new things (like AJAX) and apply it quickly.Hire Trustworthy people - trustworthy does not mean people who lock the doors at nights and remember to turn off the lights. It's very important that you don't have to cleanup after that person. The person you want to hire has to be a good writer - A programmer, or a designer, or a marketing person all have to be good writers, because of how people communicate with each other to each other these days - they don't talk that much to each other these days, they IM/email each other all the time. You have to find people who can communicate by writing. Jason's bottom line for hiring people - I will take someone who is happy and average, rather than someone who is a Guru, who is the best in the business, but is disgruntled and frustrated. Such people will bring down the team in the long run.

Constraints
Once you have put in the team in place, you have put in the constraints. Most companies instead of embracing constraints start thinking, we don't have enough money - let's raise more money, we don't have enough people - let's hire more people, and so on. Don't do that! Look at your problems and come up with creative solutions. Embrace those problems, and don't push them under the rug. Some of the constraints that 37 signals had to deal with when building BaseCamp:-

Prior commitments: 37 signals was still a web design shop and initially BaseCamp was about 20% of the time spent. David Hanson the only programmer on the project was still in school and was committed to some of his own free lance work as well. We didn't put everything down and say 'let's focus on BaseCamp'. We made sure that the time spent on base camp is valuable time. The time difference between Chicago and Copenhagen (where Mr.Ruby on Rails lives) is seven hours -On paper it looks like disaster - we decided it was a good thing, you communicate mostly through IM and email. When you talk through IM, you have to be really specific. You chunk things into small pieces and you move on. We are self-funded. Spending money should be the hardest thing that you ever do. Make sure that every penny that you spend is a hard penny to spend. That will ensure that you end up making much better decisions and you spend money in better places. And finally having a small team - we had a team of three people, one programmer, and two designers. People in smaller teams have more power, you can't hide behind twenty other people.Everyone has to do something. It ensures that everyone cares about the product. These were constraints that were put upon us and there are ones that you can put on yourself. Building less software - that's the constraint that we decided to impose on ourselves. It's not about building feature-by-feature, but less features intentionally. When you have less software, you lower the cost of change.

Managing the opportunity for things to go wrong is the key thing. Less support is required. Technical support will kick your ass - It will destroy you. We don't advocate hiring a bunch of people to do technical support. You want to build something that is manageable. Outsourcing tech support is a bad thing. Finally, you also want to encourage human solutions. Less software, less features means less rigidity which means that people have to come up with their own way of dealing with the product. We all hate the paper clip guy in the corner - you should give people enough to solve their problems in their own way and then get out of the way.Ta-da list is an example - a really simple to-do manager.You look at the patterns in the users behavior and maybe there is an opportunity there to improve the product based on how people use it, based on real product use, not fake paper mock-ups etc. Look for usage patterns in a real environment and add a feature if it turns out to be necessary or if people ask for it. It's always better to start with less than more. The idea of building less software leads to the next idea - how do you do releases - You release half-a-product, not a half-assed product. There should be no scope creep, only scope reduction.Everyone is doing a beta these days and that's ridiculous, Everything is a work in progress and continue to improve it , have confidence in your product.

How to do scope reduction
Say No, by default, to all new features. You want to listen to the people who are using it. Your customer base will tell when you need to add something. If you get ten requests, then it's a "maybe", if you get twenty then it is stronger (demand), thirty requests - then probably it is something you need to add. Listen to your product, and listen to your customers. Say No by default, see where the gaps are, observe the usage patterns before deciding to add a feature. You will build a better product based on real data.
You want to ignore details early on - you can spend a week on something that doesn't really matter. A lot of small things that you think matter don't really matter. Take care of the big picture first. Fill in the details close to the release. If you have time before the release make existing stuff better instead of adding new features. The idea that every minute should be spent on a new feature is a bad idea. Focus on what you have - make it rock solid, make it bullet proof, make it great. There is always room to add stuff later.

All decisions are temporary. You should be able to change all decisions that you make, in theory - realistically you should be able to change almost all. You can change decisions if you have less mass. You want to make decisions that you can change, every decision should be temporary. You should should take decisions just in time - You should make decisions when you have real information to take a decision.

Make mistakes in the open, admit it to customers and fix it quickly. Jason admits that this is not applicable to every kind of project. It applies to web based software, especially the UI portion. Make small changes, iterate often.

Getting Real
We don't do functional specs, we don't do diagrams, we don't spend a lot of time doing use cases, we don't spend a lot of time doing things the customer will never see or never use. We want to be in front of the customer experience close to 100% of the time.If it takes four months to make a product I want to spend 3.9 months in front of the actual product.I don't want to slap user experience at the end. That's what happens when you are talking about these functional specification documents - functional specs are political documents.They are documents used to blame one another - it was supposed to work this way,it doesn't etc.It's also an illusion of agreement. Someone will say inevitably - "that's not what I intended".Well you signed off on it and politics starts. The design is the functional specification - programming needs to follow the user interface. When you are in front of your interface all the time, it is almost like your version 1.0 is someone else's version 2.0, because you are constantly tweaking real user experience that is not based on paper prototypes - people always have something to offer when they see the real thing. You are postponing those inputs by writing functional specs. Build simple things for all users including expert users.

Managing Debt
Manager your debt - If you have earned debt through some ugly hacks, pay it off as soon as possible by setting the code right. Don't get stuck in hardware or software that you can't change.

Making most decisions just in time
Japaneses factories that have just what they need, use new or better parts. Just in Time systems allow people to make better products. Scalability is a myth. If you are a yahoo or a google, then you really need to worry about it. If something is slow for 2 weeks, it is slow for 2 weeks. It's OK to make mistakes in public. BaseCamp was running on a single server and was being used by thousands and thousands of users, till about three months back. Then we switched to 2 boxes and we are in the process of switching to eight. If you invest too much money and effort up front setting up a cluster and you don't need that for 12 months you have wasted an awful lot of money and you could have spent the time on something more valuable. Admin interfaces are another - don't spend time on writing stuff that will generate extensive reports and what not. Actual customer experience first. BaseCamp is free for 30 days. We couldn't bill anyone in the beginning;figured it out after a while. Make decisions when you have the real information, not before.

Feeling the Hurt
The people who build the product should do the tech support on the product for as long as possible. Jason still doing tech support and he owns the company. I want to know what's right, what's wrong. 37 Signals get only forty emails a day - simple product that is well designed. Don't want to get the same emails over and over again. Chefs have to be waiters in certain restaurants.

Publicity Amplifiers
Here are some publicity amplifiers - for getting the word out about your product. With no marketing budget,no PR budget,no money, how to get the word out ? Lace the product with feature food - features that users use and spit out small little features and people tell others about it. Small little features that users eat and spit out all over the place. In BaseCamp you can subscribe to your feature milestones via Ical. We talked to mac sites about it - this news blurb generated tons of traffic and tons of sales. Same feature is available via RSS as well - the blog world loves RSS. The Yellow Fade technique generated about 325 references on google. This small technique generated more buzz than the product itself. Hold back some features, and do it 30 days after launch. It will show that there is momentum happening. people will really love that and it shows your commitment to the product - You didn't build a product only to move on to something else.

Transparency and Trust
If you make a mistake, tell people.We made a mistake and had to be manually in front of our servers for forty hours. No data was lost and we had to re-start the server constantly. We could have hidden that;but, we posted a long explanation - lot of people trust us now.

Blogging
Blog as much as possible about your product. Google will send lot of traffic your way.

Question from the audience:
How do you work with David Hanson (who is in Denmark) ?
Jason: We use BaseCamp to do 8-10 hr iterations in order of priority - we don't worry about what will happen eight months down the road.

Looks like Ruby on Rails is not the only thing to come out a small software startup with less than half a dozen employees.