Episode 132: Simplicity by Design for Product Development with Jason Fried, Co-founder and CEO of 37signals
Episode 132: Simplicity by Design for Product Development with Jason Fried, Co-founder and CEO of 37signals
In this episode of Product Thinking, Jason Fried, Co-founder and CEO of 37signals, joins Melissa Perri to explore the importance of simplicity in product design, saying no to customer requests, designing for profitability, and running a successful business while maintaining work-life balance.
37signals is a well-known software development firm acclaimed for its creation of Basecamp, a complete product management platform boasting over 20 million users since its debut, and HEY, an innovative email optimization tool. Jason is a distinguished member of the Edmund Hillary Fellowship that has also lent his expertise as a columnist for Inc. Magazine.
In the literary world, he co-authored "Rework," a guide illustrating a more efficient approach to business success. His bibliography further includes titles like "Remote: Office Not Required" and "Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application."
If you enjoyed this episode, make sure to subscribe, rate, and review it on Apple Podcasts, Spotify, and Google Podcasts; instructions on how to do this are here.
You’ll hear them talk about:
[01:25] - In product development, Jason's principle is clear: build for yourself first. Instead of guessing the market's desires, his team crafts products they believe in and refines based on consumer feedback. This method ensures authenticity and resonates with a broader audience since most teams, regardless of industry or size, face similar challenges. Instead of chasing niche needs, they focus on foundational solutions with the most universal appeal.
[06:50] - In building products, Jason follows the rule of "simplicity by design." Instead of asking what to include, he begins by defining what to exclude, ensuring only the essential remains. This approach isn't about minimalism but about understanding the core essence of the product. Unlike physical objects with natural constraints, a software product can become unwieldy without limits. So, Jason treats software as if it were tangible. Imagining how a feature might feel if it were a physical object helps him keep software focused and user-friendly.
[10:05] - Jason underscores the art of selective decision-making in product development. While there's no shortage of ideas from customers, market trends, or internally, the real challenge is determining which aligns with the company's broader mission. Rather than creating niche features for specific industries, he believes in crafting universal functionalities. So the company often says "no", both to external suggestions and internal proposals. Their decision-making leans more on intuition than strict metrics, influenced by the team's current projects and inclinations.
[26:02] - Jason firmly believes in operative prototypes over ones without backend functionalities. Spending weeks on a prototype only to discard it is wasteful. Instead, it's more efficient to develop something functional from the start. Jason also believes a successful business should move quickly, ensure genuine progress, and operate leanly.
[29:12] - The essence of smart business growth and design for profitability goes down to several principles. Start modestly - profit-focused design begins with small steps. Bring on staff only when truly needed to avoid unnecessary expenses, focus on efficient small teams, and avoid non-essential costs. Next, handle core functions firsthand, as Jason did with Basecamp's customer service, to better understand challenges. Using personal funds produces caution, and profitability offers the freedom to innovate without external constraints. Ultimately, like any neighborhood store, understand the fundamental importance of spending less than you earn.
Episode Resources:
Melissa Perri - 00:00:36:
Hello and welcome to the Product Thinking podcast. Today we're joined by Jason Fried, the Co-founder and CEO of 37Signals. 37signals is a Software Development Company best known for creating Basecamp, an all-in-one product management platform which has 20 million users since its exception, and hey, an Email Optimization Platform. Jason is the co-author of the book Rework, which provides a better, faster, easier way to succeed in business and remote, office not required. Jason has co-written several other books and is a regular speaker on 37signals podcast, Rework. He's also a fellow at the Edmund Hillary Fellowship, and it's a community of 500 plus innovators, Entrepreneurs, and Investors committed to New Zealand as a Basecamp for Global Impact. So welcome, Jason.
Jason Fried - 00:01:24:
Thanks for having me.
Melissa Perri - 00:01:25:
So you have been doing 37signals now for over 23 years, I believe, which is a very long time.
Jason Fried - 00:01:34:
Yeah, we started in 1999. So it's been a while, a couple of decades. Yeah.
Melissa Perri - 00:01:38:
That's awesome. So it's still going. I think Basecamp is one of those things. I remember when I was first getting into product management, we all looked at Basecamp and all the things that you were doing as a good guiding light for how we should be working. What have you seen be the success for staying in business for 23 years, continuing to put out innovative products like, hey, it was a huge success? What's your secret there?
Jason Fried - 00:02:03:
There's no real secret. I'll tell you what we do. I don't know if this will work for anyone else. So like I can only share what like has worked for us. And the other thing to be honest about is you don't really ever know what really works. You don't really know why exactly. A lot of it's luck, a lot of it's timing, all that stuff, right? But we've always built things for ourselves first. And I think that's actually really helpful. It sounds kind of selfish, and it sort of is to some degree. But the thing about building something for yourself is that you know really, really well if it works. And so we were a Web Design Firm. When we launched Basecamp, we were a Web Design Firm. We needed a better way to manage our projects. We were using email, in-person meetings, phone calls, kind of a cobbled together DIY system of whatever. And we were just falling apart. It was fine like early on when we had a couple clients, then you get five clients and you track the stuff, stuff falls through the cracks, you hire two people, it's just a mess. So we had to solve that problem very clearly, and we knew exactly when we'd solved it. and we use Basecamp every day to run our entire business. We use Hey for all of our email. And so we know if the product works for us. And then we expect that there's other people out there like us. We don't need to find millions of them. We could find a few 10,000 of them. And if you have a nice, tight company, small company, you can do really, really, really well with tens of thousands of companies paying you or 100,000 companies paying you on a monthly basis, for example. So we're not trying to build something for everybody. We're not trying to imagine what other people need. We're not putting stuff out in front of people and saying, what do you think before we launch it? We build something we think is good, we put it out there, and then we adjust as we go. But I think fundamentally, when you build something for yourself, you give yourself a better chance, and then you just have to find more people like you. versus the imaginary customer, the imaginary persona you think you're making things for. It's a lot harder that way. If you're gonna say secret, whatever we wanna call it, that's our guiding line is us. Which again, sounds selfish, but I think it's the right way to go.
Melissa Perri - 00:04:06:
I see that be something that's really good for entrepreneurs too. Teaching a lot of the students at Harvard, they're all trying startups. And I think a lot of people try to build things that they don't have experience in the market with or they've never been a part of it. And they see the opportunity. But I think it's really hard to understand the problems there. If you've never worked in that before, you don't know anybody who's worked in that industry. How do you keep, though, an eye on what the real problem is and make sure that you're not just building things that are specific to you but that do have more of a wide market approach?
Jason Fried - 00:04:41:
Yeah, and that's a really good insight because I can imagine a listener going, well, yeah, okay, you're building something for you, but what about everyone else? And the thing is that the kinds of products we make, everyone else has very similar problems. When you have a team of six or seven or eight people trying to work together, the problems are pretty similar. It's like, who's doing what? Who's working on what? What they say? How do I find the thing I need? How do I get some of the attention when I need it, but not too much of their attention so I'm not distracting them? How do I communicate? How do we get on the same page? How do we keep feedback on the record so everyone knows where it is and there's a yes and a no and it's very clear? All these things are the same. No matter if you're in the construction industry, the design industry, if you're teaching, if you're a publisher, if you're a nonprofit serving whatever, whoever, you're still a bunch of people trying to make some progress together. And so we keep our eye on that ball. How do we allow primarily smaller teams to make progress? How do we allow them to punch above their weight? How do we allow them to have more leverage and do things that they normally would need a lot more people to do? So, that's the kind of thing that we're always thinking about. That's why I don't really care about industries. I think industries are generally, for the most part, a false. false silos, unless you're building and doing something very, very, very specific. So for example, in the construction industry, It's different than building software. There's longer time horizons and there's some mistakes you cannot make in construction that you can make in software. There's different things going on. But at the fundamental basic level, which is where we reside. It's about communication, about keeping things in track. It's about everyone sharing the same point of view and knowing where things are. It's that stuff. We don't get ahead of ourselves by trying to build. industry specific things, we build very generic, general, simple things at the base level. And that is the broadest, widest market actually. It's always interesting because people try to get really specific and they want to kind of go up market and. biggest markets down market. It's at the base level of fundamentals, the fundamentals. That's what we're focused on. And those are relatively the same for pretty much everybody.
Melissa Perri - 00:06:50:
So in your 37signals Manifesto too, you do talk about the simplicity, which you're getting into as well. And you created a whole page called Simplicity by Design. What does that mean for you when you're thinking about building products? Like, how do you bake that in?
Jason Fried - 00:07:05:
We start by thinking about what not to do, actually. We first have a sense of what we wanna build, but then it's really, what is this not gonna be? That's a big part of it. And that starts at the company level, what kind of company do we not wanna be? What kind of product do we not wanna build? What kind of timeframes do we not wanna work under? It's starting there, which is a strange place, I think, to start, perhaps, but it helps us weed out all the things that we don't wanna focus on, and what we're left with is the core, or what we call the epicenter of the problem, the feature, the product, the company, whatever it is. We get down to the absolute essence of something because we eliminate everything else, because, look, if you don't do that, the possibilities are endless, which sounds exciting, but it's also paralyzing and impossible. You can't do at all, you can't do everything. So knowing what you're not gonna do, and being specific about that. leaves only a few things left. And then you can really hammer down and or whatever, focus in on those things and get the essence right. That's what when I think of simplicity, simplicity is not minimalism. It's not fewer things on the screen. It's like what really matters. And how do we stop there, basically? Sometimes you do a little bit more, you make something a little bit more special because it's important to whatever, but fundamentally, what's the core, get that right, and then stop yourself. The fundamental problem with software My software has no edges. It's not physical. Physical objects, we look at them, we all look at them and go, like for example, here's this can of water I'm drinking, right? If this thing was seven times the size, we'd all go, you can't, that's, how would you even drink that two hands? Like what do you even, it'd be a bad design. This is a good design, it fits in my hand. You know, it's the decent amount of liquid for me, you know? We would all look at this and go, okay, yeah, great. This is about what it should probably be. It could be plastic, it could be whatever, but software doesn't have that. So software has an unlimited palette of, and canvas of anything. So it tends to grow out of control. Because there's no natural limiting factor. There's no physical, there's no physics pushing back on you going, you can't hold it, can that seven times the size of that. But with software, you can kind of hide this there and hide this there and just kind of can balloon. So we try also tend to think of things as physical objects, our software is physical objects. What would this thing look like if it was a physical object? It's not really like a, we don't really go through that every time, but it's a thought exercise, it's a mental exercise that we do have in our heads. This is getting unwieldy. If this was physical, it wouldn't feel right. So that's another way to kind of keep things tidy and tight, I think.
Melissa Perri - 00:09:49:
I like that. I have not heard that perspective before, but I could totally see your point, like physical products you can't just keep shoving stuff into, you gotta pick and choose, otherwise it's gonna look crazy. So with that, I feel like, I definitely see us not doing that in software. So I really like this. You talk a lot in your book too, and about in rework, and in a lot of your writing about saying no, making sure that you're not building a lot of everything that the customer requests. And I think that's a really interesting take when a lot of people are thinking about hyper growth and growth in their companies these days, right? We get these investors who want us to keep building feature after feature and expand the TAM and give us everything so that we can make a wider and wider and wider market. And you have this approach that's kind of like the opposite of that. It's like, don't do that. Stay small, stay profitable, really focus. When do you know it's time to expand your product or add a new feature, let's say, right? Is there danger maybe to being too small?
Jason Fried - 00:10:54:
Yeah, I mean, maybe, but like Basecamp today is an incredibly powerful tool that has a lot more stuff in it than it had five years ago and 10 years ago. So it's expanding, it's getting better all the time, but it's still limited intentionally in different areas. How do you know, first of all, how do you know what to do? Where do the ideas come from? I mean, they come from all over. They come from us. They come from our customers. They come from the market. There's never a shortage of ideas. They're everywhere, too many of them. And we have to say no to pretty much all of them because you just can't do all of them. So you just gotta figure out what can we build that's going to benefit the most people. And that's why we don't really go into niche features for a specific industry or something. Because if I build something specifically for publishing, We have a lot of customers who are publishers, like books, magazines, newspapers, things like that. There's some workflows in the publishing world that are very specific to publishing. If we spend our time on that, We're just carving a very small niche there, which is not our niche. It's not our focus and then that's not going to benefit, pretty much any of our other customers. But you could build something that's a little bit more generic that allows people to set up certain workflows and then show examples of how a publishing industry could use it and how the construction industry can use it and how a design firm can use it. And so you back out a little bit, like you have an idea. An idea might come from some industry. And you hear this idea and you go, that's actually pretty clever and pretty interesting and I can see how that would be useful for you. How could this be useful to more? How could this be more generalized, genericized almost? And that's the kind of thinking we tend to do. So we hear these ideas and we try to pull it back and go, can we make this broader? Because to me, getting to your growth point, like growth is about for us, it'd be more about broadening our base and not narrowing in on a specific industry. Now, there's other companies who are focused very, very tightly on a specific industry and can build wonderful businesses in that industry. But they're typically coming from an industry. They're a construction firm who's like, we've got an idea for Construction Software. They know that better than we'll ever know it. And so I'm not going to dabble in that world. I still want to get back to the generic, what does a team of seven or eight people need to move forward and make progress? And so that's how we do that. Now, saying no to customers, we say no to us too. We say no to us all the time. It's an equal or equal opportunity no's. But what we do here, we hear things, we store them away, we think, I mean, we don't make a list. I don't believe in making lists of ideas, they're too long. But when you keep hearing the same thing over and over, it reminds you that there's something here. That's kind of the hook we're looking for, like there's something here, there's something here. And then you just kind of toss it around for a while, it could be six months, it could be two days. It's just sort of, you toss it around until you hit on something that you think could be really useful, and then you decide, maybe if you wanna build that. So it's a little bit more of an art, it's not a science for us, it's more about feel. It's also a matter of when. So, I might hear a great idea now, but we're just not in the mood to do it because we're working on something else or we just worked on something really complicated and we don't want to add more complicated stuff to the product. So let's give it a rest for a while and work on some simpler things. It really is this churning collection of possibilities. and you just sort of pick and choose as you go and you feel things out. And the other thing is, because we only work, we work on what we call six week cycles. So we've invented this system called Shape Up. basecamp.com/shapeup for those who are interested in learning about it. And Shape Up is based on the six-week cycle, so we won't work on anything that takes longer than six weeks. Whole product might be a series of six-week cycles, but no feature will take more than six weeks. So, we don't have to be so precious about what we choose to do, because we're going to be able to pick another thing to do in six weeks. If you plan so far in advance, like we're gonna lay out the roadmap for the next two years. You're just putting this huge amount of stress on yourself and indecision and you're locking yourself in to not being able to change. I'm not a big fan of that. So we're not really precious about the things we choose to do. If we get to it now, great. If we get to it in October, great. Get to it till next February, fine, whatever. We'll get to it eventually when we feel like it's the right thing to do.
Melissa Perri - 00:15:09:
I feel like that six weeks just made a bunch of scrum people panic.
Jason Fried - 00:15:14:
Don't care.
Melissa Perri - 00:15:15:
That's okay, that's okay, right? Like they can panic about it, but I do kind of like your six weeks approach because I feel like it's meaty enough to get something fully baked out to a customer to try it and to get some meat stuck in it where they can actually like play with this big feature. And sometimes two weeks isn't long enough for that.
Jason Fried - 00:15:30:
This is the key. This is so, so the scrum like it's like two weeks, two weeks, two weeks, two weeks, as long as it takes, but two weeks at a time. Now-
Melissa Perri - 00:15:38:
Yeah. Exactly.
Jason Fried - 00:15:39:
Six weeks is the most anything can take for us. And we only have two people working on it, one programmer, one designer. Two people have six weeks max. And most of the time it's like a week or two or three, but these are complete ideas and they need to ship at the end of that. This idea that you keep working in two-week sprints forever, what's the point of that? I don't get it. I don't get it at all. I think it's a broken system. I know it's popular, but I think it's broken. I think you need to put limits, and two weeks is not a limit if you can keep backing them up to more two weeks. Anyway, what's nice about six weeks is, like you said, it's enough time to really get something meaningful done. It's also put some pressure on because it's not unlimited time. It's almost over before it begins, which is good, because sometimes you're working on something you don't really even like working on. So that's nice to know that, well, okay, so six weeks is something I'm not really thrilled about, fine. Sometimes you're working on stuff that just has to get done that no one wants to do, but you gotta get it done. Usually it's shorter amounts of time, but it can no last more than six weeks. And we get to make new decisions all the time about what we wanna work on next. And we get to ship and move on, and ship and move on, and make progress that the customer sees. A lot of companies are making pseudo-progress, I will call it, bye. working a lot, but they don't ship things. And I think you got to ship things to customers. So that's our point of view on it.
Melissa Perri - 00:17:01:
How do you balance the research approach, talking to people before you ship stuff? I know you are a strong advocate for get things out. Make sure you get that out. What kind of stuff do you do to explore the idea or figure out what the solution should be before you start coding?
Jason Fried - 00:17:19:
We have a few people here who are, well, first of all, our customer service team is constantly talking to customers. So we get about 500 emails a day from customers. Some are feature ideas, and these are also prospective customers. Some are feature ideas, some are questions, some are problems, some are bugs, whatever, right? So there's constant communication happening. We have a pretty good read on like what's going on. And then occasionally we do these interviews, or we do one-on-one demos and we learn things because we show someone something and they go, oh, I didn't know that's how it worked. I thought it worked like this. And you go, gosh, I thought this was simple, but actually it's not. And you get these nuggets here and you get those nuggets there. And there's just these interviews where you really sit down and talk to someone for a while. When we decide to do something, when we decide to like do a project, we don't show customers while we're making it. We do the best job we can and we ship it. We believe that's when you show customers. Put out there for real, let them use it for real. If it totally falls flat, we'll find out pretty quickly. Oftentimes it doesn't, sometimes we need to tweak a little bit, fine. I'd rather get real feedback from real customers using it for real in their own real environments than show them something half baked and go, what do you think? Would you use this? I know those aren't the only two questions, but I don't like that. I don't think it's realistic and I don't think you get good answers. I think you get answers because you ask questions, but I don't think you get the real answers. There's a lot of thought that goes into deciding what to do. Again, some of this is based on customer interviews. Some of it's based on other insights. Sometimes we'll float an idea around our heads for a while. Sometimes it comes really quickly. Sometimes it's an internal frustration. We're like, God, we just gotta fix this, or we just gotta build this, or why can't I do this? And then you just do the best work you can. I mean, that's you should have enough confidence and have enough skill if you're doing this for a living to feel like you have a pretty good take on what this product should do and how it should work and what this feature should do. We don't do things that we don't really understand. We do things that we think we understand well. We can get things wrong, of course, but our track record is pretty good and we're pretty comfortable with that. So I think we would move a lot slower and not get that much better if we put everything in front of people. I don't think that'd be beneficial ultimately over the long run. I think the product would be worse because it moves slower and the marginal improvements you might get ahead of time, maybe you get some, I don't think they're worth slowing things down like they would. So we're not big into customer research during the building process. And I'm not that huge into it ahead of time, but we use it to get insights and we use it for understanding. But after that, it's on us. We're the people who make the product to make the product.
Melissa Perri - 00:19:56:
I think. So totally understand your approach from an entrepreneurship standpoint. There's a lot of product managers out there or people working for companies where it's not. a problem they deeply understand, right? They weren't in healthcare and they work for a healthcare company now. Do you think some of this still applies to them or what would you change if it was, let's say an employee, not necessarily a founder, an employee product manager coming into a company, working on tools that they don't necessarily use every day?
Jason Fried - 00:20:26:
Yeah, obviously a smart question because my previous answer would not really apply in that case, right? Which is, yeah. I'll just, again, I'll jump back. Like if we had to make a healthcare thing. What I would do is, what I'd want to do is, I don't know if you can always do this, right? I'd want to sit in a doc. Let's say it's a, I don't know, like a patient medical records thing or something. somehow want to sit in that doctor's office for a day. watching them interact with patients. I know this is, there's HIPAA, this is probably a bad example, doctors and patients, but.
Melissa Perri - 00:20:59:
It's actually not, because I worked on a medical record. So we did exactly what you're talking about.
Jason Fried - 00:21:04:
So let's say I could like literally just sit with them for a day or a week. They would do things and I would take notes and I'd ask them why and I'd say, why did it take you? I mean, I can't even think of my own experience. Why did it take 45 seconds for you to type in this note with seven words? Like what, what? And I'm like clicking around here and they're clicking around here. What is going on there? And then I'd say like, what frustrates you about your job? I would ask very specific questions around this, but I would observe. And I would get a really good, I'd try to get a really good feel and understanding of their day to day and really understand not the software they use today, but what are they trying to do? I'd fill my mind with this. I feel like I have a sense of what the major core problems are. And then I would go build something. I would not show it to them while I'm in the middle of it. I would make something quickly, though, in a few weeks, like a basic version of this, perhaps, and maybe walk them through that. But it's not an MVP. I don't like the MVP thing. It's not that. It's more like, here's everything I saw you doing. Here's a faster way to do it. Now, what can't you do in this that you wish you could do? I'd ask questions like that, or where would this frustrate you? What's missing from this that you really, really, really use? So I would have to go back and forth, I think, with people at that point. But what I wouldn't want to do is I wouldn't want to show them half-baked stuff in progress. I'd always want to show a complete idea, just maybe a very simple version of it. That's probably how I would approach that. And this is what we did. And we used to do client work way before we did software for ourselves. We were a Web Design Firm. And I would do things like this. I can only tell you I don't like working that way. But I know a lot of people have to. Partially what I'm going to tell you is what I just said is probably how I'd approach it. But I also think that my advice is not very good here, because I don't do this kind of work. And I think that whoever's listening is better off talking to someone who does that kind of work specifically. But what I would caution against is asking too many questions in the middle of building. Ask the questions before. Get a good model. Get a good understanding of the problem you're out there to solve. And then go to work and build the thing. And don't keep asking questions while you're building. Build something that works that you can show someone. Don't give them mock-ups. Don't give them wireframes. Don't give them things they can't use. Make something that they know. Again, in the doctor's situation, this is tricky because you've got HIPAA. And they're not really going to use this thing. So it's maybe not the best example. But you've got to make something that works so people can actually use it. That's where they're going to give you real feedback that matters. I think looking at pictures doesn't teach you anything. People don't know how to respond to that. People don't know how to talk about something they can't use. They're not really good at it. And so they'll give you the answers. But they're not really the real ones. That's my guess and remembering 20 some odd years ago when I used to do this that's how I would do it. Like actually, I'll give you a quick example. We did this Intranet for a Credit Union in Madison, Wisconsin, I don't know, 25 years ago. And we went up there to Madison and we sat with them and looked at what they use today and just watched them use it. And talk and go, why does it take so long? Or what frustrates, again, these questions like, what's in your way? Why is this so hard? Is it not hard? Or what part of this do you like? Or how does technology get in your way? Why are things, anyway, we sat with them for a few days and really absorbed this stuff. Then we went off and built something for them. And then we showed them something that was real and worked. and then we iterated from there. So I consider that basically shipping. We shipped something and then we iterated from there, which is what we do today.
Melissa Perri - 00:24:43:
I do think what you're honing in on though is really interesting. And I think it's a big shift from maybe 15 years ago in product management and the way that we built software to now. It's gotten faster, I think, to build software and the tools that we have today are light years ahead of what we used to have 15 years ago.
Jason Fried - 00:25:03:
Yes.
Melissa Perri - 00:25:03:
And it used to be all about, let's do prototypes, let's do this. And I still think prototypes are a valuable tool in my opinion for a lot of things. But what I've realized too is that. In a lot of places, we can actually build software sometimes faster than we can build a prototype. So I do kind of like your idea of, let's just get it out there if you can scope it down into something that takes six weeks to build and test once you have like very good validation from a customer research standpoint of like, hey, let's go this way. But I could see also in some really large organizations, it may not take six weeks to build something because of the systems they have or the old school tooling they have or the code that they're actually creating. But I think in companies that can move quickly like that, sometimes it does make sense to actually build out a good first version in software rather than fight some different tools if you don't have like a ton of things on the line or a ton of dependencies.
Jason Fried - 00:25:56:
Yes, and the other reason why I think this is really important and why we don't really work in, we don't really ever build prototypes that don't work. People say, well, my Figma prototype works because I can click around. That's not really, it's not storing data behind the scenes. It's not really a real thing. Nothing against Figma. Figma is a great tool. I'm just saying like, we build stuff in Rails and HTML and CSS and Java. We build the real thing. And the reason why is why spend six weeks building a prototype that you have to throw out and start over again? It seems so inefficient to do it that way, frankly. I'd rather build in the real medium and then iterate from there with the real code based on the real design and actually like. get a head start on this real thing, or have this real thing turn into a realer thing, versus going in one direction, trying to like perfect something that you're literally going to throw away. and then have to recreate. Making the same thing twice, not into it. I think it's a huge waste of time and I think it's a problem. So when we show anything to each other, it's cheapo terrible sketch. We use fat Sharpie markers or like a sketching thing on the iPad that's like not about detail. It's like, I don't mind throwing that away because it took six seconds to draw this thing. But I don't want to spend six weeks on something I'm gonna throw away just to recreate the same thing in a different technology. It all depends on what you're used to and the kind of organization you build, but these things layer up and matter. And the closer you can get to making the real thing, looking at the real thing, using the real thing, the faster you're going to move, the more progress you can make and the fewer people you need, which all ties back to like building a profitable business. being sustainable, being around for a long time, not needing a huge mass of staff just to do basic things. All does relate to each other. And I don't think you can look at these things individually. They are all one point of view and method to make progress as a company.
Melissa Perri - 00:27:53:
In that case too, like when you're talking about the design and not doing the prototypes, are your designers at 37signals also front-end engineers? Do they build the HTML and the code and everything, or how does that work?
Jason Fried - 00:28:04:
Yes. So every designer here writes their own HTML, their own CSS. They can make their way around Rails, which is our primary platform. They can do their own JavaScript for the most part. And that's critical. That's why there's only two people working on any given feature. We built a combine like thing in Basecamp called Card Table, two people in six weeks. Actually, that took two full cycles. So that was about 12 weeks total, but two people. One designer, one programmer, and they work together. A designer is not delivering a set of designs to somebody who then chunks it up, makes it, whatever, and they go away to the next thing. The designer and the programmer work together every single day, hand in hand, not literally, but passing stuff back and forth in GitHub or whatever, and committing code and working on things and building stuff together, making tweaks, making adjustments, they're building as they go. But yes, we don't have any front end engineers as a separate role from design. And the programmers here do like all the backend stuff, Rails, all the database work, whatever else needs to go behind the scenes is on the programmer side.
Melissa Perri - 00:29:06:
Cool. So then. that definitely keeps your team small. And I think that gets back to what you were talking about as well with the profitable company. And I wanna talk about that a little bit too, because right now, with this economy that we're seeing, I hate to say that, because everybody's like, oh, with this economy, such a funny phrase that you hear every day. But it's true, money's not as plentiful as it used to be. A lot of companies took a bunch of venture capitalist money and now they gotta stretch it, because that fundraise isn't coming around for. another quite a few years. And those that want to start a company now have to think about becoming profitable fast. And that's something that you talk about a lot. And really what you did with all of your companies in 37signals. So can you talk a little bit about how you designed for profitability and how you lead your company with that in mind?
Jason Fried - 00:29:57:
Yeah, so the primary way is initially to start small. When we first launched the company, there was four of us. And there was like, I don't know, six of us for a couple of years. And then we would hire very, very slowly, only as we needed people. So we have a philosophy, hire when it hurts. Don't hire in anticipation of pain. Don't hire because you think you're gonna need six more people. when you needed six people three months ago. Higher when it hurts. So that's the first thing. Because payroll is a huge, the primary cost center really, that marketing, which we didn't, we've never really done much of. We've been recently beginning to explore that, but over the 20 some odd years, we've spent essentially nothing, all things considered on it. So it's salaries and you know, hardware is cheap and whatever and software is cheap. So salaries are expensive. So small teams, which forced us to learn how to work with small teams and get a lot out of small teams and actually see the advantages of them. They're hugely advantageous. direct communication, we don't need project managers because there's two people working on something, so we have a product strategy, product owner who looks over the entirety of all Basecamp and all of Hay and can direct six or seven teams working on things because the teams are so small and so direct and everything's very clear, it's just so much simpler. The thing is we did a lot of the jobs ourselves. So I ran customer service myself for the first handful of years while also designing Basecamp, you know, and being the primary designer on the product. I answer all the customer emails. Like you just can make that pain go away very fast, just hire a bunch of customers. But I wanted to feel it, I wanted to know it, I wanted to understand it, and I'd rather not spend the money initially, right? So it's this initial mindset you need to go into things with, which is the problem a lot of companies have when they don't have that mindset. And they get a bunch of outside money and they grow big, big, big, big, big. And then they've got the money, the spigot turns off. And now they've got to flip into profitability mode. Like they don't know how. Just like if someone threw me a bass guitar and like play it, I'm like, I don't know how to play this. Like I don't know what I'm doing. Or if it's just a trombone, like, okay. I don't know what to do with this. That's what it's like to run a company unprofitably, kind of a sloppy company in my opinion, when you're just like blowing tons of money, hundreds of millions of dollars. Some of our competitors are literally losing hundreds of millions of dollars a year, collectively losing billions of dollars. Like, what are you doing? How is this even possible? How can you lose this much money given the number of customers that you have? I just do not understand that. Primarily it's because they avoid too many people and they're blowing a bunch of money on marketing. We just had this mindset early on, we're gonna be independent, we're gonna be self-funded, and when you spend your own money, you're more careful with it. And the other thing is that profitability buys you time. So it's like, you can't buy time. You actually can buy time. That's what profits are for. As long as we make a buck more than we spend in a given year, all things considered, all things paid for, we can stay around and have another shot the next year at doing something new, something better, servicing our customers, whatever it is. So I just think profitability, profit is like, it's this universal, wonderful thing because it allows you to stick around. It allows you to be independent. It allows you to take chances. It allows you to do what you want. I don't have to ask anyone's permission for the decisions we make. I don't have to ask anyone's permission to launch a new email service. Like, hey, I guarantee you, if we had investors, they'd be like, you are absolutely insane to battle against Gmail. It makes no sense. And I'd be like, you're right, it makes no sense, which is why we're gonna do it, because we have an idea that we think is good. And I don't have to get people's permission. So our motto is like, do things people wouldn't give us permission to do. kind of going a little bit all over the place. But fundamentally, we think about costs a lot. I think a lot of companies, they don't think about costs. They think about revenue. They think about raising money. They don't think about costs. And it's a hard mindset to shift into when you need to. It'd be a lot easier for us to shift into the opposite mindset, which is like, if someone's going to give us 100 million bucks, like spend, spend, spend. Spending isn't something you need to practice as much. Making more money than you spend is. And if you're not practiced, and then this figure goes away, you're in trouble. So maybe it's this Midwestern mindset. I'm from Chicago. Like my parents always taught me this. Like, don't get ahead of yourself. Don't take risks that can put you out of business or whatever. Like we never risk the company, but we will risk, we'll take risks, but I won't put ourselves at risk in that way. So I don't know. Every business knows this. And pretty much every business has to live this. You go down, take your clothes to the dry cleaner on the corner, they're not blowing money. They're not like, I'll clean your shirt for 30 cents, but it costs them $1.50 to do it. They're not going to do that. They're smart business people who know they need to put food on the table and make more money than they spend. Same thing with the pizza shop, same thing with the convenience store and the bodega, whatever it is, like. Most business runs this way. So it's almost kind of ridiculous. I feel like in my industry that I have to talk about this, although I'm happy to, but it's so silly that I have to explain in a sense like what it means to make more money than you spend and why it's important.
Melissa Perri - 00:34:51:
I love you talking about this too, because I think it's really important. And I think you're right. I have seen so many companies just not care about the cost. And now they do have to care about the cost. So at a left field, all of a sudden this company that only cared about the top line is like, oh, I got to look at my costs. And they realize how crazy it is. It's like out of control. And for the longest time, I think investors have been, especially with a SaaS company, they only value it off the top line growth unless it's in decline. And then they go back to EBITDA. We did things that We did not scale really well in many of those companies. So they're not super sustainable. And I think with the VC model in a lot of places, it's like, care, just get that top lineup there so I can value it at a certain number and then I'm going to sell it to somebody else and the cost is their problem at the end of the day, right? Like it'll exit and I'll just pass the buck. Also, like, you know, I was raised in a family of like bar and restaurant owners. If it wasn't profitable, we didn't make money that year. So that's how I've always looked at, you know, running my business as well is just like we need to keep making money and I got to worry about costs because I don't have outside funding. And it's so different than I think the way that investors and SaaS models kind of worked with the raising the money approach. And I've been told by some investors too, like, I don't build software like 37signals, but like with my online school and stuff, they're going, oh, don't worry about the costs. Like you're too scared, Melissa, just like throw money at the problem, just grow, grow, grow at all costs. It doesn't make a profitable business when you think about that. I hear this word too, I think from investors, that's really interesting. I want to hear your approach on this too. They always call these smaller profitable business lifestyle businesses, which means they're not going to be the billion dollar darlings that are exiting from the SaaS world. I'm curious. Your approach is very much the profitability model as well. And when you think about 37signals and this kind of like juxtaposition with investors as a lifestyle business, like what's your end goal? How do you want to grow it? How do you think about like, this is my business, this is my life's work?
Jason Fried - 00:37:01:
Yeah. Well, the whole lifestyle business thing, yeah, it's usually used as a pejorative. And, but you know, the funny thing is, it's like people who take VC money, they're doing it for a lifestyle too. Everyone, you work for a lifestyle, like great, good. So, okay, great, let's get that out of the way. So, but the pejorative sense is that you're never gonna be as big as you could, or you're gonna, you know, you're leaving money on the table and look at the opportunities that you could dominate an industry of whatever. Maybe all that's true. I don't care. I'm not interested in domination. I'm not interested in controlling an industry. My interest has always been and still is just to build really wonderful things that we use, that I like to use, that take craft into consideration. I get to work with wonderful, smart, incredibly talented people every day to make things. We get to build a sustainable business that's profitable. I take money out of this business every year or two. So we're an LLC. So whatever profits left over at the end goes to the owners after we pay all the bills, right? And salaries and bonuses and all that stuff and profit sharing is included in that as well. So we built a really wonderful lifestyle off this business and we're able to generate profit and we still get to make great stuff that we wanna make. Like I like to make things. And to me, being an entrepreneur is actually about being independent. this is gonna be a controversial take. But, well, okay, let me put you this.
Melissa Perri - 00:38:23:
You can say it, go for it. Be controversial.
Jason Fried - 00:38:24:
I didn't say. But, I really like the word entrepreneur, I'm going to I use it. If you are dependent upon an outside source for money, not revenue, revenue is different, revenue is like from your customers. But if you're dependent on an outside source, then you have a job and you work for that other person, that other fund, that other company. Are you really running your own business at that point? I'm not so sure. I work for my customers, that's to me, and we're independent. And I think that is to me, the true entrepreneurship. Like the bar and restaurants that your folks or family own, like they work for their customers and they probably worked for the bank. They probably had a bank loan. And you know, there's some of that too, of course, or maybe they didn't, I don't know, but most small businesses like have some sort of bank relationship or a line of credit or something, right? But it's different because in that case, they're not expecting an exit. They're not working towards something for someone else. They're gonna pay their loan back. Yeah, with interest and all that, of course. That's totally cool. But there's still a sense of independence there. And why I do this and why we keep doing this is because I love the ability to be independent and to make things out of nothing, to make wonderful products for wonderful customers, work with wonderful people, and not have to play a game for someone else who's extraordinarily wealthy above me, who I need to do something for so they can be even wealthier. It doesn't interest me. That's it for me. So that's what I would say. I should write something up about this. If you're dependent on someone else. You're working for them. I mean, you really kind of are. And by the way, there are wonderful businesses that are only VC style businesses that would never become what they became without that. So it's not that like investment and I put some money into a few things. It's not that investment's a bad thing. It's just that I think people who are taking the investment need to really truly understand what they're getting themselves into. That's what I think is often lost. They're not sure about what they're getting themselves into. They're just getting themselves into this because it sounds amazing. Someone's giving me 20 million bucks. I'm in. Well, what does it cost you? to get 20 million bucks. It costs you a lot of freedom and independence and flexibility actually. And the last thing I'll say about this is that When you take outside money, there's really only two outcomes. There's like going on a business or going huge, getting big. A lot of companies I think would be better off being smaller, medium sized, whatever, but they're not allowed to be if they take outside money.
Melissa Perri - 00:40:57:
That's true.
Jason Fried - 00:40:57:
I would like, I like optionality. Like why not find where you're gonna land and land there and land in a great place? Like why does it have to be all or nothing? I don't like the all or nothing model. So that's what's nice about being independent as well. You can kind of find your place, settle in and do your thing.
Melissa Perri - 00:41:12:
What I like about what you're saying too is that It's an alternative mode of being an entrepreneur, right? For people, even in software, who think that the only way is to raise money. And I run into those people every single day doing startups, right? And like you said, there are these mom and pop shops, there's a laundromat down the street who's not thinking about raising venture capitalists money. They weren't like, oh, this is the only way I could start a business. They went, let me go start a laundromat. And they went to the bank and they got a loan and they did that. But I find that people now think that the only way they can start a company is to go get venture capitalists money. And they work towards that exit because they think one year, sometimes it's 10, 15 years down the road, right? They're gonna come away with, let's say $50 million from that. But what they're not thinking about is like, how do I make money for the next 15 years too and make a steady profitable business, like you said, to take money out of the business? Because it's all yours. It's something that you own, it's something that you grow. And I really like the way that you present that. And I think what happens with the people who think about the only mode of building businesses as the one to take venture capitalists money is I also see them burn out because they're like killing themselves to rush into getting this growth that was a number that we picked out because we need to give our investors back that money. So you do talk a lot about sustainability from a effort perspective too and something that you enjoy and not burning out. What's your opinion on that? And how have you balanced that with running your own business and making sure that you don't burn out over the last 23 years?
Jason Fried - 00:42:49:
Yeah, I mean, first of all, all this stuff is hard. So like running a business in any way is a real challenge and the odds are against you. You're probably not, it's probably not gonna work. Like that's just the, those are the odds. So all this stuff's hard. So then it's like, why make it even harder? And I, to me, like raising money and living under someone else's expectations actually makes it harder, not easier. You can't run at the right pace. You've got to sprint, you've got to speed, you've got to go somewhere big or go home basically. Not for me. So I think kind of optionality and trying to reduce the amount of stress you're under is a huge part of reducing burnout and maintaining sustainability. Like there's stressful times, obviously. There's all sorts of moments in any business where it's hard and all that's true. but I feel like you have a little bit more control over it when it's your own stress that you're creating in your own situation you're dealing with versus like the stress that's coming from above, pushing you down. That is a different kind of stress. Performing for others is a different kind of stress than performing for yourself. And you're gonna maybe put on yourself anyway, but doubling up is tough. So one of the things we do here is, first of all, we work 40 hour weeks, so we don't work, I mean, look, sometimes it's 42 hours, sometimes it could be 45 hours, other times it's 36 hours, like, but about 40 hours a week, and in the summer we work 40 weeks, so about 32 hour weeks, so that helps, first of all, starting baseline, like, we want you to have a life outside of work, I am not entitled to any of your time after 5 PM, I mean, people work different times, but you know what I'm saying, when you leave, you're done. We're not pulling you back into work, unless there's an emergency, which should almost never happen. I don't own your weekends. I'm not expecting you to do anything on Sunday afternoon before Monday. That's your time, life is this, work is this, and there's clear boundaries, okay? As clear as they can be. So it's of course up to each individual person to figure out how to really. manage that, but that's our expectation of you. 40 hours is plenty, so that's number one. We also do paid sabbaticals for everybody every three years in every position. So you get a 30 day sabbatical. We might extend that to six weeks. We'll have to see, gotta figure that out. But we've been doing this for years. So every three years you earn an extra month off a year paid. That's helpful for people, really helps them sort of recharge. We have a lot of people who've been here for a long, long time. Just had someone celebrate their 14th anniversary a few weeks ago, 15th anniversary a few months ago. People have been here for a long time. And part of that is, again, 40-hour weeks, working with great people, not putting unnecessary stress and growth targets. We have no goals and no targets. We don't have anything people are trying to strive for other than to do the best work they can. that just helps to bring a certain degree of calm. And we don't work in real time all the time. A lot of our work is asynchronous. So people have their own day to themselves. They don't have a lot of meetings. There's nothing where people don't have the time to get the work done they need to do. All those things compound to create a place where you can work for a long period of time and not be burned out. But you can also get a little burned out from time to time. So occasionally, when someone's been here for a long time and they need three months off, they need four months off, we'll grant that. Go ahead, take some extra time off, get recharged. We've done this a few times for people and it's been very helpful. I just took my first sabbatical, which is embarrassing. I should have taken more of this. But a few months ago, I took seven weeks off. So I kind of ganged two of them together, essentially, since I hadn't taken a single one in 20 years. I mean, that was really refreshing and wonderful, too. I think it's all these individual techniques and also giving people a lot of agency and freedom over their work. And there's just, there's not this feeling. I think the worst feeling is downward pressure. So if it's from investors or from managers or from ownership or whoever it is pushing down on people, we try not to do that at all. So you don't feel that you're going to feel your own expectations and your teams, but there's not this, that's where I think people get squeezed into burnout. So we try to stay away from that as best we can.
Melissa Perri - 00:46:39:
And that's definitely some really good tips to make sure that everything is sustainable and you can keep making profitable businesses. So thank you so much, Jason, for joining us on the podcast. If people wanna learn more about you or 37signals, where can they go?
Jason Fried - 00:46:52:
37signals.com, so 37signals.com. I've got an email newsletter. If you go to world.hey.com/jason, you can follow me there. You can follow me on LinkedIn at my name, on Twitter at my name. I don't know, those are kind of the places. We also have a podcast called the Rework Podcast, which we talk about these things weekly, so similar topics. So that's something you can check out, rework.fm. I don't know, anywhere else I might be. That's where you'll find me, I guess.
Melissa Perri - 00:47:26:
Great, and we will put all of those links at the end of our show notes. And for those of you listening, if you enjoyed the Product Thinking Podcast, please go to Spotify or Apple and leave us a review. Make sure you subscribe so that you never miss an episode. I'll be back with another Dear Melissa segment next Wednesday, we'll see you then.
Jason Fried - 00:47:42:
Thanks.