Jason Fried is the president and founder of 37signals, a Web interface design and usability consultancy based in Chicago. He spearheaded the concepting, design, and development of Basecamp, 37signal's web-based project management tool for designers, freelancers, and creative services firms. He is also the coauthor of Defensive Design for the Web.
Jason and 37signals have worked on projects for Microsoft, Qwest, Monster.com, Clear Channel, Panera Bread, Shure, Meetup, Kinja, and others. Jason has presented at the AIGA Risk/Reward conference in San Francisco, Active8 in Seattle, South by Southwest in Austin, Reboot 6 in Copenhagen, HOW Design Conference in New Orleans, AIGA Exhibit A show in Minneapolis, and various universities.
tompeters.com asks ...
Jason, I found a little bio of you that said, "Jason Fried is the fastest white man you'll ever meet. He has curly hair and a sunny disposition. He loves to travel, play hoops, and watch sunsets from his roof deck. He wishes he could break dance." Is that all true?
JF: That was an old bio that someone wrote for me. I guess it's probably all true, except for the break dancing part. I really don't have any desire to do that.
That's what I thought. Maybe you're not so interested in the break dance thing anymore.
JF: Well, I wasn't ever really interested in doing it. I went with some people to this break dance battle one time. It was fascinating, so I wouldn't stop talking about it. So people thought that I was into that, but I really just thought it was fun to watch.
I met you at the Blog Business Summit in Seattle, Washington. You were hawking your Basecamp project management software, which I am using subsequently with my team here at tompeters.com.
But let's take a step back. What is 37signals, and why does it exist?
JF: We started out in 1999 as a web design firm. We did a lot of work for a variety of clients, and we needed to manage our projects better. We were just using email and post-it notes and throwing stuff together all over the place.
While we were sort of organized, it didn't look very good to our clients. We searched for a web-based project management tool and couldn't find anything we liked. So we decided to build our own. We started showing it to other people, and they liked it, and they said, "Hey, I could use this." So we turned it into a product, and now we're a lot less of a web design firm than we used to be. Only about 10 percent of our time is dedicated to client work, and 90 percent is dedicated to building Basecamp and other products.
So we started as a web design firm and transitioned into a product development firm.
And what's the origin of the name of your company, 37signals?
JF: One of the original partners in the company, who is no longer with us, was watching Nova on PBS, and there was some talk about the SETI Project. Search For Extraterrestrial Intelligence—the movie Contact is about this. Back in '99, Carlos—that was our partner's name—was watching the show and they were talking about how they've analyzed billions of signals from space. Radio waves, space sounds, just whatever is out there.
Out of the billions of signals they've analyzed, 37 signals were unexplained and considered as potential signs of intelligent life. Carlos and I both thought that was kind of cool, so we just went with it. It doesn't mean anything as far as web design or product development goes. It was distinctive and unique, and the domain was available. We were launching ourselves as a different kind of company at a time when everyone was named Viant or Science or Lucent or something with -iant or -ent at the end of their names. We wanted to go out there completely differently and do something new.
Now did you think that putting a number at the beginning of your name would automatically pop you to the top of any alphabetical list?
JF: We hadn't thought about that actually. We weren't concerned too much about lists. But it does work that way. Although sometimes it's in the T's, because people don't know what to do with numbers so they spell it out.
You have a particular kind of design—I know now you've segued away from being a design company—but even in the midst of creating your own products, I get the sense you have a definite kind of design philosophy. Can you talk about that a bit?
JF: We're pretty well known for our focus on simplicity. Some people would say minimalism, but I don't really like that word. To a lot of people it means emptiness and just white space. And that's not what we're all about.
Simplicity is also something that's a little bit tough to define. In some people's minds, simple means just less, and sometimes less is better, and sometimes it isn't. So we like to say that our design is all about clarity—using just enough words to explain something, just enough design to make something look nice, but no more. We want to let the message and the content shine, and let the design fade to the background. Because it's not really about the design so much as it's about the message and the content.
So we try to understand exactly what it is that the application we're designing or the website we're designing, or the company we're designing for, needs to communicate. Then we make sure that all the design supports a clear message about what that particular thing is, and we don't go any further. We don't put a lot of ornamentation on things—it's very modernist if you're looking at it the way you look at architecture. It's not about ornament; it's about structure and making the key points shine and getting rid of everything else.
What about your work process? It seems I've read somewhere that you're not big into a lot of planning or pre-designing. Is that right?
JF: That's true. We're not much into planning or writing a lot of things down that are concrete. My personal opinion is that every decision you make should be temporary. So when you start writing things down, you start putting signatures to things, and you start being locked into your past actions. You're letting your past determine the future. So I prefer to just start designing and see where things go. Then you can make adjustments and tweaks, realizing that every decision you make and everything you do can be changed if you come up with something better. I think that's the best way to design things.
It also lets you make decisions when you have the right information to make them. The traditional design process might include a lot of documentation of functional specifications, or lots of charts and diagrams, and a bunch of stuff that you compile before you begin designing. In reality, you can plan all you want, but by the time you start actually designing something, and using it in the real world, you start seeing patterns and things you never could've guessed before. If you're locked into a plan, then you can't change those things.
Do you let your clients know this?
JF: Yes. We don't really do much work for clients any more, and we kind of stumbled onto this method in the past couple of years. We used to do it the old way, which included a lot of up-front planning, functional specifications, flowcharts, and such. We realized that we were doing those things for process sake, not really for end benefit. We did all this work and then once we started designing, it didn't have anything to do with what we'd planned originally.
So we started working on our own stuff without planning for it, and then we started doing some client projects without doing much planning. And it's a leap of faith. You have to find the right clients who are willing to let you experiment in that way. In the end they certainly appreciate it, when their product turns out to be better.
37signals has written a book called Defensive Design for the Web: How to improve error messages, help forms, and other crisis points. What is this book about?
JF: The book is about a concept we coined a few years ago called "contingency design." We've since renamed it "defensive design" because that's easier to say. More memorable.
And it's got the alliteration.
JF: Exactly. Defensive design and contingency design are basically design for when things go wrong. If people have the idea that everything is going to go right on the web, all the time, they're mistaken. It's a myth. What happens is that people think things are going to work all the time, so they forget about designing for when things don't work. Like when there's an error message or when someone misspells a search term and can't find what they're looking for. Or there's a broken link or page not found error, or someone doesn't have a plug-in, or whatever. You know, how do you deal with these situations when things don't go right?
So this book is about designing for the bad side of things. First of all, we want to help people prevent bad things from happening. And secondly, we want to help them understand that bad things are going to happen and that there are better ways to deal with it when they do. Instead of saying, "No results found," you might suggest the reasons why, or alternate searches, or different spellings of the search term, and things like that. It's about helping people get back on track when something goes wrong instead of giving them dead ends like, "This page is missing" or some cryptic error message.
Being a design firm, or maybe at that time more of a design firm, you might've just written a general book about design. Why did you select this? On the one hand, it seems a very narrow area, but this is where people lose business at their website. You get to one of these wonky forms and it doesn't work and you don't spend ten minutes writing a letter to the company saying, "Oh, this isn't working." You just storm off to some other site. But what led you there?
JF: We've always looked at things differently from other people as far as design. For instance, we launched our initial site in 1999—you can find it now at 37signals.com/manifesto. That site is all text. There are no graphics anywhere. It's 37 things we think are important regarding design, how to do business, and whatnot.
If you remember back in 1999, everyone's site was all flashy with lots of colors, and so big that it took forever to load. We've always had a completely different approach to what's important online and how to present yourself. There are a lot of Web design books out there, and we're just not interested so much in the traditional visual definition of design. We're more interested in helping people get things done.
This is something we all run into all the time, but we want to shove it under the carpet because we just don't want to think about it. "Wow, something can go wrong. I don't want to worry about that stuff."
It was like the dark side no one wanted to talk about, even though it's extremely important. So we decided to write a book about it to give people a different perspective on what design can be and another way to think about their sites.
There are really two sides to your site. There's the side where everything is going right and the side where things are going wrong. The side where things are going wrong is really important, because when things go wrong, that's when people start to abandon your site.
I remember working with a designer once and we got as far as having a little fun with the 404 error page. That was the extent of it.
JF: The thing is that we're really big into realizing that there are people on the other end. We're all using computers to do things, but there are still people on the other end. It's really inhumane to treat people with such disrespect when something goes wrong that they get a cryptic error message that sounds like a computer is talking to them. Or when someone makes a spelling error and you just say, "Nothing was found," and leave them hanging. That's just not a good way to treat people. So this is a book to get people to think about what it's like for their customers. It asks the question, "Would you like to treat your customers that way? Because you are treating them that way, and you don't even realize it."
So back to Basecamp. Now you've got a web-based project management software, and you're going to a lot of conferences hustling that. So what's happening with 37signals? Is Basecamp really successful?
JF: Well, if we think of Basecamp as a client, it's our biggest client. It's definitely driving us in the direction we want to go. It's profitable for us, so we're really able to spend time and resources on it. It's allowing us to say no to client work. That's not meant to be cocky; we just need to focus on our products. If Basecamp were not doing well for us, we'd have to do more client work to pay the bills. That would mean that we wouldn't be able to spend as much time on Basecamp, which would in turn mean it would probably never be profitable because it would just be a side project.
So its success has really given us the opportunity to focus on it and to build other projects. We've built a product called Ta-da List, which lets you make simple to do lists. The to do list functionality in Basecamp has been so popular that we decided to turn it into a free little product, to get people using simple to do lists. Then maybe they'll upgrade to Basecamp down the road.
I was wondering about Ta-da—but shouldn't it be Ta-da!
JF: It can be. Basically we pulled out a little piece of Basecamp that people love and are giving it away for free. In some ways it's a marketing vehicle—an ad that people can use really. And even if they never upgrade to Basecamp, we're totally fine with that. If they just want to use Ta-da, that's fine. They're still using something that they think is useful and that we enjoy building, and hopefully they'll get some good value out of it.
That leads us to our next product, which is called Backpack.
Yes, exactly, you've got a couple of tantalizing little posts at your blog—what's your blog address?
JF: It's 37signals.com/svn. As in signal vs. noise.
There's something about this new product called Backpack. Can you tell me about that now?
JF: Okay. Backpack is a product that fits neatly between Ta-da and Basecamp. Frankly, it's a little hard to explain—we're working on figuring out the best way to explain it right now. It's a project management tool for the little projects where Basecamp would be overkill. You might use it, for example, if you're taking the family on a trip to the West Coast and you need a place to keep track of your hotel and airline confirmation numbers, the five restaurants your friends told you to check out, and maybe information about what you want to do while you're there or people to call while you're there.
You need to put that stuff somewhere. Certainly you can put it on paper, but if you live a more digital lifestyle, you want to have something on the web so you can get to it from anywhere. So Backpack is a little tool that lets you make pages that can have to-do items, notes, files, pictures, and just freeform text. It's almost like putting a whole Basecamp project on one page, but the page is whatever you want to call it.
So you could call a page "Trip To California With The Family." Or it can be "News Stories I'm Interested In." Or it could be something like "What Are My Competitors Doing?" where you keep a list of things your competitors are doing and stories that have been written about them. It's just a place to put stuff and manage what we're calling "life's little projects." Like a bathroom renovation or any project where you need to keep track of a few things—maybe some prices, some ideas for fixtures you want, some color ideas—whatever. You need a place to put that stuff, and that's what Backpack is all about.
So there again it's web-based, accessible from any computer anywhere.
So you don't have to take the laptop if you're going with the family to the Grand Canyon.
JF: You put it up there and you can get to it from any computer.
It reminds me of something I found recently called Circus Ponies Notebook. Are you familiar with that?
JF: No, I'm not.
It's basically a digital notebook. In fact, you can even make it look like lined paper, complete with three holes along the sides so it looks like it would tear away. It's an odd mix of digital and old paper visual. You can even make it look like graph paper. You can drop links in; I think you can even drop video into it. But it's sort of a catchall for anything. I downloaded it and started using it, and now I have it open almost all the time on my desktop. Because I find some link or you're just surfing around and you drop it in there. So it sounds similar to what you're doing.
JF: There are lots of tools out there that do things like this. Our philosophy is that we build really basic, simple products. We give people just enough to solve their own problems their own way. Products like the one you're talking about, and a lot of others, are really specific. There are all these slots for different types of content and all these specific things you can do. Backpack is really a very general tool. You just make a page and add stuff to it in any way you want.
The real beauty of it is that it's web-based first of all. With the product you're talking about, you have to have it on your computer. The other thing that's nice is that with Backpack you can share pages with other people. Let's say you and I are working on a business together and we want to brainstorm some business names. I can make a page called "Business Name Ideas," and I can share that page with you. Since it's on the web you can get to it, and I can get to it, and we can collaborate. Unlike other tools where something is stuck on your desktop and it's yours and only yours, Backpack is a tool where you can share things with other people as well.
I've heard you say that anyone you would want working with your company—in addition to whatever they have in technological expertise—also has to be a good writer. Why is that? I'm not misquoting you, am I?
JF: No, you're spot on there. In today's business world, most communication is done through writing, whether it's via email or via instant messenger, or if you use Basecamp or Backpack or whatever. You have to write things down, because instant messaging and email are so easy and fast. I think it's really important—especially these days—that people should be able to express themselves through writing.
If they can't quite formulate sentences or explain things clearly in writing, it's going to be a problem. Because communication is really the key to everything here. You need to be able to be clear about what you mean and what your intentions are. If someone can't write, that's going to be a problem down the road, especially for teams that are geographically spread out. Our team includes people in Chicago, New York, Provo, and Copenhagen. It would be very expensive to make a lot of long distance calls or calls over the ocean. So writing is very important; that's how we communicate almost 90 percent of the time.
Even if we're in the same office, I'll often instant message Ryan instead of going over and talking to him, just because it's faster and easier. Of course, if we need to talk then we'll talk, but you are writing most of the time. That's why I think it's important that people can communicate through writing.
Another thing I noticed at your site was called 37express, where you do a one-page redesign. Has anyone taken you up on that offer?
JF: Oh, yes, lots of people. It's become really popular. People just want less risk and more reward in general. The 37express project is a result of my looking at the web design and client industry and seeing what's wrong with it. The thing that's really wrong is that clients don't trust design firms, and design firms don't trust clients. People are always afraid that something's going to cost more than they thought, and it's going to take longer than they said it would take.
So we decided to be really, really specific. We'll redesign one page for you; it will take one week; and it will cost you 2500 bucks. It's very low risk, relatively low cost, and you get it in a week. If you like it, maybe you'll hire us to do some other pages. If you don't like it, you're out 2500 bucks and you still have an idea and you have it in a week and there's not too much that's lost. So it's become really popular—a lot of people are using it just to get one more idea.
Let's say they hired a firm to redesign their site, or they're doing it internally, and they just want one more take on it. What else could it look like? What would a fresh set of eyes do with this? They know it's not going to take three months; it's going to take a week. So they take us up on that and we do it for them in a week, and we deliver it, and that's that. It's been very popular.
In fact, that's the kind of client work we prefer, because it's short and it's quick. Long-term client projects are very draining. By the time they're over, no one is quite happy with them, and it's just not the kind of work we want to do. So we think that there's a big business in these quick, one-off, fast design projects that help people out.
Do you find in some way it stretches your thinking/design muscles in a different way? I mean you're giving yourself this pretty intense deadline on a regular basis. Is that a good exercise for you?
JF: It's very helpful for us because it takes us out of our element a bit. It only gives us a week to think about and design something. So it's a really nice creative challenge for us. A health care company, for instance, says, "Hey, we need a new homepage." And then we do it for them in a week. Or a TV network says, "Hey, we want help with our search results page." And then we have a week to do that.
It also gives us some freedom because there's no client feedback after the project begins. We talk with the client up front and figure out what's wrong with their page, what's right with their page, what are the three things that are important. After that, we just do it and deliver it. So we can be as creative as we want to be and really develop the best solution and put it out there for them. Then it's up to them if they like it or not.
It's good because we get to do a lot of different things. If you're doing one client project for six months, you're just focused on that one solution for six months. Theoretically we could probably do—I don't know what the math would be—40 express projects in six months and have a lot of different creative outlets.
So what's on the horizon? Are you adding functionality to Basecamp or fine-tuning it? Is there something else lurking after that?
JF: We're always tweaking Basecamp and working on new features. A lot of people ask us, "What's your road map?" They ask what features are coming up and where we see it in six months. The answer is that we don't have a road map and we don't know what's coming up. We're very much believers in practicing what we preach, which is an iterative approach where priorities change all the time. So one week it might be time tracking, and then we might change directions and work on something else.
We call it listening to your product. Not just to the customers, but you have to listen to your product. What is the product missing, or what does it have too much of? Part of development for us is not only adding new things, it's potentially taking some things away that aren't working well. Or slimming things down. We're not in a race to have more features than anybody else.
In fact, if anything, we want to compete with fewer features. If people want to race, and race, and race on who has more features, let them go for it. We don't want to run in that race. We want to be in the race for what's really useful and how can we get things done quickly. We're really about improving what we have and adding things when we need to more so than just piling on new stuff.
So we basically look about 30-60 days out, and that's about it. We're certainly committed to building the product, but we don't know where it's going to go. Two years ago we had no idea we'd be building Basecamp. If we had a five-year plan, we wouldn't have built Basecamp because it wouldn't have been in the plan. So, we'll see where it goes.
What's interesting about it is that people have been using it for a lot of different things. Professors are using it to manage their classrooms. Students are using it to write research papers and collaborate with other people on papers. People are using it to manage their weddings or home improvement projects. Because it's so general and so simple, it's found a lot of different industries that we never would've anticipated. So we're listening to those as well and seeing what we can do about that.
Will you put out a book at some point about all the different things you can do with Basecamp? Would you ever do that?
JF: We've had a couple of offers to write a book about how we built the product. We actually have a full eight-hour workshop on this called "The Building of Basecamp." It's all about how we came up with the idea, put the team together, designed it, engineered it, launched it, marketed it, etc.
We've done five of them so far and all of them have sold out. We get about 50 people at each one. Since the workshop is only available to 40-50 people per session and it's $500 to attend, a lot of people want to go, but they can't make it or it's too expensive. So they say, "We'd love to buy a book with your ideas from the workshop." A few publishers have asked us to do that and we're considering it. Books, as you know, are really time consuming, and right now it would pull us away from what we're really focused on, which is building products.
Maybe later this year when we have a little bit more time we'll consider putting this stuff down in book form.
You were also talking about perhaps making a video. Would you do that?
JF: We've been thinking about videotaping one of our workshops, and making that available for people who can't make it to the workshop.
So videotape the whole thing and sell it as an eight-hour video?
JF: We could do that. Or probably edit it down to three or four hours. I think eight hours is a lot of video to watch. Someone with editing skills could put together sort of a documentary-style presentation based on the workshop.
Who is coming to that workshop? What are they hoping to get from that? Do they then want to go back to their own places to develop some software?
JF: We get a mix of people. We get business people, designers who work for big companies, entrepreneurs who are thinking about launching their own services. A lot of different people show up, because we talk about a lot of different things. I think that's what really is great about it; it's not just about design or engineering or business. To me, at least, those things don't matter so much on their own. I think what's important is how you can make them all work together.
You can be a great designer, but if you don't have any idea how to build something, or market something, then it doesn't matter. And vice versa. So, a lot of different people show up from big companies and small companies. At our workshop in Seattle, people from Microsoft and Amazon showed up, but we also had owners of small companies with just one or two people who want to build a product. They wanted to gain some insight from how we did it.
Our whole thing is about making big things happen with small teams. You don't need all these layers of red tape and bureaucracy and formal process to get things done. In fact, being smaller has its advantages, and we talk a lot about that. In some ways it's an inspirational talk, and in other ways it's a very practical, real talk about how we did it and how you can apply some of these principles to your own process.
It's tricky. It's tough. Some people can't do it, and other people can.
Well, Jason, I want to thank you for your time. This has been fun.
JF: Yes, I enjoyed it, too.
Book: Defensive Design for the Web