David Heinemeier Hansson helped transform 37signals from a consulting company to a product company in early 2004. He wrote the company's first product, Basecamp, an online project management tool. He also wrote companion products Backpack, Ta-da List, and Campfire. In July 2004, he released the layer of software that underlies these applications as an open source web development framework. Ruby on Rails has since become one of the most popular tools among web developers and won Heinemeier Hansson the Hacker of the Year award at OSCON in 2005. In July 2006 (after this interview), 37signals president Jason Fried announced on the company's blog that Jeff Bezos had made a minority private equity investment. Livingston: 37signals wasn't begun as a startup, correct? Heinemeier Hansson: 37signals was founded by Jason Fried as a web design shop in 1999. It transitioned from a consulting company to a product company with the creation of Basecamp. I'm part of the 37signals 2.0 management team. Livingston: So the launch of Basecamp was a pivotal turning point for the company? Heinemeier Hansson: It was not an overnight transition. While we were developing Basecamp, 37signals had a lot of client work, so we couldn't dedicate more than about a third of our time to it. It wasn't a client project; it was something that we created as an internal tool to help us manage our client work. Livingston: Take me back to the time of the Basecamp launch and the transition. 309 David Heinemeier Hansson Partner, 37signals 23 CHAPTER Heinemeier Hansson: I was working with 37signals as a contractor while I was finishing my bachelor's degree. They did the design and I did the programming. After a few years, it became clear that they needed a tool to manage the client project process. One person wouldn't know what the other was doing. It was pretty disorganized and starting to look unprofessional. The idea came to us that blogging had been a pretty good way of distributing information between people. I had been blogging personally on Loud Thinking and 37signals had Signal vs. Noise. So we wondered, what would happen if you took that blogging idea and applied it to project management? That was how we got started: the project blog was the first part of Basecamp that was made. We got it up in about a month and then we started using it to manage Basecamp itself. So it became self-contained very quickly in the sense that we were using Basecamp to build Basecamp. As we showed it to colleagues in the industry, we quickly realized that others had the same problem; there was not a lot of software available for small companies to manage projects. Microsoft Project and the other heavyweight approaches to this relied on critical path management and things that might work fine for a 200-person project on a construction site, but not well for 3 people trying to deliver a web application. So we started out just thinking, "This is going to help us solve our consultancy needs." And as we got more feedback, we realized it was a good time to start thinking about how we could make this 37signals's product. Livingston: Do you remember the moment? Heinemeier Hansson: It was more 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." Livingston: What were the features that people liked most when they saw it? Heinemeier Hansson: The funny thing is that most people were impressed by all the stuff Basecamp didn't do. They were used to these big, honking products that tried to do everything, where they just needed something simple. We had this dilemma that either you had MS Project or you had email, and there's a huge gap between them. Managing a project by sending emails back and forth is messy and doesn't work, but otherwise you had to adapt your process to what's mandated from these other heavyweight applications. Basecamp was basically just trying to be one step above email. And by setting such a humble goal, we had to make a lot of decisions about how simple we could make things. We tried to make less software from the very beginning. It's one of the mantras we have. It's a win whenever we can get away with just a simple model, since we have to do less programming. I was the only programmer and I was dedicating 10 hours a week to this, while we were developing it. 37signals was paying me to do this out of its consultancy revenue, since we didn't have funds to fund it. So we had only a quarter of a programmer dedicated to the development and no funds really for doing this. The designers 310 Founders at Work were giving it a third of their time at most. And we realized through this process that those constraints--which sound negative--were actually the greatest gift to the development of Basecamp. That 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. And we keep getting feedback from customers that say, "I love this, it's just so simple to use. It's got just the features I need and not all the other stuff." There wasn't time for us to say, "Wouldn't it be cool to do this and that?" It turns out that when you build only software that you absolutely need, you don't get more software than you'll actually use. And that's why we didn't fear competition from the big guys. If Microsoft decided to go after Basecamp, they'd say, "Get a team of 20 people to do this and we'll give them 6 months to come up with something." Because when you're in a big corporate environment, you throw a lot of resources at projects. You just could never arrive at the type of product that Basecamp is when you don't work under constraints like we did. It's just too tempting to try to do it all, or at least do too much. It wasn't necessarily that we were great programmers and designers, but because we embraced the constraints that forced that upon us. If we took the same people and put them in an environment where we had all the money and time we wanted, we couldn't even make Basecamp again. Livingston: Did you worry about any competitive products? Heinemeier Hansson: There have been a few businesses that have tried to do similar things, but most of them try to do the full management of projects: billing, time tracking, and other things that we've never tried to solve. We picked a few simple things: a project weblog, milestones tracking, file and to-do list sharing. And we haven't really expanded beyond that; we've just tried to refine those few simple elements. The funny thing is that another reason Basecamp is a success is because it's not more focused. We started out wanting to make a tool for creative services businesses, like us. But we never actually wound up including things that were specific to creative services, like billing, time tracking, etc. So people use Basecamp for all kinds of projects, like managing weddings, home improvement projects, and student collaboration. The only reason that we're attracting all those people who just need help with project management is because we're not trying to be more specific. And that's why I think that if we had had more money and time to add features specific to creative services businesses, we would have shut off our entire market to all these other people who are using Basecamp for types of projects that we didn't even imagine. Livingston: So you built this new project and didn't have a marketing budget. What happened next? Heinemeier Hansson: We didn't spend a dollar on advertising when it launched. Though Basecamp is a monthly service, you don't need to pay David Heinemeier Hansson 311 anything when you first sign up. If you just need to manage a single project, the product is free for life. So a lot of people got in just testing it out for a certain project. As soon as they realize that they'd like to use it again on another project, there's an upgrade path for them to go down. They can buy the first paid version that gives them three projects and gives them file uploading for $9 a month. So we have a shallow upgrading curve where you can go from paying nothing to paying very little. The most expensive version is only $99 a month. And because we charge on a monthly basis, customers get the advantages of low risk. People can sign up for two months, and if it's not what they want, they can cancel easily. And that's been one of the most powerful marketing tools. Also, Signal vs. Noise had a fairly large following in the web development community. The first big market for Basecamp was these creative services firms. Since they were already reading about what 37signals was doing, we went the other way around: first we built the audience and then we figured out a product. We blogged about Basecamp even before its launch, making previews, and it was viral from there. So it helped that 37signals had a big audience and had an easy way of selling into that audience. The majority of our new customers have heard about it from someone else or read something about it on the blog. They sign up for the free version and then, that's the best lead you could ever get. It doesn't cost us anything in the first place and doesn't cost us that much to keep the lead, because, though they get one project for life, we have a large group of people who are now friendly to the product we're selling because we just gave them something for free that they're actually using. And we're not yanking it away in 30 days. So this builds a lot of goodwill in the early phases of the relationship with the customer. It's a really powerful way of selling. Livingston: Did anything go wrong? Heinemeier Hansson: We made a bunch of mistakes. We got the launch pushed back by almost a month. Initially, we thought that we were going to bill people once a year, $99, $299, and $499 for the different plans. We built this entire billing system, which was a sizable amount of the development time. We didn't figure out that the bank wouldn't let us bill this way until about 3 days before we were ready to launch. The bank wouldn't let us sell a service that we were going to promise for an entire year, because they'd be on the hook for the money if we went out of business a few months into a $500 agreement. They wouldn't allow that because we didn't have a long history with them. So now we had this extensive billing system focused on billing once a year and we couldn't use it. We had to go back and make it monthly instead. But this turned out also to be a blessing. So we pushed back the launch about a month, and now we charged monthly, but we charged twice as much. The plan that was before $99 a year is now $19 a month, $224 a year instead. So we actually got to raise the prices and at the same time create a less risky offer for small companies since they didn't have to buy a whole year. 312 Founders at Work One of the technical mistakes that we made early on was that we had this notion that Basecamp was for creative services firms. Set up like that, you have a firm and you have a client, so it's a one-to-one relationship. That assumption went very deep. For instance, in the database there's a client ID and firm ID, and now that people were using it, you'd have setups where people wanted two firms. So now what did we do? Basecamp simply couldn't do that. And that assumption was so deep at the roots of the system that it took us about a year and a half to fix, which was not a good thing. Another interesting mistake was that we didn't consider time zones. Basecamp ran with the assumption for the longest time that everybody is in Central Standard Time, even though I was in Copenhagen, which is a 7-hour time difference from Chicago. So people in Australia would get their milestones one day late. We didn't really care about time, because we didn't usually have fixed deadlines. We had stuff we wanted to do, but it didn't really matter whether it was 2 hours later or 2 hours earlier. Of course, not every firm works like that. And it was also disguised by the fact that Basecamp didn't use a lot of time. The only place where we displayed the time itself was on the comments. On the posts themselves, it just said the date and the milestone. So you wouldn't be able to discover that, unless you were in that central time zone, it was off. In Denmark, for 7 hours after midnight, the system would say it was yesterday. So it was a big deal for the firms that needed specific times. And it was always a big deal to people in Australia. Half of the time they would be off by one day. We've gone back to fix that problem too. Livingston: Were you the only programmer? Heinemeier Hansson: I was until February 2005 when we brought on our second programmer. Yes, for well over a year, I was the only programmer and systems administrator on Basecamp. Livingston: In addition to all your responsibilities, you were also starting the Rails project. How did you manage it? Heinemeier Hansson: When you have to do a project like Basecamp and you only have 10 hours a week, you can't spend your time on things that don't produce anything. So you get extremely aware of tools that aren't necessarily helping your productivity and you go seeking tools that can help. That's how I found Ruby. It was such a nice experience for me and a nice productivity booster. I was coming from PHP. I had also looked at Java and other environments and I wasn't finding anything else that would allow me, as a single programmer, to deliver all this stuff. And I then 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 David Heinemeier Hansson 313 to deliver within constraints. I'm building Rails while I'm building Basecamp-- rather, I'm building Basecamp, and every step of the way, I'm extracting Rails. So I'm doing what I need to do for Basecamp, then figuring, "Hey, this looks generic, I could pull this piece out and put it into the toolbox Rails." And as time goes by, this toolbox gets larger and larger and somewhere in the process I realized that this generic toolbox that I had was actually a very useful toolbox and perhaps other people could use that too to do the same thing we were doing at 37signals, use less resources and build less software. When we launched Basecamp, it was 4,000 lines of code--so not very much. One guy who's now involved with Rails told me that they had a single configuration file in XML that was 5,000 lines! We released Basecamp in February 2005, and by then I knew that I wanted to release Rails. We went through the hectic time after releasing Basecamp where we would keep on pushing a whole bunch of new features. 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. We don't say, "Whew, we're done now," and then go on vacation. It's then when you keep on pushing to show this product is alive. So that happened in February and then we had pretty much a finished framework for Rails, but I didn't want to release it yet, because I wanted to document it. I'd been using open source software for so long that I was really annoyed that a lot of it had terrible documentation. I didn't want that to happen to Rails, so I kept it back about 2 months, and then pushed it out about 3 or 4 months after Basecamp. Livingston: Was there ever a time when you felt you couldn't do all this? Heinemeier Hansson: Sometimes, but whenever we had those feelings we viewed them as clues that we were trying to do too much, so we'd think, "How could we make this feature require less engineering and programming?" And we got into a pretty good mode that, whenever we wanted to do something new, we would brainstorm some ideas and try to look for the idea that required the least amount of work. And I had this same thing in the development of Rails. When you try to do 100 percent of what somebody wants, you need a perfect match, and it's pretty rare that you have a perfect match between what you thought people needed and what they actually need. If you just try instead to do 80 percent of what they need, there's a pretty good chance that you'll hit a sweet spot. So Rails is really about trying to get that 80 percent all the time and not really caring about those last 20 percent that are really specific to the situation that you're in. When Rails launched, it was just 1,000 lines of code. So even though we've done all these things, there's no superhuman strength involved. We aren't producing more lines of software than everybody else; we're just making each line count for so much more. 314 Founders at Work Livingston: So, much of your innovation was driven by your own needs, rather than your clients' requests? Heinemeier Hansson: Very much so. 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. And it's the same thing for programmers. If you went around and asked them what they wanted in a framework, you wouldn't get a good product out of that. You need to be able to source input from a lot of sources, and then have your vision of what it's going to be and then drive that. You need to drive both framework development and product development with a strong vision, where you're not afraid to turn somebody off. We're not afraid to say to a customer, "Maybe Basecamp is not for you. If you want those five things, maybe you should go look for something else." Livingston: Now that you have received a lot of publicity, have you been wooed by investors? Heinemeier Hansson: Yeah. We've gotten quite a lot of VC calls. But one of the things we're seeing that we really don't care too much for is that way too many companies are taking money when they don't need it. And the whole idea we had was that having too little money is a great way of getting great product, because it's a way to get focused. So we have definitely said to ourselves, "We don't want any outside money. We actually don't even want to grow our team." We're trying to design our products in a way that they can scale with more users without us having to scale as a company. So, through Signal vs. Noise, we're trying to deliver a pushback to companies that feel like they have to hire a bunch of people as early as possible and to take money to realize their vision by saying, "If your vision of your product costs a million bucks to make, try rescoping that idea in your head so it fits in $100K and get it out there earlier. Instead of having a 1-year product cycle, what could you do in 1 month?" And sure, that doesn't work for every company, but in the web age, it works for way more companies than are trying to. Livingston: Might you ever get acquired? Heinemeier Hansson: We're not that focused on that at all, but we're not ignorant to the world that we're living in. There's no urgency though, because we're a profitable company just doing what we do. If somebody comes tomorrow and offers us $100 million, I'd be pretty foolish to say, "No, never." Livingston: What's been the most surprising thing? Heinemeier Hansson: I think I'm fairly surprised that we've been able to stay true to our initial values. Since we launched Basecamp, we've added only one more person, even though the product has grown like crazy. I'm definitely surprised that we've been able to grow and not write a whole lot of software, and still make a difference. David Heinemeier Hansson 315 Livingston: Was it challenging having several of the 37signals team in different places? Heinemeier Hansson: We view it as advantageous actually, because the 7-hour time difference leads to "alone" time. In a company where everyone is in the same place, it's very easy to walk down the hall and interrupt somebody. If you're part of a distributed team that's 7 hours off, you're bound to have a good portion of the day where you just get work done. There are no interruptions. Another thing is that we communicate mainly through IM, which is a fairly low-bandwidth way of communicating, so you're not going to disrupt somebody unless you're going to say something that matters. If you meet in person, it's very easy to just talk for 30 minutes, and what was the information exchange actually about?