 Jason Fried, the CEO of Basecamp, and in my opinion, one of the most important voices in design told me everything he knows about product design, and here it is. So over the next few minutes, you're going to hear a conversation between myself, Jake Knapp, the author of Sprint, and Jason Fried, the CEO of Basecamp, and he's going to give us some savage product design advice that you usually don't hear anywhere else. We go into, you know, the user testing is bullshit, all of this kind of stuff. It's really, really interesting. Now, what you're about to hear is just from the Product Breakfast Club podcast, which is a podcast that comes out every Monday. We're putting a few of the bits and pieces of it on YouTube. Let us know if you like it. Let us know in the comments if you have anything to say about what you just heard. If you disagree, if you agree. And thanks for listening. Jason, yeah, thanks a lot for joining us on the old Product Breakfast Club. My pleasure. Thanks for having me on. We thought we'd just dive straight into the tweet that we started talking about a couple of episodes back and accidentally became the point of the entire episode. And let me just read it out for anybody listening to this for the first time, which I'm sure there'll be a lot of people. So you could only iterate on something after it's been released. Prior to release, you're just making the thing. Even if you change it, you're just making it. Iterating is when you change or improve after it's out. So if you want to iterate, ship. So this is the tweet that you pumped out. I think it was just a little bit before Christmas. It caught my attention just before we started recording the podcast because a lot of people were freaking out about it, which was obviously really, it was really fun to watch. And what I'd love to do just to kick this off is to get from your perspective, what exactly you meant by that? Because there seems to have been so many misinterpretations. Okay. So basically, and I know this is all semantics at the end of the day, we're just talking about language. And when you start getting into the definition of iterate versus revise, like, okay, like whatever, right? Fundamentally, what I'm basically trying to say is that my feeling at least is that until something is out on the market, until it's actually being used for real by real customers, not being tested, like it's out. That's when you get real feedback that's really valuable. And after that is when you begin to iterate on actual feedback that to me is the feedback that really matters, which is ultimately the customer feedback from the market. Before that, you're revising, you're tweaking, you're still guessing. It's all a guess. Everything's still a guess until it's actually hit the market. But at least at that point, you're able to iterate on something that exists. Prior to that, everything's still a dream, in my opinion. It's still something you're making, it's still something you're trying, it's still something you're tweaking and revising. And there would be a million of revisions and whatnot, but I feel like there needs to be a threshold when you get to say that you're iterating. And that is once something is shipped, launched, live, being used by real customers out in the field for real, then you can iterate on the product. That's what I was trying to get at. And again, I recognize that it's all semantics and it's all language and whatever. But I do think there's this point where if you want to iterate, you got to ship. And I feel like you need to earn the ability to iterate. And that is by putting something on the market for real. Right. And you said that testing gives you simulated answers, shipping gives you real answers. Why is it that you thought you actually needed to post this tweet? Do you think a lot of companies are holding things back? What is the reason behind it? Because I think that's what's maybe interesting. Actually, it was something that we did internally. We'd shipped something. We've been using something internally for a while, and we all felt great about it. And we had some people look at it and everything was great. And then we shipped it and then like Shitstorm came at us. A feedback. The only real feedback that I believe that you can truly trust is when you actually put something out there. So it's actually something that we did. And we kind of went against our own best intentions was like, let's get this right internally. Let's make sure, let's use it for a long period of time internally. Let's make sure it's right. You put it out there and all of a sudden like reality hits. And to me, it's the same thing as if you ask people how much they're willing to pay for something. In my opinion, you cannot ask people how much they're willing to pay for something. Because until they have to pay for it, the answer doesn't matter. It just doesn't matter. I'm willing to pay 100. Well, if you don't have to pay 100, you might as well say 1,000 or 50. It doesn't matter until you actually have to pay. So I believe like the same thing is true for products. Like you can't really ask, does this make sense? Is this easy to use? How do you feel about this? How do you feel about that? Because they don't have to lay down their usage, just like you don't have to lay down their money. It was basically sparked by our own ineptitude internally. We occasionally fall into these pitfalls where we think we got to figure it out and then you put out in the wild and you don't have it figured out. We made some changes over a course of two days to fix that. But it wasn't externally motivated. It was internally motivated. It's kind of frustrating listening to you talk because I wanted to disagree more. I thought that would make for a more interesting conversation, but I think everything you're saying makes a ton of sense. And it kind of matches up with the way Moan Jonathan and I are talking about doing process, always what we're always talking about. The thing that seemed to really incite a lot of people on Twitter and sort of sparked us to start talking about it too is what role, if any, testing with customers should have. Before you launched, can you learn anything? Do you all at Basecamp ever learn anything useful or can you think, for other organizations, it ever makes sense to test before they launch? Given semantic differences aside, is there a value? What is it? Yeah, here's how we've always looked at it. And again, let me just say up front, this is just how we look at it. I'm not suggesting any of these things are right or wrong necessarily. This is just what we've done. We have a small company. We have five or six designers depending on how you count. We try to get things done in six-week cycles at the very most. From idea to shipping anything six weeks, not a whole product redesign or anything like that, but features or whatever. What I always think about is value and odds. We could put what we're building in front of a bunch of people and test it along the way. I think that would slow us down. It might get us to a better answer. It might not, but it would certainly slow us down. And then I figure out the probability. Are we going to discover something that much better than what we think we can come up with? And is it worth the cost of slowing the thing down, getting people involved, coordinating schedules to get someone to test something, getting their feedback? Now we have three different types of feedback, whether it's diametrically posed feedback. Now, who do we listen to? Now, what do we do? I think that we are best off. All things considered. Doing the best work that we think we're capable of doing. We've been doing this for a while. Doesn't mean we don't make mistakes, but we feel like we've learned a lot of things over 18 years. And let's take our best shot at it. Let's get it out in the wild. And then if we made some mistakes, we can correct them very quickly. And we'll know the real mistakes because we'll have thousands or tens of thousands or hundreds of thousands of people using it immediately and not just a small collection. It's just been our experience that that is the best tradeoff for us. Everything's a series of tradeoffs. All design products, it's all tradeoffs. And for us, we prefer just to stay tight, lean, stay focused on what we're doing, make our best choices along the way, use our best judgment along the way, put something out there. And 95% of the time, we don't run into any problems. 5% of the time, we run into big problems that you could say could have been prevented had we had it thoroughly tested ahead of time. But had we been thoroughly testing 100% of everything ahead of time, we would have been wasting that testing 95% of the time and slowing all of our process down. So that's sort of the calculation that we make. I think it probably depends overall on what you're doing, how well you know the domain. So we're building Basecamp for us primarily initially because we use Basecamp every day. We understand Basecamp really well. If I was making medical testing software, I wouldn't be using that day to day. I would have a harder time judging whether or not something is solving the proper problems in the right way. I would really understand what tradeoffs are worth making. I wouldn't understand a lot of that stuff. So I think it really does totally depend on the context of what you're building, your experience with it and with the domain, and maybe also how much experience you have in the past that you can draw on to try and make the best possible decisions. Not that they're going to be the right decisions every time, but that they're as close to the right decisions as possible and then roll the dice. And I'm willing to take the 5% or 10% chance that we might be wrong on something and then fix it quickly out in the open. Here's the thing. You can't make sure everything's buttoned up. You can hope everything's buttoned up through testing it, but then you still put out in the wild and certain things can go wrong. I've been following your stuff forever. I read Getting Real. I worked at Microsoft and I read Getting Real and I was like, oh my God, this is amazing. And it totally made me question the way we were doing products there. And then I very shortly afterwards left and went to go work at Google and that lens of like the way we're building things is not maybe rational. I couldn't unsee your view on building products. And over the years led me to create, I think this design sprint thing is the thing I eventually came up with as the way to Google to try to do some of this stuff. That's what I've been doing for a number of years. And Jonathan is the CEO of a design agency based in Berlin. They use design sprints. He's in that similar situation to I think kind of where you were probably early in your career where 37 signals was growing. You're thinking about what kinds of products to build. And so the way you describe what you can get out of research and what kinds of teams need to do it and don't need to do it all perfectly fits with the way we think about it. So I think the big thing that I was wondering about coming into this conversation and reading your tweet is that at the end of every week, the design sprints has really structured process. And the last day, you get the team to test it with customers. And I think most of the steps in the sprint, if you looked at it, you probably think, I would hope you would think that's kind of applying the same mentality like the getting real or the rework mentality to building products. It's the kind of things most teams need to do. They need to get together. They need to stop being abstract. They need to get concrete with their ideas. They need to put them in front of people as quickly as they can. But the big difference is we're saying put them in front of your customers and do one-on-one interviews on Friday because any team can do that in a week. Not any team can quickly make this organizational transformation to be able to launch so fast. So what I was thinking about and coming into this is it'd be super interesting to hear your take. Do you disagree with that take? If you could redesign what we do, what would you tell us to do differently? I've read the book. I'm familiar with the structure. I'm familiar with all that. And I don't think it's a bad idea what you're suggesting at all. I think what's important is to recognize that after four days of work or whatever and you put something in front of customers, what kind of feedback are they actually giving you? Here's the thing I always struggle with. Customer feedback prior to something that's actually truly real and shipped. It depends on the questions you ask, first of all. It also depends on the context they're in. I don't think products can be judged in isolation. And this is why I'm so much a fan of putting something out there in the real world and letting people use it for real versus testing environments. Because when someone's using something in the real world, there's all sorts of other variables that you cannot simulate. So someone had a bad morning. Their boss is screaming over their shoulder to get something done by two o'clock. They've got a meeting coming up in 15 minutes. There's some other pressures and other things they have to do. And all these things push on them in different ways and create different forces that help them evaluate whether or not something is good or bad in that moment. If someone's being patiently asked to figure something out in a more of a traditional testing setting, they don't have those other pressures. Meanwhile, someone who's already frustrated actually needs to be a lot simpler for them to figure things out in that situation. And so I just find it like it's important to take their feedback with a grain of salt. Just like you're offering them something with a grain of salt, which is this is not the final thing. And their feedback is not the final thing either. So I think it's a matter of recognizing that. I also think the other thing I would suggest is that it's a matter of making sure that you don't design by anecdote, which is someone say something or two people say something and you think that that is the thing. This one person said that one thing and like, oh, well, now we got to change everything. That's one person. That's one thing in a simulated situation. So it's a matter of figuring out to which degree of value do place upon that feedback, given the fact that the inputs are not final either and not taking those answers as gospel essentially. You have to filter back through your own judgment and your own ideas. I'm guessing you guys may not disagree with that either, but that's kind of my general feeling. I know a lot of people, a lot of companies like show customers wireframes. To me, that is just the bad idea because wireframe. Yeah, and I know you guys do, but like, this is pretty common. Still, I see it all the time. I hear from people all the time. It's like, customers don't know what to do with that. Then what they're doing is they're looking at something. They're not using something. And if you're looking at something and judging it, that's a very different thing than using something and judging it. And it's also a much different thing from using it for real and judging it. So one thing I think is interesting about this is what is realistic for a team or an individual to do when you try to share an idea about a product process with them. And I think one thing that I really tried to do when working on the design sprint process was make it something that any team could kind of pick up and do and have some good results. And I think part of the goodness, part of what I hope insulates people from those anecdotal decisions that can be really harmful or from over-interpreting an artificial situation is that the whole team is together watching the feedback. In my experience, those kinds of tests in a design sprint feel much different than the typical kinds of usability tests or especially wireframe tests that I think teams often do, which I've also seen a lot of. There's just something different about the team is in a frame of mind of what questions can we try to answer pre-launch right now before we commit and go hopefully really fast to launching. I do wonder with like when you're writing, when you're tweeting, one thing that I think is so cool about your writing is that it's so opinionated. And I know you do that intentionally. And I know that you poke people intentionally. I mean, getting real intro talks a little bit about the why with that voice. Do you ever think about like when you're writing a tweet, not necessarily this one, anyone, right? Or writing a post, do you kind of think like what you're trying to accomplish for your audience? Because I know to some degree it's stuff that's coming up real world for you. But how do you think through that stuff? I'm kind of curious and I want to get into a little bit asking you about how you write just because as someone who's admired your writing, I'm just curious. And part of it is how much of it is intentionally crafted to like the shorter and more opinionated, the missive, the more likely they're going to break their frame of mind and have to reconsider. Yeah. I mean, of course, like when I put something on Twitter, there's less room than there is anywhere else to explain something. So like you have to leave a lot of detail out. And then of course, you open it up to interpretation and then, you know, people take it their own ways. But I've always just written things down that I want to say. I don't think so much about the audience actually. This is what's on my mind. I'm going to share it. And most of it comes actually from things that are going on internally in base camp at our own company, observations that we have or things that we notice this whole string of tweets started because we screwed something up basically. And it reminded me that like, hey, you don't know until you ship it. And then you know, you can't really control when people are going to receive information like what part of their career they're in or how much experience they have, or how long they are to push back or how long they are to accept. There's so many people out there and we have a large audience. So there's no way to really know. I don't even know if I can write to an audience because we have many of them. I just write what's on my mind. For the most part, the context collars everything. And there's only so many disclaimers you can put into an article before you sound apologetic and it's like super washed out. Like, well, I didn't mean this and I didn't mean that. And you probably know it. Go at it, if need be. But hopefully like in most cases, of course, there's always cases where this doesn't apply. But the nugget is clear enough that people see, oh, I think I understand what he's trying to say here. Most people will understand at least where I'm coming from. They may disagree with it. And that's totally fine. But I want people to understand where I'm coming from. It's not calculated to get a response. I don't write provocatively to get a response. I write provocatively because I got a point of view. And I actually think that's one of the things that's missing from a lot of companies and teams is a point of view. I think that what I've noticed, especially as of the last couple years, people aren't thinking enough about how they're working. They're adopting a methodology that they read or that they picked up from someone else. That's just the way they will work until they pick up the next methodology versus them like looking at themselves and their team and go, what works best for us? Because this other team uses it. That doesn't mean it's good for us. Like, I just feel like I'd love to see more of that self reflection out there. And you see it in tools, too. You see it like for a long time, you know, people would pick up rails and act like us. Then there's node and there's react. There's all these different things that people pick up and there's Python and whatnot. And people tend to like go into these camps and just defend the camp versus it's like they're under attack, but no one's actually under attack. You don't have to defend. You can just kind of figure out what works best for you. Design sprints as a concept. It's a wonderful concept. And I think it can help most teams, absolutely, especially teams that don't have any current methodology or teams that take way too long to get anything going. That to me is the biggest problem I see out there is things just take too long for too many teams because they're just, they don't know where to go with it. So I love the five days. I love the tight thing. I love like, let's get some progress. Let's get some traction here. Let's do something, have an end. One of the reasons we work in like six week cycles is so we can always see the end. And five days, you can always see the end. Two weeks, you can always see the end. It's when you work on projects that takes six months, eight months, 12 months, 18 months, you can't see the end. That is demoralizing. It's very hard to work on something when you don't know when it's going to end, I think, especially if it's an unhappy project. And there are many of those where it's just like, you're not really totally into it. If you're not totally into it and you know it's going to end in three weeks anyway, like you just kind of, you'll be fine. If you're not totally into it and you don't know when it's going to end, that's demoralizing. So I love things that have horizons that you can basically see the end of because if it's great, you can do it again quickly. And if it's bad, you can end it soon. Great. A lot of our customers are large corporates, you know, like Fortune 500, these types of very large organizations who aren't necessarily used to creating digital products in-house. A lot of these companies, they want to start doing that. And their go-to methodology is design thinking. It's all building innovation labs or when they call in us, it's because those things have been going on for two years and no innovation has happened and no products have come out. They've been trained and they've spent a lot of money to believe that you need to do things like a six-month research process before you start anything. How would someone like me being called into these companies, what would be a way for you to go into one of these companies and help them at least understand a little bit how to move quicker? Or do you think it's just like impossible to change a company of that size? I think it's definitely hard to change a company that size. But I think the first thing I would say is, hey, is what you're doing working? Why are you calling me in? If what you're doing is working, you don't need me. I have an alternative point of view on this. Let's try something in a week. What can we build in a week? What can we build something here? Can we make something here? Can we do something in a week? If they say that's impossible, then you can show them that it's possible. And I think that in a lot of organizations that are especially much larger organizations and more traditional organizations, they haven't seen that be possible. We're launching a large visual refresh of Basecamp 3. And we did this in seven weeks with one designer. Now, it's a big product, huge product, millions of people using it, like big time thing. One person did it in seven weeks. Now, that's not a bragging point. All I'm saying is that it's actually possible to do that. It's possible to do that. In a lot of organizations, I've been reading a lot of posts on Medium about refreshes. And it's like an eight month process. And there's 42 people involved. And there's all these steps and all the stuff. And you read enough of those things and you think, this is how you do it, right? You put a bunch of post-it notes on the wall, you have 20 meetings over an eight month period, and you do tons of research, and you interview tons of people, and you have seven different specialties involved. And there's also other ways to do it. And until people can see that, they don't know it's possible. So I would go into an organization like that and say, let's not even work on this problem that you hired me to work on, because there's already too much baggage there in a sense. Let's work on something else. What else do you have going on here that you want to improve? What can we do in a week? So I would start on a parallel thing, because by the time they've called you in to rescue them, there's probably so much baggage and so many personalities tied to it and so much politics tied to it and a lot of pride. But I think if you take a step over to the right, you just like slide over and you go, hey, let's pick something else. Let's try something else. What else is bugging you around here? What other screen or other process is like a mess? Let's just pick that one. I mean, there's probably still some politics, but it's not like fresh politics. It's just like maybe old politics. Let's pick that. And then I would demonstrate that it's possible and then go, okay, now see what's possible. Now let's step back to where we were on the thing you hired me for. And now let's see if we can apply some of that same approach to that. I think then you have a win under your belt and some evidence that this is possible. It's hard to, I think, ignore that at some point. That said, none of this is easy. This is why I got out of consulting a long time ago, because it's very hard to change organizations, extremely hard to change organizations. So you mentioned that earlier, people, they don't really think about the ways that they're working. And Jake, you talk about defaults. And I think there is one very bad default that I see in even in startups and in smaller design agencies that I work with is that people think that the difficult way is the right way and that the only way to really get things done is to do it the hard way. They're looking for all of this friction when there really doesn't need to be necessarily friction. And that's one of the crazy things I guess that refers to what you just said, Jason, when we come in to a company and run a sprint or when myself and Jake do a sprint workshop, people are just like, wait a second, this usually takes us six months, eight months. Shouldn't we create a product vision document first before we do something like this? Where do all these really difficult, stupid things come from? And you realize people in the company, they don't even know where these processes came from. They just adopt them when they join. They just take on these bad defaults and don't think about it. It's a process that really just doesn't improve on its own when they're comfortably plotting along. There's a benefit to shipping fast and to moving fast, which is that you learn in the real market. By moving fast, it may be more likely to stay true to your opinionated vision. The longer you take and the more you debate it inside and the more you try to react to feedback real or imagined, the more you are often going to water it down. That's a big part of what is so successful and so powerful about base camp and about your writing and about the vision for developing products that you've shared. It's really hard to do. It's hard to be authentic. I just find myself every time I write something struggling to not water it down or think about the audience. And you make that seem quite effortless. I feel like this is all tied together. If companies can be more authentic, if they can be more true to what they want to do and more opinionated, that a lot of things just come together and work better, how do you do that? How does that work? Well, maybe it's a defect of mine. I don't know. That's possible that it is. Thing is, I disagree with myself all the time. So I'll write something up. I mean, I can see another angle on anything that I write up and I could disagree with myself immediately. And sometimes I do. I think you've actually hit on something great, which is one of the things I've noticed about long running projects. You begin to second guess yourself. There's a cycle where you begin to second guess yourself because you've been sitting in front of it for so long that now you have a new idea. I think you need to be very careful about that. You're a designer. You make things. You're a creator. And so you sit in front of something for six months. It's old to you again. It'd be brand new to customers who haven't seen it yet. But to you, it's already old. And then you start second guessing every decision. You start second guessing 10% of them and you start making changes at 10%. And now you have inconsistency. And now that you have inconsistency, you've got to figure that out and get consistent again. So you either have to go backwards. You have to go forward all the way with a new idea. And that six month project turns into nine months, 10 months project. And then maybe you start second guessing yourself again to go, yeah, you know what? Maybe the first thing we do is better. And then like, I love squeezing all of that indecision out and going with something. We don't look at multiple directions whenever we do anything. We pick one and we go. We revise and play off that. We rip off of that central idea that we have. And we evolve that. So we don't look at three or four or five things and pick one. We just build one. Once it's out, we might come up with a better idea. We just pick the one we like best and evolve it and then get it out to the market. We just commit early to things and we make them the best way possibly can be in our opinion. And then if we want to change and we change them, for example, this redesign that's launching Tuesday for Basecamp three, Basecamp three launched about two years ago. I've been using the new redesign for about three weeks and I can't stand looking at production currently the current design because it looks 10 years old to me now. So I'm so excited to get the new design out next week, but had we held up the new design and like, I'd be bored of that, I'm sure, we've always tried to squeeze out opportunity for things to slow down. Again, here we go. I'll disagree with myself. Like I can make the case that maybe second guessing something is right is a good move because then you put it through its paces again and are you really certain is a honeymoon phase over like all that stuff. I can make all those arguments, but like again, it comes down to trade offs and odds. I'm not willing to constantly provide space to second guess. We can second guess in six months after the thing's been out for six months. I'd rather that be the case than to hold everything back and try and pursue this when you have no more second guesses and everything's perfect in the whole thing. I just don't think that's how things work. So, and as far as writing and not thinking about the audience, I try to write my blog post within 15 minutes, 20 minutes, like that's it. So I write and I do a little bit of editing and I publish and that's it. If you work on it over a matter of days, you're going to rewrite it three or four times. You know, is it going to be 3% better? Maybe. Is it worth 3% better waiting four or five days and then maybe not even publishing it because you get cold feet or something like those are all things that happen. And I just try to avoid them by getting stuff out fast and then not having to face those internal demons of is this actually any good. Some stuff I published, I shouldn't have put that out, but I did. It doesn't matter because it's everyone forgets about it three days anyway. You know, who cares? You just kind of for us, except for you. I try not to attach this preciousness to these things. And instead I put them out there and they are what they are and they stand up for themselves or they fall down on their own and like, what do you do? So I'm trying to kind of create a new career for myself writing. I'm trying to write like fiction, which is I have no business trying to do that. But one of the things that really inspires me a lot is this book on writing by Stephen King. I don't know if you've read that. I've heard of that book. I've not read it though. I highly recommend it to everyone. Like you don't have to be a Stephen King fan. I was not before reading it, but what's really the most cool thing about it. I mean, he has some great writing advice. But the most cool thing is how passionate he is about what he does. You know, he writes like two 800 page books a year. He does the Stephen King version of the horror novel version of what you're talking about, which is he just cranks them out and then he just publishes them. He does like one revision and that's it. There's no long editing process. He's like, yeah, some of them not that great. Maybe I'm not so happy that whatever. Like I just enjoy doing it. I'm just going to keep going and I feel like that un-preciousness, that willingness to like just go and just make the thing and just let this like perfectly crafted version of yourself not exist and just like go with it and just go is so admirable and it's so hard to do. But hearing you talk about it and that's inspiring. It makes me want to be more precious. You're doing it right now. We're recording a podcast, right? This is one take. Yeah, that's right. We're having a conversation. The only differences is that we're talking versus, you know, the talking going through your fingers and the keyboard. I don't see them as different. But I think a lot of writers do see them as different and they feel like if it's written down, it has to be perfect. I want to make sure that things are spelled properly and that I love the rhythm of language. And so I want to make sure if I can find the right word that has a couple of good balances in it to the next word. Like I'll play with that stuff a bit. But to me, that's play. I like to play with that. Those aren't critical things. That's more for me. That's selfish. I just like the way it sounds. You know, I want to make sure it sounds great, but it doesn't really matter. And you can argue it does matter and like whatever. You can go down all these roads. Like we're having a conversation. If we were having coffee right now, we'd be having a conversation. Conversations, you don't redo them. You just have them. And I think that's how I like to write. I just have a conversation with the keyboard and I sent it out there and I can't take it back. And I think once you think about that a little bit more, I think maybe perhaps books. Like we're writing another book right now and we do a little bit. We're editing with the book. For some reason, there's an expectation that we also have to work with a publisher. There's different levels here. When we wrote Getting Real, like we still publish that to a PDF and like, boom, there it goes. Publisher is different. So like there's different players and parties involved. So you're not just working for yourself there. But I would begin to think of writing as just having a conversation with somebody you can't see and you don't get to take it back. You seem to be very effective with how you use your time. You think a lot about, should I be in meetings? You know, that's my impression is that you're very conscious of how you spend your time and making good use of it. You're on Twitter a lot. Like I'm impressed with how you will engage with people on Twitter. I mean, I don't know if you're on there all the time, but people will tweet at you and you're kind of famous and you'll like write back to them and have a conversation with them. What role for you does writing, does tweeting, does that stuff play? How does it fit into what you're trying to do with your time in general? It's spontaneous. I pop on and pop off here and there. Sometimes I'll kind of go on a roll if there's something I'm saying that people are engaging with. I tend not to reply to people who have an agenda, who are trying to just get your argument, because we could argue it all day long, but Twitter is absolutely the wrong place to argue anything. So for me, it's more like people who have questions and want clarification or something like that. I'll tend to follow up with them if I can, if I have something that I feel like I can add. I don't really want to get into battles on Twitter. It's just the wrong place to argue. I'm happy to argue. Like, I'd love to see more arguments on stage. I think that our industry is under-represents the debate. There are hardly any disagreements on stage if you go to any of these conferences, especially on panel. Yeah. Everyone's like, yeah, and yeah, and yeah, and yeah. I'd like to be helpful on Twitter, which is like if someone's clarification, they want a resource or they want to link to something. Like, if I actually know someone who disagrees with me, I might go into it a few tweets with them because I know where their heart is on it. I know them and I respect them and I feel like we can argue a little bit versus it going like way off track. I don't set aside time for that. I just, you know, when I feel it, I pop over there. To me, like, Twitter and Instagram are modern-day smoke breaks, basically. Like, way back in the day when people smoked a lot of cigarettes, companies would let people go outside for 15 minutes and smoke a cigarette. And like, no one thought that was a bad thing. I actually feel like people were healthier smoking cigarettes because they got to take a break. This is, of course, not technically true for lung health, but they got to take a break from work. Usually they would sit outside and talk to other people, other smokers, I guess. To me, that's what Twitter and Instagram are for me now. I'll take a jump on there for a little bit, poke around, and then get back to work. They're a little relief moments, but I don't have a Twitter window open all day. I use a 12-inch MacBook. Everything I do is full screen, so I never had multiple things up at once. I'm just a full-screen guy, focus guy on one thing at a time, and that's just how I manage to do it. Well, very disappointing, Jason. You keep looking for some master plan besides your persona and your brand, and it's just authenticity. That's just, it all comes back to authenticity. I don't think too much about that stuff. I just kind of do what makes sense to me and what feels right. And I don't think too much about it, actually. I'm very intentional about how we run our company and that kind of stuff. But when it comes to me just sharing ideas and thoughts out there, I just share ideas and thoughts. I don't think too much about that because to me those are personal things and they don't impact other people in the same way as if I make a policy decision at the company, it might affect 56 people. And I care deeply about that, so I'm careful about those kinds of things. On Instagram, you post a lot about really nicely crafted watches, beautiful cars. These are products that don't come out the first go. Like, let's just get it out there and see what happens. Obviously physical products like that, especially these watches, these are things that need a lot of time to be crafted and to be perfected. How do you reconcile your digital product opinions with what seems to be a love for really well-crafted, really well-done physical products? Or does that even matter? Yeah, I think it comes down to the malleability of these things. So like software can change eternally, permanently, forever easily. You ship a watch, like no, can't. And in fact, even with software, way back when I first got started with software, I was using FileMaker Pro to make software. This is actually before the internet, so I was uploading stuff to AOL. And basically, you'd upload this thing. It was like an executable, like a standalone FileMaker Pro database. And like, if I had to update that after I shipped it, like people have to download a new version, do a migration, like it was a real pain in the ass. So back then, I was actually way more careful about what I was shipping because change was hard. And changing a car is incredibly hard and changing, you know, a watch, you basically can't do those things. So to me, it all comes down to how easy is it to change? What is the cost of change? And if the cost of change is really low, I feel like you can run faster and experiment more and be more willing to put stuff out there that may not totally be finished because it's never finished anyway, unlike a physical product is finished in a sense. But even that, like you launch physical product and new ideas come out. Like we're kind of inspired by car manufacturers. So Basecamp is all we do now. We're on version 3, 12 years in. Portion 911 has been around for 50 years. There's been six different iterations of the 911. And it's still the same idea, engine in the back, small coupe, you know, the whole thing. But every five, six, seven years, Porsche has a new idea. New chassis, new engine, whatever. They also do mid-cycle refreshes. You know, they change the bumper a little bit, change the interior a little bit, whatever. That's kind of what we're doing with Basecamp 3 right now. We're doing our visual refresh, but fundamentally it's the same product. So even if Porsche has a brand new idea, like they ship the car and like, ah, this interior, you know, we have a better idea. I guarantee you they're working on that new idea already. And in three years down the road, they'll ship it. So if they are changing, just the pace is different. Our pace can be, we can make a change in an hour or five minutes or whatever we need to if we need to. So, but I do appreciate the limitations of physical products, how there's a different level of criticality and how you have to be more careful about certain things because you don't have a second chance with some of those. Right. And a lot of people on Twitter, that's the first thing they jump on. They're like, all right, Jason, what about if I was making a plain asshole? Yeah, I know exactly. And I always say like, are you making a plane? Well, well, it's an app that is kind of like, you know, related to planes. It's an app. It's like a plane. And it's like, no, it's not. So it's a gotcha culture. It's like, yeah, absolutely. Nobody really is making a plane, except for like a thousand people in the world. In the world, thousands of people are making a plane. Now, what about, you know, what about brain surgery? It's like, you posted it on Twitter. So you're talking about like back to the tweet again, back to getting things out there and then iterating when they're on the market. I think one of the reasons why companies are so precious about their products and so reluctant to get them out there is because they're taking bad examples from other companies that they don't understand. A lot of our customers, even like very new startups who they read the right books, they do the right things, they take their inspiration from companies like Apple who do hold things back for an entire year and do still release things all in one big bulk. And I think they almost think that that's how it's supposed to be because this whole Steve Jobs thing was such a big deal and design is almost defined by Apple in the last 10 years. So for me, often the first thing I have to do the first few weeks when I go into a company is just try to tell them to pull back from this like obsession with these companies who are totally nailing it in a non-iterative way and show them case studies of companies who are actually able to do this very, very quickly, very successfully. I think it's a lot to do with just having bad role models or incorrect role models for the time that the company is in or the place that the company is in. One of the unspoken rules although we sometimes kind of mess up in this is don't use Apple as an example, don't use Amazon as an example, don't use Google as an example. These are extreme outliers. They just are extreme outliers. I mean, they're great companies, obviously, but you're not them. You don't have the resources they have. You don't have the criticality they have. You don't have the scale they have. Apple kind of can't, in many ways, they can't screw up some things because they have a lot of billion people. So it's like, it's just different that Steve Jobs would never, like whatever, cares. Yeah, exactly. By the way, I think that's important when it comes to business advice as well. Like, I don't think you should be listening to Richard Branson tell you how to start a business. He's at another level and there's nothing wrong with Richard Branson. Like, Richard Branson is great at what he does, but that's not what you're doing if you're three people in a startup. Like, you're not that. And likewise, I'm the wrong person to talk to about starting a business. I've been starting a business in 18 years. I'm the right person maybe to talk to about keeping a business going and in the things that I do on a day-to-day basis, you shouldn't be listening to me about how to start a business or about how to take venture capital money because I've never taken it. I have my opinion about why and why you shouldn't in all those things, but like, if you're going to do it, don't ask me about what it's like because I don't know anything about that. So I think it is important to match your mentors with your situation. In fact, I think it's far more valuable to talk to, if you're starting a business, it's more valuable to talk to someone who started one six months ago than to talk to anyone who's been successful at it but hasn't done it for five years or 10 years. Like get to the ground, get to the real, get to the person who's closest to your situation. They have the most information about what it's really like at that time. So that's what I would look towards and not like look at the idols, the extreme outlier idols. By the way, Amazon's kind of interesting alternative example to Apple, which is Amazon kind of shifts things pretty rapidly and kind of comes up with quirky, weird stuff and a lot of it doesn't work and they're like okay with it in a lot of ways. Or their first Kindle, look back on it now is kind of a mess. Like in their head, they're probably like, we know it's a mess, but like we're going to get out there and we're going to have a new version in six months and new version in six months, new version in six months. Or we're going to get there eventually three or four years down the road. We're going to get there eventually. Amazon and Apple actually complete opposites, I think, in that world. And I actually think that the Amazon model is a lot more realistic for more companies than the Apple model. Me too. Yeah. And by the way, Apple's been slipping a lot, which is interesting. Like they've been slipping on hardware lately, the home pods late. They've maybe set up these expectations for themselves that are actually difficult for even themselves to meet now. And so if they can't be themselves, how are you going to be them? That's deep. That's very deep. Jason, do you think that base camp is an outlier in a different way? Obviously, I mean, you guys are huge, but do you think that you're an outlier in a way? Are there things that teams might find very difficult to reproduce about what you do? I think we are probably in some ways, for sure. Part of it is because we've been in business for 18 years and that makes us an outlier just period. The other part is that we've had a core that's been around for a long time. A handful of people have been here for 10 years now, seven, eight, nine, 10, 11, 12 years. The average 10-year base camp is five years. And then in our industry, I think it's 18 months or something like that. So that actually affords us certain things that brand new teams cannot have, which is like a certain level of camaraderie, a certain level of comfort and pushing against each other, a certain level of honesty that you don't have with strangers, but you have with good friends, in a sense. People you've been working with for a long time. That's not impossible for other teams to have. You just have to be dedicated enough to have that opportunity. So I think that those are some of the things that allow us, perhaps, to be able to do some of the things that we do. But those aren't impossible things. It's not that we have superheroes here. We do not. We don't hire famous designers. We don't hire famous programmers. We don't hire anyone who's famous. Well, you guys are famous designers and programmers. I mean, that's true. Whatever that means. But my point is that we're not poaching from Apple and poaching from Google. We don't have anyone who's ever worked at Google or anyone who's worked at Apple in technical roles. Or we hire people who are just really, really good at their job and can become really great at their job. And they're often in places where they're not being appreciated or they don't have the opportunity to shine or grow. None of us are superheroes in that way. We didn't pick an all-star team. We may have built an all-star team, but we didn't pick one. We didn't recruit one. I'm really inspired by the coach of Santone and Spurs. Probably, right? They've had a few stars along the way, but they've been good for 20 years. That's what we're trying to do here is kind of take any pieces that we can find. And you have some long-running pieces. He had David Robinson for a while. Then he had Tim Duncan, and he's got Quy Leonard now. Like, he's got these core people who are dedicated long termers but then can assemble anyone else into a great team. And so I don't think that we're outliers in terms of initial talent. I think we become good at figuring out how to work well together. And we do have a unique way of working that we share with anyone who wants to know about it. So it's not like we have secrets. We're outliers because we've been around for a long time. We're outliers because people have been here for a long time. It's hard to get used to the way we're working. I don't believe it requires a certain level of superhuman talent or anything like that to do the things we do. It's just a matter of choices. Companies are a collection of choices and decisions. And figuring out which ones you want to make and how you want to make them, and that's what makes up the company. So all these are decisions that other people can make too. There's no level of intelligence that we have. It is so much high. I just don't buy that. In fact, far more intelligent people out there than us. Clearly, if you asked us to build some AI, so we couldn't even get started. I don't know how to do any of that shit. We have a couple really particularly good programmers on our team, but we don't have deep computer science people. We may have one or two, but it's none of that. It's just figuring out what matters, figuring out what doesn't matter, which is even more important, squeezing out all the stuff that would distract all of us from doing our work, putting realistic deadlines and time frames on things, being really good at scoping, working, figuring out what really matters and what doesn't, and getting rid of that stuff. It's a bunch of those things. You have to practice that, of course. Jonathan and I were talking before the interview started about what we selfishly wanted to get out of talking to you. I'm looking for advice I can apply to, either making the design sprint better or making my writing go better. You've said this ton of stuff that to me has totally struck that chord. I'm like, man, the authenticity is just a do-it-like. Do it faster so you can get through it while you're still being authentic. I think there's a lot in what you just said that also really, to me, Jonathan, I don't know how you feel about it, but it sounds so much like the situation you're in right now where the agency is young, you're the CEO of the agency, you're trying to figure out how to grow and how to make that work. Jason, if you had words of wisdom for somebody who's like, you're still shaping the form of your company in those early stages, and obviously you have a lot of stuff out there that is advice for people, but what's the hardest thing to keep true to all those elements? Like, what would you have done differently or what are you so glad you did? I don't know if there's one thing, but I'll share a couple things that I think are really, really important. Protecting your team's time and attention is the most important thing you can actually do. If you want people to be able to do great work, they need uninterrupted stretches of time to do that work and they need to go home and get away from work and they need to sleep well at night. At Basecamp, we don't have shared calendars. I can't see anyone else's calendar, no one can see mine, so I cannot claim time on people's calendars, no one can take time from me. Everybody at Basecamp who works in product roles specifically has a full day to themselves. It's their day, it's their eight hours to do what they need to do to get their job done. It's not, they have two hours today because there are meetings for six or whatever. So I think that giving people a full eight hour day to themselves, figuring out how to do that and how the company does not have to steal time away from people and burden them with all sorts of other things they probably don't need to do is really important and the key thing there is to think about what really matters now versus what matters later. So the reason we don't have a lot of meetings at Basecamp, hardly any meetings at all, is because meetings happen in real time and the stuff that's discussed in those meetings rarely has anything to do with the moment it's being discussed. So instead we write things up. We're very asynchronous in that way, we write up long detailed documents, write up messages, write up pitches and share that stuff. So people can read those things on their own time and their own schedule versus being pulled away from their work to get into a room to discuss something right now that has nothing to do with right now. It's about like structuring your day and structuring your time so people have it. It's really as fundamental as that. I think if your day is filled up with other people's obligations then you can't do your work. That's why people are working longer hours. That's why things are taking longer. That's why everyone's stressed out and rushing all the time. It's that kind of basic fundamental stuff I think you have to get right first. So people actually have the time to do their work before you can solve any of the other problems. But I would also say that so much of what we all do every day does not matter at all. Lengthy debates about this interface element or that interface element or this feature or that feature in many cases any of them will do probably just fine. In some cases some are certainly great ideas and some are not like that does exist. But most of the stuff is okay. So like I still like make call and move on. Something we learned from Jeff Bezos in his latest shareholder letter. I love this idea. I don't know if you guys read it. Disagree and commit right. Disagree and commit. Oh it's so great. We'd use this idea internally but we never had language for it. And now that we have language for it we use it all the time. And so it helps us shorten debates that don't need to go on very long. So we're not looking for consensus. We're not looking for everyone to agree. Like we make our point we all talk about it. And then on every single project there's somebody called the point person. And the point person makes the final call whenever they're ready to make it it's made and that's it. Whoever disagreed commits and we go. So we're just trying to always have forward motion. And I think that's another thing that I would encourage people to get used to. It's not about speeding through things. You want to make sure things have been heard enough. But once arguments start being repeated you can start to see where the circle or the loop closes and then you're like you need to make a call. So I think it's just developing those kinds of skills. I can never answer the question like what's the one thing I'd suggest. But I do think respecting time and attention first and foremost is critical because without that it's very hard to get any meaningful work done. And then it's about like really figuring out what is meaningful work. What is not worth doing. That is a lot harder to figure out than what's worth doing. What's not worth doing is really hard. So we kind of work on those skills and how do you do that. That's a whole nother podcast. But the other thing I would just finally say is like get very good at saying no to things. Like really build up your tolerance to being okay to say no to stuff and work on all that kind of stuff and keep the team as small as you possibly can for as long as you possibly can. We basically like we're 56 people now. We have a hiring freeze. Not because we can't afford to hire people we can hire 100 people whatever we wanted to hire. But we don't want to hire anyone else. Everything we want to be able to do we should be able to do with who we have. And if we can't do it with who we have then we either don't do it or we do something else or we wait until we can do it. So you guys started in 99? Getting real in 2006. Rework 2010. Yep we were probably 30 people, 20s, 30s something like that. We tend to hire a few people a year max like two or three. There have been some moments when we've hired five or six because we hired a lot of people in customer service. So we've had a few years where we hire two or three people a year and then we work with what we have. We force ourselves to make better decisions because we don't have a lot of extra room not to make good decisions. It's so interesting to me that the first thing you said was make sure people have time to work and you're not interrupting them because if that is your first principle that forces you to say no. That forces you to be really careful about who you've got and what things you're taking on and what kinds of culture you allow in terms of meetings or discussions. You can't allow them if you're going to give people time which is great. Actually there's probably a step before that which is eight hour days, 40 hour weeks. That's really step one for us and everything we do has to be able to be done in that amount of time. It actually makes a lot of other decisions very easy because then you're like should we sit in a meeting for three hours? No, we only have eight hours today and that's three of them gone and we only have 40 hours this week and so that's 10% gone roughly. That doesn't seem like it's valuable enough. How else can we make these decisions? That kind of stuff and you start to think like we don't have that much time and in the summers we only work 32 hour weeks. May through September we do 32 hour weeks so that even compresses our time even more which allows us to practice being more and more efficient with our time and really get down to what matters and what doesn't. That can be a struggle sometimes but it's a good struggle and then it makes when we get back to 40 it's like oh my god we have all this extra time. And most people are like 40 that's not anywhere near enough time but it is plenty of time. And the way I think of it in eight hour days is like a flight from Chicago to London is eight hours and if you've ever been on a flight from Chicago to London or I guess basically an eight hour transcontinental flight like it's long and you look at your clock or your watch or whatever and you're like oh my god there's still four hours left and then you look at it again and they're like there's still two and a half hours left at work people are like it's five and it's like oh my god it's five already where'd the day go? Like no one feels like that on an airplane because on an airplane there's no distractions and it turns out eight hours is a lot of time to do a lot of stuff when no one's bothering you. So that's where we start from that eight hours is plenty of time and I think it'd be interesting actually if go get a flight that's eight hours and go sit on it and do nothing and see how long that feels because that's your work day and you'll realize that actually days are pretty long you do have this kind of time every day you have this kind of time just to feel it the same way. As a team you could start with that principle that we are going to have full work days and start with that lens that so many other things might fall into place because you just wouldn't take on the kind of complexity you wouldn't wait forever you can get things done so much more quickly when you also when you have dedicated time and you can get your head in it and you're not constantly bouncing out whiplashing between different things it's such a counterintuitive first principle to think it's about the quality of your day if you start there with the quality of the day the people who you work with and yourself good things will flow from that. I think so and you can even start by the way at the quality of an hour that's really kind of a good unit so like 60 minutes 60 times one is what we're after not 15 plus 15 plus 15 plus 15 that's still 60 minutes but it's not the same as 60 minutes you know what I mean so we're really looking at like kind of the quality of an hour first and then stacking eight of those on top of each other giving that to every person then stacking five of those days in a row every week and turns out you can get a whole lot of stuff done when you're flying to London every day basically. Excellent and I think that's a great way to end the podcast I think really really great topics really interesting conversation amazing that you took the time to do that Jason really appreciate it and I feel the same way thanks for making this happen now thank you for being so generous with your time that was that was totally awesome have a good one Jason take care love to know what you thought about that episode with Jason Fried was really great having him on if you're interested in things design sprint or design related or product design related don't forget we have a weekly podcast called the Product Breakfast Club podcast on all podcasting apps we have daily vlogs on Instagram on our AJ and SMART channel definitely check that out have a great one bye bye