SEASON 2 - EPISODE 0093 - JAN 24, 2024

REWORK Live!

In this special YouTube live episode, co-founders of 37signals, Jason Fried and David Heinemeier Hansson, join host Kimberly Rhodes to field live questions from listeners.

Listen in as Jason and David answer questions about topics such as the recent launch of the HEY Calendar. They also share updates on the release of Campfire, the first ONCE product, with behind-the-scenes details about this simplified and affordable chat tool.

Plus, tune in for insights into the evolution of the Shape Up methodology, learning from customer feedback post-launch, and the Founders’ thoughts on the exciting but uncertain future of AI in the ever-evolving landscape of technology.

Check out the LIVE video episode on YouTube

Key Takeaways

Highlights from the HEY Calendar launch.
Updates on the ONCE line of products from 37signals and the economics and philosophy behind fixed-price software products.
Campfire’s role as a simplified, affordable, and privacy-focused group chat tool.
The importance of engaging with customer feedback after product launches.
An overview of the evolution of the Shape Up methodology, its application in new product development, and adaptations for different team sizes.
AI—excitement, caution, and its potential impact on the technology landscape.

REWORK is a production of 37signals. You can find show notes and transcripts on our website. Full video episodes are available on YouTube and X.

If you have a question for Jason or David about a better way to work and run your business, simply email us, leave a voicemail, or text us at 708-628-7850. Your question might just get featured in a future episode!

Links & Resources

Transcript

Kimberly (00:00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. We recently recorded REWORK Live where we took our conversation to YouTube to share some current updates from 37signals and answer some listener questions live. Here’s that recording. Enjoy.

(00:00:18): Okay, I think that we are live on YouTube. I’m Kimberly, the host of the REWORK podcast. I’m joined by Jason Fried and David Heinemeier Hansson co-founders of 37signals. I think that we’re live on YouTube if we are, and you can hear us and see us, let us know in the chat. Thanks for being here. We know we have lots of people joining us live. We’re trying something new. We’ve never done this before. We usually record the podcast and then push it out later, but we thought, why not just hop on live and answer some live questions. We know that you guys are here to hear from Jason and David, so I won’t spend a lot of time talking. We’ll get right to them and I think first we’ll start with a question we already saw pop up on Twitter, which is you guys just launched the HEY calendar. What about ONCE? When are we going to hear about ONCE? Jason, do you want to take that one?

Jason (00:01:05): Yeah, I’ll start. I mean, we’re late, so we made a public promise essentially that we would have this done or have the first version, first product from the ONCE family out by the end of 2023. Now, this is more of a patting us on the back, but not really true. I mean, it’s true, but not completely. We did release it to some customers early at the end of last year, so some people have it. There’s I think six or something like that, or eight. So it is out, but not really. It’s a good example frankly, of never making public promises because you just shoot yourself in the foot more often than not. With the HEY calendar, we launched January 2nd, although with the Apple thing, we had to push that off a little bit, but we were ready to go on January 2nd. As we said, we would be all the way back in March of 2023.

(00:01:54): We predicted we’d be ready and we were, but we didn’t promise that to the public. We just said early 2024, and it turned out to be true. We didn’t make a public promise. It was specific. With ONCE we did, and we didn’t hit it, and so it feels kind of bad. That said, we are very close, in fact, today or tomorrow, actually going to launch to a significantly larger batch of people. It’ll not be public for everybody, but it’ll be let’s say wider beta and people will be able to pay for it. The first product, again is going to be, it’s called Campfire. It’s, it’s a group chat tool similar to Slack or Teams, but significantly simpler, kind of the way these tools used to be before they became bloated, complicated, convoluted, massive messes in a lot of ways. So I expect a week or two of that beta stuff happening before it’s probably out for wider release. So anyway, just always a reminder that, and by the way, the reason why it’s bad to announce release dates publicly is because they’re always far in the future and they always sound easy to do. It’s very easy to say yes about something later and we have to continue to learn our lesson and we learned it again here. So I dunno. David, you want to add anything on that?

David (00:03:06): Yeah, I think we’ve made this mistake several times over the last 20 years and every single time we make the mistake, we say never again, never again. And then a couple of years pass by, I’m like, eh, this seems so easily doable to hit this target. I think one of the things that added some complication here was we were trying to do two launches at once. We have never ever attempted anything as foolish as that when you’re a small company. So we had HEY Calendar, which is a major new product that we’d worked on for a whole year happening at the same time because we’re bigger and more capable company as we were developing ONCE and felt really exciting. Hey, we have two separate teams. We can do both things at the same time, but there’s just a gravity of attention that goes into any major public launch, and Jason and I can’t split ourselves.

(00:03:51): The rest of the team can’t split ourselves when it comes to a launch. So when we pushed out, HEY calendar, even though I’ve mostly been working on the ONCE side of the product fence for a while, I couldn’t just sit over there and like, wait, oh, looks good, have fun. I mean the Apple thing added a fair amount of complication to it and I got drawn into that, but even if that hadn’t been the case, a launch for a company of our size is always going to be sort of an all encompassing event and we had put both of these expectations a little bit on top of each other. And then the other part was that one actually influenced the other. So already towards the end of the year we were starting to get excited about this PWA concept, progressive web applications. We were not going to build native applications for ONCE.

(00:04:39): First that started out actually being, do you know what? Our native teams are fully engaged with, HEY calendar. HEY calendar is the most important thing we’re working on right now. We can’t also do native app for ONCE. Then it turned into a little bit of, you know what, this is actually a little bit of a feature. Once it’s an installable product, you install by yourself, if we have to have native applications, we have to also run servers, which kind of becomes a service then. The whole point of ONCE is that there’s no service. This is a set of products. You install 'em yourself, you operate them yourself. This is why I think people will be pleasantly surprised when we announce pricing, that it’s not as high as I think most people think because we’re conceiving of this as products, as boxes on a shelf. You take it off the shelf and it’s mainly on you.

(00:05:22): There’ll be a 1-800 number. I mean, not really, it’s an email, but imagine a 1-800 number at the back of some envelope. How many times did you call Sony when you bought a Walkman? I don’t know anyone who ever called Sony about buying a Walkman because that was a product and you were just like, that’s on you and you got to do it. So all of these things came together and then of course the accelerant with Apple being just absolutely vindictive, S.O.B.s when it came to our own native apps and now this Epic games verdict just really lit a fire under the intention pushing PWAs as far as we could. So it kind of raised the quality bar we were trying to hit a bit. That we thought at first, you know what? Let’s just push this out. It’s going to be fine.

(00:06:06): And now we’re like, yeah, we’d like it to be a little better than fine. We’d like it to be quite good, the PWA story, because we have to shine a light on an alternative path for all this app store gatekeeper nonsense. And no PWAs are not going to be as good in all the ways, but I also don’t feel like they’ve fully gotten a shot PWA as a concept. This idea that we could just use web apps, especially on mobile. That’s really where the whole question is, that that feels unresolved even though the term has been around for five years because it wasn’t mainstream viable before. Now we have Apple actually supporting PWAs. I mean trying to deduce like why and how much and what they’ll change to the future, you can go crazy. But you can also just accept what’s there Right now you can do a web app that you can install on your phone.

(00:06:57): It gets pushed notifications and it’s actually kind of quite good. Perfect? No, just as good as peak fidelity on a native app? No, but for a lot of apps, including this Campfire product, it’s quite good and we’d like to put our best foot forward when it comes to this. We’re also trying to validate a category on two different levels. There’s the PWAs, want to validate that that’s a viable path and hopefully inspire others to invest in optimizing that as much as we can. And then we are also trying to validate this idea of installable commercial software. Again, that used to be a thing 20 years ago, you’d buy a CD, whatever, you’d set it up on your own machine. Then it fell out of favor because of SaaS, although it kind of continued all alongside, what is it half of the internet runs on WordPress. Every one of those installations was an installable app kind of thing, but that’s open source. We’re trying to do commercial software in this form. So yeah, we just took a little longer to get it just right and I think we’re almost there.

Kimberly (00:08:04): Okay. Let me ask a quick question and then also if you guys have questions, put them in the chat. I can see them. I will make sure that we get Jason and David to answer them. David and Jason, tell us with the ONCE product you said we’re starting with Campfire, why do you guys pick that one as the first one to start with?

Jason (00:08:17): So one of the premises behind ONCE is that besides it being Installable software and not subscription based, is to look at categories of products that exist, that are widely adopted that everybody already knows how to use but are still being priced like luxury items. And group chat is something that has permeated pretty much every business and every organization. Some of these tools do some more things, but fundamentally the core of it is like I need to talk to my coworkers in real time by chatting. And the thing is that this has been around now for 15 years. Well actually longer if go back to IRC or whatever, but it’s been around for a long time yet it’s still priced as if it’s brand new. And so we asked, in fact on Twitter, how much did you pay for Slack? And the bills that were coming back were thousands a month, some people, tens of thousands a month even just hundreds a month, even 800 a month.

(00:09:13): And we’re like, that’s just obscene. It’s obscene to spend that kind of money on essentially a tool to chat with your coworkers when things like WhatsApp or Signal are free. What is it about Slack or teams that makes it worth thousands a month? So we’re like, okay, we know how to build this. We actually built this way back in 2006. It was actually called Campfire originally. We know how to make a simple thing. We have it already in Basecamp. This would be a perfect category where we don’t have to explain how to use it. It’s a known entity. You can actually build a UI with almost no words in it. It’s that clear. It’s like transcript box, the bottom where you type list of rooms or channels on the side, very well known, and we can price this and it can be hosted on someone else’s box. It doesn’t need to require email or any complicated interactions with outside systems wssentially. It’s very self-contained and it can be radically cheaper and just as good at the 80% level. So we’re not going to have video conferencing in it. It’s not going to have audio conferencing in it for V one or any of that stuff. It’s just basic, simple group chat, but it just felt like the right thing to do, the right category to start and the right place to prove this idea. And so that’s essentially why we chose that.

David (00:10:27): There’s just so many angles of this too that are exciting to me. Not only this idea that we’re taking something old that was good, like the installable software and we’re bringing it into the present. I was going to say the future, but it really is the present. The fact that the fundamentals have changed. There’s a reason why everyone moved to SaaS in the early mid two thousands because it was such a pain in the ass to install an update and keep things in sync if you were running your own servers, that was just very poor ergonomics. Now, the fundamental underlying technologies have improved leaps and bounds. This whole thing of containerization where you can take an entire system, not just a piece of software, but the entire system, put it in a box that is a turnkey, that you just turn the thing on and then it just runs as it was designed.

(00:11:16): It’s very different from how it used to be to distribute server-based software. You’d have to worry about what machine are you installing it on? Did you have the right things? Can you get it wedged? Can you get it out of shape? All of those questions have largely been solved. It’s one of those things though that the fundamental improvement or advancement with containerizations, I mean at this point it’s like whatever, 10 years old, but we haven’t fully digested what the possibilities are, and I just find those things so fascinating where you have a fundamental technology that is done, but people haven’t still caught up with what does that make possible? So this makes it possible to distribute these installable apps without having to have service calls, without having to send someone out and look at your server, without having to get access to your server. All these things that used to be true if you wanted to distribute that kind of software, boom, gone.

(00:12:09): So the compression or the complexity has just been compressed down to a thin sliver and we just add our little special sauce on top to make it even easier. In fact, I’m about to record a install video. We just went it through on a walkthrough, Jason, I and a couple people from the team yesterday. What does it take to set up this kind of installable software on your own host? We just used Digital Ocean. I’ve been testing with Hetzner. If you use any of those cloud VMs, you can do the same thing on your own server. If you have an actual office, I would totally recommend that someone just put a little box in the corner and you can run chat on your internal network. But it’s so easy to set up. It’s literally you turn on a fresh box, you paste in one command and it’s going to run through its things and you’re up and running with auto update and all these other things.

(00:12:59): So just a lot of technology enabling things. It’s not about the technology. I don’t think there’s a lot of people who will actually care. Oh, it runs Docker underneath. Yeah, whatever. Can I do the chat thing? Can you save me like $10,000 a month on this thing? Can we own the data? This is something that’s also huge. I mean, I just spent three years in Copenhagen living there and the way the GDPR, this privacy framework has just infiltrated in some senses, good in other senses, I don’t know about that, but infiltrated European business mentality, how do you store data? Where can you keep it? I think these kinds of software is just tailor made for the moment. I can imagine a Danish public school installing this Campfire tool and running it like that. Inconceivable that they would at this point in the gdp R’S advancement would use a tool from us as a SaaS product as an American company. So I just find that just really exciting. But I think what’s important to say here is all this is speculative. Jason and I are so excited about the new product category. We want to push it out there. We’ve thought a lot about it. We put our hearts, sweat and soul into it, but until people actually buy, we don’t know what we got.

Jason (00:14:19): Actually, I see some things from, I want to respond to a couple quick things before we move on. So Justin is asking, will we eat our own dog food with once Chat? You already use chat basically. So we’ve converted the entire company over to using Campfire Chat for now, and so we’re not really chatting in Basecamp, we’re chatting in this. You have to dog food your own product, you have to use your own thing as you’re building it to really start to understand what it’s missing, what it’s good at, what it’s not. So we’ve been doing that. And also it says that you’re surprised to see that we’re doing chat considering we’ve been semi anti chat or many years. We’re not against chat. We’re against chat as a primary method of communication. It’s a terrible default method for all communication across the company. And so most companies who’ve switched to something like Slack all in or teams, like it sucks.

(00:15:08): You’re bombarded with notifications all day. You’re bouncing between dozens of different channels. It’s chaotic. We don’t support that at all, but as a tool, it’s a good thing to have In the tool belt. We do go to chat when we need to discuss something or hash something out real time. It’s very good for social interactions and just kind of screwing around, shooting the shit kind of thing. And it’s also really nice for really small teams occasionally to make some quick progress. So it’s a tool, just like in Basecamp, it’s one of eight different tools we offer within a project. It’s not the primary method. So we primarily talk long form, but we do go to chat occasionally. So part of what’s interesting about this whole thing is that while this is technically could be a Slack replacement for many companies, I actually see it as also sort of Slack adjacent or team adjacent.

(00:15:55): You can imagine many of the people in the company still using Slack, but you set up a separate corner for just the executive team or just a smaller team who wants to keep things completely separate, a separate space, a private meeting room that’s really truly private and that only six people have been invited to this thing. It’s so low cost that it’s like a no-brainer to have also. So this idea of “also software” that you already have something primarily for this, but you want another similar version also for a different use case. The other thing is that we are giving the code away. So not only do you get this thing, but you get to see how this product was built all the way through, which is something you never, ever get with commercial software. So you might just buy it simply because you’re curious about how it was built, how a team like us put this product together and again, the price is going to be, it’s less than a conference ticket in most cases. So it becomes another no-brainer purchase to learn and to have a team dissect this stuff and look through it. So anyway, that’s just a couple quick things I wanted to get to.

Kimberly (00:16:56): On that note, Kevin asked, who do you see as the target demo initially for Campfire? You’ve talked about that a little bit, but maybe Jason, who isn’t the target audience for this new product?

Jason (00:17:05): I would say this is a really interesting open question to be honest. I’m not really entirely sure who’s going to, is it a company size? Is it a type of company? There is some basic technical knowledge required, very low, but some to kind of get this going. If you’re using Slack and it’s free, why would you pay for anything at all? There’s some of that, but I think that there’s a couple things. There’s a privacy aspect of it. There’s a controlling your own data aspect of it. There’s just the ability to look at the product all the way through and know exactly what it’s doing, knowing that your data’s not being sent to someone else’s servers and someone else’s location. There’s the ability to potentially customize this because you get the code and you can mess around with it to some degree. There’s this idea of having a separate segregated place for certain discussions that are separate from the rest.

(00:17:55): Companies do this all the time. They have file system and there’s only certain people have certain access to a specific folder, and of course you can do that in other tools, but to actually thoroughly separate them is even safer. But I think we’re going to see a lot of mid-size companies jump into this. I think we’re going to see a lot of small teams who are product development teams who are curious about how this works buy this. I think we’re going to see a lot of large companies like what they do with Basecamp. The whole company doesn’t use it, but a team within it uses it. They want their own thing, they want their own place, they want their own rules that they want to set up. So I think we’ll see it in a lot of different places and I think ultimately if we can get the pricing right in other markets, we’re going to see this adopted all over the world in markets where typical SaaS software is way too expensive to get going. So what we’ll have to see, I’m very curious. Typically, to be honest, we don’t think about market so much ahead of time for anything we build. We think what do we want to make for ourselves and let’s put it out there and then we’ll find out what the market has to say about it.

Kimberly (00:18:58): And with Campfire, everyone’s loading it themselves using their own servers. This kind of answers Chris’s questions. Maybe you guys can address that. Will Campfire have a mechanism for preserving messages for legal purposes? We don’t have the data.

David (00:19:10): In the sense that you have the data, you have the database, the system is built for you to be able to take backups of that database. There are no sort of enterprise retention controls in the traditional sense that you would with a Slack or something. But in some ways it’s not needed in the same way because it’s literally your installation. It’s literally running on your stuff. Either your physical server or a cloud VM that you control. You have direct access to the database. We built a really nice system in where you can take backups of not just the database but all the files that’s been uploaded. So say for example, you have a preservation request, you’re in a lawsuit and they say, Hey, you can’t anything in the past three months, you got to just store, right? You could do it at backup. You take that backup and put it somewhere safe, just that you’re in compliance with that subpoena or whatever it is.

(00:20:03): So yeah, I think in that sense it’s quite well set up, but it’s not the same way. You really have to shift your mindset a little bit when you go from multi-tenancy, which is what systems like Slack and Basecamp is when someone else runs on your behalf. So single tenancy where you own the whole thing, you’re not renting, you’re buying a product here and it’s yours. This is the other thing here. We’re not making a license agreement with you that we can revoke your right to run the software. There’s a license agreement on what you can do with the code. It’s still copyrighted. We trademark the name and so on. You can’t just buy our code and then give it away for free or distribute it or whatever, but it’s yours to run the way you see fit. You don’t have to get any of our updates.

(00:20:47): You can buy Campfire once, continue to run it on your service as you please and you can run it in the next thousand years. I mean, I’m making a sort of broad proclamation here, but the software years, the software is open source, I guarantee, well, I shouldn’t say guarantee, you who knows civilizations around in a few hundred years, but if it is, if civilization is still around, there will be people who are capable of running this, which is absolutely not true for commercial SaaS companies like Slack or even Basecamp, right? You can’t make declarations about whether this is going to be around in a hundred years or 200 years. Now, is this actually a practical concern? I dunno, not so much, but there’s a philosophical attraction to this that really appeals to me. One of the reason it does is because I’ve gotten really into retro gaming. There’s these emulators that allow me to play the video games I first played when I was like five years old.

(00:21:42): It’s incredible. You can emulate a Commodore 64, which was the first computer I really had exposure to all those games on a modern sort of handheld gaming device where you’re actually playing that real software. That to me is magic. We have a history here of computers and software that we should be cherishing, and I do worry a little bit that the SaaSification of everything destroys that. This is one of the other reasons I’m so thrilled that we still run silly things like Tada List, this free service we made 18 years ago because it’s trying to give friends to this idea that software should have a legacy and a history. All the major material things that I truly enjoy, whether it’s watches or cars or cameras, they all have these long legacies and you can take a watch. Actually, this is a watch from I think 1968. It’s from before I was born. I can wear it on my wrist and it tells time. That’s amazing. Software should be more like that and I think with this kind of software we’re trying to put our chips in and say like, all right, it’s going to be that. And I think that’s just, that’s just fun.

Kimberly (00:22:56): Okay, I want to go…

Jason (00:22:58): Can you address… I’m sorry, Kimberly, go ahead.

Kimberly (00:22:59): No, no, no. I was going to go to Shape Up, so if you want to stay on the ONCE train…

Jason (00:23:02): Let’s do one more thing about ONCE first before we’ll jump to Shape Up. I saw, David, this is really more of a question for you. It says, if you’re giving the code away, does that make it open source? Can people modify it? How are we thinking about allowing people to mess with the code and see the code?

David (00:23:15): Yeah, this is where I think the parallels are so great to physical stuff. So this watch or you take a camera M3 or you take a Corvette from 1968, those are your things. Like I didn’t sign a end user agreement with Rolex or General Motors or Leica to be able to own those things and do whatever the hell I please with those things. Now the question is whether you can. If you buy a mechanical watch from the sixties, do you know what? You can take it to any independent service provider. They may be good, they may be bad, but they can work on it. They can open the case and they can rinse it out and clean it out, whatever. You can take your Leica M3 to an independent shop and they can fix it. You can take your car if you’re good enough, interested enough in this, you can learn it yourself.

(00:24:04): You can change the, I dunno, carburetor, battery, whatever. Do you know what you can’t do if you buy a goddamn Tesla? Do anything. Now, I love Tesla, so I’m not taking a dig at 'em here. I’m saying there’s been a shift here where everything has become software and all softwares become closed when it comes to commercial systems. So this is not that. This is a Mustang '68 that you can buy and if you can teach yourself how to operate it and maintain it and change it, you can. You can install a different stock and do all those things. That’s not the same as open source as people traditionally understand it. People understand open source in the same way we give away Ruby on rails. You can distribute it, you can build it into something else, you can build a product with it, you can sell that product.

(00:24:49): There’s a lot of rights that come with that kind of open source. We’re keeping some of those rights. So this is somewhere in the in-between land. This is commercial software. Source code is trademarked, sorry, copyrighted. You can’t just take it and distribute it. Just like you can’t just buy a book, take photocopies of all the pages and then hand that book to someone else. Now, do you know what? We have some limitations here to ensure that commerce endures, but you can still get into the machine room. You can change it, you can adapt it, modify it, do whatever the hell you want. And I think that’s what, it really is an intersection of two things I care about. I care about commercially viable software where companies can actually make profits and pay employees and all those other things. And then I also care about open source, and this exists somewhere, I don’t know, in the middle.

Jason (00:25:40): Sorry, Kimberly.

Kimberly (00:25:41): No, no, no.

Jason (00:25:42): There’s a couple… Some people are asking about one stuff, since we’re on the topic, lemme just knock out couple quick ones. Nick, what are the economics? How are you going to charge for it? Again, if you’re going to update it, whatever. So basically it’s going to work like traditional software has always worked, every major version. So if you have 1.0 and 1.1 and 1.2 and 1.3, these are all included for free updates. If we ever launch a 2.0 or a massive redo or a massive upgrade, we’ll sell that again as an optional upgrade. That’s how that’ll work. Also secure, we’re going to do what I think it’s we’re going to guarantee three years of security updates regardless of what version you’re on. So we’ll do that…

David (00:26:20): Jason, lemme just make one point on that because I’ve gotten some feedback on that too. Oh, okay, so if I install my own software, how am I even going to get updates? We built all that in, so actually this is something we did recently. When we started out, it was like a manual process. If you wanted to get an update, you’d go in and update yourself. Now we build an auto updater, which is not something new. Your Mac has an auto updater, it’s not SaaS. Your Mac is not SaaS. It’ll pull an update from Apple or your computer will ask once a day, oh, Apple, is there any new updates here? We’ve done the same thing. So when you install this Campfire through the ONCE command, it’ll set up an auto update or every night, I think it’s at 2:00 AM in the morning, the system will ask our service, Hey, is there any update? And it’ll auto apply. You can turn that off. Not everyone wants auto updates, but if you want the auto updates, it’s going to be on by default and it’s going to be super duper easy.

Kimberly (00:27:09): Okay, another ONCE question. Will you try to have similar products of ONCE products play together? Are they completely separate or are they going to…

Jason (00:27:16): Don’t know, don’t care, not thinking about that right now. Yeah, there’s a lot of, I saw some other questions about,

Kimberly (00:27:21): Sorry, Sebastian.

Jason (00:27:22): It’ll not do so many things. It’ll not do almost everything. It’ll just do a few things. Each one of these tools will do a few things really well. What we’re really aiming for here are high quality generics. If you think about what is the canonical version of a group chat, it’s a transcript, it’s a place to talk, it’s a list of rooms, maybe some direct messages. It’s like that. That is what this is. It is not more than that. It’s not more sophisticated than that intentionally. This is the core nugget. The 80 or maybe 90% of what these tools really stand for, and then all the other stuff around it is not part of it. So these are radically simplified, straightforward versions of popular product categories that we’ve just stripped down and that’s why they’re just, let’s call it a few hundred bucks, once.

David (00:28:16): I think this is one of the things Jason and I were talking about yesterday. I’ve been so excited about the prospect, the new distribution forms, everything we’re bringing back, and I mean I think it’s fair to say we’ve been hyping that. I mean, I’ve certainly been hyping that and we need to sort of peg down the expectations like two levels from what is the actual software underneath, because if you have the expectation that this is exactly the same as Slack with all the features, belts and whistles that Slack does just massively cheaper and you get to own it and we build it all in the amount of time we did. I mean, I’m sorry, but that’s delusional. That’s just not how things work. You can’t get all of it plus 500 times extra. So this is how it always is when we make new products, when HEY email launched, it included a ton of really novel interesting things and then there was a bunch of baseline stuff that wasn’t there on day one. Now some of that baseline stuff still isn’t there. We’ve covered the majority of it, but some of it isn’t there. We’re not trying to replicate every single thing that Gmail does. I think there’s like 500 different items or configuration points and Slack has grown into a Gmail like Monster in that regard too. Jason and I, a few weeks back went through the signup process with Slack and like, holy shit, I don’t remember it just being (explosion sound effect)

(00:29:31): This much stuff and you can tell me, I mean that’s not a critique per se. Every single little checkbox that it has in its 500 million configuration screens is there because it helped make a sale to some enterprise organization somewhere. That’s their business model. Totally fine, great. Actually that should exist. It should be good. We’re making something else. And I think it connects to this idea of that watch I held up 1968. To have something endure for not just two years, but 10 years or 50 years, you actually kind of want it simple. I think that’s the recipe behind the magic of a Leica camera from 1954 that still works. Like a Corvette from '68. You can still make run because they’re actually quite simple products. A do not think that my Tesla model S is going to run in 50 years. That’s just unlikely. They’re so highly complicated systems built with computers and software that it just seems like, you know what? This is a more of a disposable item and again, that doesn’t mean it’s bad. It means it’s actually good for a lot of things and we get a lot of progress out of that. But it also means there should exist a category of software that’s not, that is more like trying to be a likem three more, trying to be a '68 Corvette, more like a Rolex GMT from '72. We’re trying to make that.

Kimberly (00:30:55): Okay, last ONCE question before we go to Shape Up.

Jason (00:30:58): Doubt it. I don’t believe it.

Kimberly (00:30:59): This one is how do you distinguish products suitable and not suitable for the ONCE model? That’s from Nick who’s live with us.

Jason (00:31:06): The way I think about it is can you boil this down to a few things and be done? For example, people have been asking for, can we do a CRM of ONCE? A CRM? I’m not so sure because CRM requires a lot of integrations with email and some other sophisticated external systems, and there’s a lot to that that is not as simple as literally group chat. It’s obscene that anyone pays more than 50 bucks a month for group, it’s just obscene. It’s a transcript and a box where you type. That is all it is. That is it. I know there’s other things it does like threading. Yeah, yeah, yeah. You don’t need any of that. You don’t, and it’s just like can we find ideas and we have a handful of them that are so simple in their concept, conceptually simple that we can deliver a very high quality simplified version.

(00:32:01): Another example of this, which we might do next, I don’t know, is Kanban. The concept of Kanban columns and tickets and moving tickets between columns. That is 99% of what Kanban is. Simple, conceptually simple. You can squint and draw it and cover all the bases. I think this is another way I’ve thought about it. It’s like if I could sketch the UI and cover 95% of the whole product with a single sketch with eight lines, that’s a ONCE product. Kanban is like that. Chat is like that. There’s a number of other things like that. Things that people already know how to use already understand that are simple concepts that you can do on paper. I mean you can make a Kanban board for your office by using this tape on your wall and post-it notes. That’s Kanban, right? You can do that digitally, of course. It doesn’t need to do all the things that something like Trello does and all the other things that other Kanban systems do. What’s the simplest version? Is there one that’s attainable very quickly that we could build in a few months? Absolutely. That’s sort of the bar for us.

David (00:33:07): And I think it’s good to contrast this with what doesn’t fall in that category. For example. Hey is a perfect example. Like hey, is an email service not an email client and running an email service today is actually kind of shockingly depressingly difficult. Ensuring deliverability of email has turned into a freaking PhD project. I mean just even, I’m trying to remember all the standards that you have to keep in your head, D cam, this and SE, I can’t even keep it in my head on a operating basis. That’s how complicated it’s, it’s not a good system to try to run yourself. It used to be I used to run my own mail server back in the late nineties I think it was. I’d run my own mail server. Lots of people did, but today you really have to be a very dedicated hobbyist to attempt running your own email service if you care whether your emails reach the recipients.

(00:34:05): So that’s the kind of service that I think, in the word actually, service. Anything that’s a service where someone has to tend to the operations of this thing on a running ongoing basis, otherwise it falls apart. It’s a poor fit for this. Now there are people who tried, I actually bought a physical product, I forget what it was called, but someone did a physical product that was a mail server in a box and it was complicated. It was not a single sketch. It was not actually easy to set up even though it actually came as a physical thing. So I don’t think this is a good fit for it, and that’s the other important part of this. When we talk about ONCE, we’re not saying all SaaS needs to go away. Every SaaS product needs to be a installable product. That is unrealistic and in fact bad. There are lots of services that are best as services. Email is a great example of that. Anything that requires a bunch of integrations or updates or continuous refinement doesn’t really fit this model all that well.

Kimberly (00:35:04): I love that we’re recording this live so you guys can actually see what happens. It’s me just trying to not interrupt them, basically, is how it goes.

Jason (00:35:11): No, your turn.

Kimberly (00:35:12): No, quick. Here’s a question that I actually a little off subject, but I thought was a great one. Jason, you used to do lots of customer support work, which would’ve helped you stay in the loop with existing and new customers. Now that you delegate the work, how do you maintain your customer muscles?

Jason (00:35:26): I’m a little bit more involved in new product development than maintaining existing products these days. So because there are no customers for new products that we don’t have yet, it’s a little bit different. It’s more about gut intuition, what do we want to build for ourselves? But we have someone named Brian, for example. Brian’s sort of our head of strategy. He’s sort of keeping track of all the things that are on customer’s minds. He’s doing a lot of the shaping work for Basecamp and continuing to improve Basecamp, so he’s very much in touch and in the weeds there. And if I was doing that then I’d be in the weeds there as well. But since I’m more on the leading edge of things that we’re doing right now, like the HEY calendar, of course we had some requests for calendar in HEY, but the thing we built was not what people told us to build. That’s sort of my focus. So it’s a little bit different these days.

David (00:36:14): Although I will say that when we do launch a new product as we just did, we step into the river of customer feedback. I mean both Jason and I have fielded absolutely hundreds of emails from customers giving us feedback on HEY calendar and whether that feature request a bug reports or what they’d like to see or just appreciation for the fact that they found the product so likable, all that stuff. We get the fire hose sort of occasionally, but yeah, I think at some point I think we get, I mean many hundreds of emails a day on customer support. Gone are the day where Jason could just answer them all by himself, which he did and I think the first three years almost, I think at peak Jason was doing a 160 emails a day on customer support while also running everything else. And just for sense of scale, what we asked or what we benchmark our customer support team is 50 to 60 tickets a day. So Jason was working three customer support jobs while also being CEO and running things in the early days. Yeah, good times. And we walked, by the way, uphill both directions and it was always snowing and we were bare feet.

Jason (00:37:23): I had a snow machine indoors just to make sure. But the thing is, and I would recommend every founder or whatever or anyone making something new for the first time does that. You must do that. You want to step into the fire hose, but after you launch the thing, so I would not go ask people what they want, I would build something, then you put it out there, then you step into the fire hose and you learn. There’s no better way to learn than that. Alright.

Kimberly (00:37:50): Okay. I’ve been saying ShapeUp for a while now because some people mentioned it on Twitter and then Parker, I do see you. I haven’t forgotten about you. The question is can you explain use of ShapeUp when building new product lines?

Jason (00:38:04): Yeah, so I was just on a podcast Hackers Incorporated with Adam Watham yesterday, two days ago. I don’t when that launched. And he asked me about how we built HEY calendar and I talked all about it and then there was this one part in there where I’m like, well, we don’t really follow all the traditional Shape Up methodologies when building a new product. And that caught a few people’s eyes or attention. They’re like, gotcha, gotcha. I knew you guys didn’t use Shape Up. I know you invented it but you don’t use it. It’s like we do use it. What we’ve discovered though and is a constant process of discovery and evolution, this whole system evolved over 20 years. Cycles, which are now six weeks, used to be three months and before that we didn’t have cycles. So this is an evolution. Any product or any process that’s stuck is dead. Like Latin as a language is dead because it doesn’t change.

(00:38:54): Things that don’t change are dead. This process continues to change. What we’ve discovered is that for new product development, while we stack up work back to back to back to back like you would in a cycle, the cycles are a little bit more fluid to some degree. We don’t shape everything ahead of time. Some stuff that’s especially small is just sort of done on the fly, but what we don’t do is we don’t let things take as long as they want. So that’s also consistent with ShapeUp. ShapeUp has an appetite maximum six weeks. We’re not working on one feature for eight months this way either. There are limits. We don’t have cool downs typically during the new product development process where we do with existing product development. So typically we do six weeks and then a two week cool down and then six weeks, that’s what we do on existing products for this we go back to back to back to back to back.

(00:39:44): It’s a little bit more of a constant jog without rest. We’re not sprinting. You can’t do that for months and months and months. But we do that maybe a little bit more towards the end, but it’s a little bit more chaotic, a little bit more on the fly, a little bit more feeling things out because we’re going to be using this thing as we’re building it. We don’t really know what we’re making yet. And you can’t be so rigid ahead of time to know what you’re going to do over the next year when you’re exploring something new. But there are time boxes, there are limits, there is this urgency not to spend too much time on something. We want to make the thing that we’re using and we want to move on from things. We want to finish things up and move on. Sometimes you leave something sort of half done, you’re going to get back to it, but you also know you got to move things on. So it’s an evolution, it’s a different context, it’s a slightly different variation and we should update the book and update the website and talk more about our latest discoveries and how to pull this off for new product development.

David (00:40:37): I think one thing I’ve realized is that where ShapeUp really helps us at this stage of the company is it allows a delegation of decision-making power on an interval where Jason and I don’t have to be involved on like a day-to-day or weekly basis. So with Brian for example, shaping most of the pitches, taking a lot of input from customers and feedback, what we otherwise want to do, he can go off and do that work for several weeks, maybe he’ll sort of spar with Jason a couple of times. And then every cycle we can look at what’s on the menu. And when you look at it in that way, you end up with a certain courseness in your decision making power. We cannot make decisions in that forum on an hour by hour basis or even a day by day basis. The minimum block we can actually operate with is a week, and more likely it’s two weeks. Most projects that get shaped have a two-week block.

(00:41:33): That’s fine. When you’re evolving an existing product and you can set a couple of things to go. When you’re doing RD, that’s inherently explorative. You don’t even know what you want to build, right? You don’t know exactly the shape of the product itself. You have to be working on a day-to-day basis and the decision making power to change direction should be embedded in the team. So you don’t have this delegation in the same way. With both HEY calendar and with ONCE, Jason and I have been in it him more on the HEY calendar side, at least on the design part of it. And I’ve been on the technical side with ONCE, like really in it all the time, to constantly like, alright, we hit a dead wall here, let’s change direction, let’s go over here. So you’re operating almost like a different scale.

(00:42:19): If you think frog view versus bird side view, the more you get up into the level of, I hate the fucking word, but stakeholders, people who want to see an outcome of something but they’re not involved in the day-to-day of it, ShapeUp becomes more and more important, more and more critical that you have the shaping and you have the repeating ways of doing it. But I’ll be perfectly honest, if I was starting a new company tomorrow and we were four people, we would not use any process barely. I mean we wouldn’t have kickoffs, we wouldn’t have heartbeats because it would be no one to communicate with. The smaller you are and the more isolated that group is from the rest of an organization, the less methodology, the less process you need and the more liberating that is. This is why I think a lot of people, a lot of entrepreneurs look back wistfully on the early days.

(00:43:10): Oh remember when we were just five people? There wasn’t any of the complexity. Yeah, because the scale was so small. It isn’t hard to organize four people. It just isn’t. Organizing a company of whatever, 72, 75, that’s a more difficult problem, let alone organizing a company of a few hundred or a few thousand or tens of thousands, right? They’re just different scales. And if there’s one thing I think we’ve been consistent in saying is you have to pick tools that are appropriate for the scale you’re at. This is why I’m so adamant that microservices is a terrible idea for most small teams because these are techniques built by and formed in huge organizations. What works for Amazon at that level is not what’s going to work for you. So I think ShapeUp has a little bit of the same thing. I don’t actually think most people go looking for ShapeUp until they run into process pains. You’re not going to have process pains with four people. You’re going to have process pains maybe 10, 12. Now you’re going to have to have multiple people and they have to have an eye on five different things. They can’t be involved in everything all the time, ShapeUp steps in. Makes a ton of sense. Do you know how big the ONCE team was? We had, how big was the ONCE team for the longest time? Two developers, one designer, Jason and me. That’s five. You don’t need any process with five people.

Kimberly (00:44:29): Okay. Here’s another ShapeUp question before we move on to just the random questions. How do you handle betting on smaller projects like say three weeks during the six weeks? The engineers focus on two shorter projects rather than a big one? Just a general ShapeUp question for us here.

Jason (00:44:43): So before a cycle starts, we set up the work that we’re going to do and not the tasks but the big ideas and we say we’re going to pick, for this example, I’m going to say we’re going to pick five things to do. Two of these things are going to be full cycle projects. They’re going to take the whole time, they’re bigger things. I’ll give you an example from HEY calendar, if we’re doing this in shape up, habit tracking and time tracking are both full cycle projects. They’re going to take the full six weeks, but there’s a bunch of smaller things that are going to take a week or two to do. And so we set the appetites for each one of these projects and usually we have a team work on a big thing, a teamwork and a big thing. And then one team might work on four smaller things in a given cycle.

(00:45:31): So there’s the small batch team, which we’ll do a bunch of things and the big batch teams which will do one thing and that’s how that comes together. And look, the other important thing here is that this isn’t really, this isn’t, we’re not aiming for rigidity here. There is a framework and a concept that’s supposed to help guide things and prevent the worst parts of human nature from taking hold, just giving things an unlimited amount of time and perfectionism and all that stuff. So there’s discipline here that’s built into the system, but there’s also flexibility. So if someone needs to jump over from one project to another, they need help. Of course. The answer is of course it’s all within reason, but that’s typically how we would assign the work out. And then again, once the work is assigned, the work that’s assigned is the big idea. The actual bits that need to get done are defined by the team doing the work. There’s no architect or task master or scrum master or whatever making all the individual tasks and tickets for each person, the people doing the work, make their own work. That’s how that whole thing works.

David (00:46:33): And I think it’s key here to contrast that with, in my opinion, the ways agile, big A Agile methodologies went astray. They absolutely did try to codify way too many things in too high level of rigidity. Ironically, given the fact that it’s called agile, but everything’s called agile this day, no one is going to say, oh, I’m not agile, right? Everyone say they’re agile about something and then oftentimes they present a very rigid definition of what that agility actually looks like. And it’s far away from the agile manifesto, which was this idea of it’s still online if you Google Agile manifesto, you can see these ideas that people or processes for example, if something’s going to bend or give, we’re going to give it to people. We’re not going to stay rigid in the process. And this is where the context setting is so important that you can’t just take even ShapeUp, I don’t think you can’t just apply shape up as a whole to an entire organization of a hundred thousand people without making serious modifications.

(00:47:35): I also don’t think you can apply it as we wrote the original book to a team of four people. It fits somewhere within the processes starting to hurt. And we’re not a mega company yet. So I don’t know if I was going to say something, I’d say from 10 people to maybe 500, something in there is the sweet spot for it. The further you get away from that, either on the small side or on the big side, you’re going to have to make modifications, you’re going to have to make changes to it. And that should not be seen as a refutation of the ideas that are in there. You could totally take a concept of, for example, budgets over estimates. I think that is a universally applicable concept that goes directly to Jason says like the worst parts of human nature. If you go with estimates, humans suck at estimation. Even if they’re four people, they will still suck at estimation. So you could take that idea and go like, yeah, you know what? We’re going to apply that here. We’re going to set up some appetites. We’re going to do that. We’re not going to have the whole thing. We’re not going to do the formal pitches and they’re not going to be at that level. But we’re going to think about estimates.

Kimberly (00:48:37): Okay, I’m going to move on to this question about new products from Julian. When you start something new, how much time do you spend on it before saying it’s a good idea or not?

Jason (00:48:47): So if we’re talking about a brand new product, typically it depends, I guess. For example, this ONCE Campfire, we’ve already built chat a few times, so we kind of knew what this was going to be. But let’s say that the HEY calendar, let’s take that as a, I always want to get practical. So by the way, if we’re talking too high level, tell us in the chat. I want to get practical and real. Okay, so HEY Calendar, we spent a few months, typically no more than a couple months max exploring in the early days. Is there something here? We knew we were going to build a calendar. We decided we were going to do that, but what was it going to look like? Well, it wasn’t going to look like a traditional calendar, but what does that mean? So there could be a million other ways to do it.

(00:49:32): So we spent a couple months playing. It’s really play. And then at some point, I think it was early March, basically we started this, I think in January, I dunno, something like that. Early March we’re like, okay, we kind of have a direction here. This doesn’t mean everything’s finalized, basically nothing’s finalized. But we’ve landed on a few interesting ideas that form enough of a foundation from which we can then build the walls and build the roof and build another layer and all the whole thing. So I’d say a couple months of exploration and play before settling in. If you’re spending more time than that, granted, look, there’s always exceptions if you’re building an electric car from scratch and whenever had done that before for example, you’re spend more than a few months. Software conceptually, a couple months should get you far enough to go, there’s something here or there’s something not. That’s kind of how we basically do it because otherwise you will keep going. And if you feel like you need to explore every possible avenue before you decide to commit to something, you’re never going to this thing done. So you’ve got to go on faith at some point after you’ve determined that there’s enough of a foundation here on which to build future things.

Kimberly (00:50:39): Okay. I’m going to go to a question that came earlier from Victor, which is would your business structure be any different if you guys made products that you didn’t use internally? We’ve talked about it all the time. We are our customers. We use Basecamp, we use, Hey, would the business look different if that wasn’t the case?

Jason (00:50:55): I wouldn’t be here. I don’t know. I’m not interested in building products for imaginary people and to be honest, I know it sounds really, I dunno what it sounds like, but I don’t mean it in a negative way really. It just means I don’t want to imagine someone else’s problems. I’ve got my own problems. It’s hard enough for me to understand my own problems. I’d rather solve my own problems that I’m close to, that I can really understand if this is a solution or not. I know what my own struggles truly are. I can decide to build something and if the struggle goes away, we’ve nailed it. At some level, once you’ve got something out there in the world, you do build for other people. But initially we build for us. So for example, there is no amount of money someone could pay us right now to build patient scheduling software for a dental practice.

(00:51:44): It’s just not going to happen. We don’t care. You can pay us a billion dollars. I just don’t care. Not going to do it, not worth doing. So we’re going to find things that we know how to do that we struggle with, that we want, and that’s the kind of business we build. I think if you build another kind of business where you’re doing things and you’re imagining other people’s struggles and doing it for other people, you don’t really know where to stop. You’re probably going to have a lot of salespeople because you’re going to need to sell this thing. You can’t just make something that’s going to be really good on its own and it just doesn’t sound interesting to me. I’m not really interested in spending my time. I like to make tools that I’m going to use. So that’s my missive on that.

David (00:52:23): I’m completely on board with that too. You could not motivate me. It’s not even that you couldn’t pay me, you could not motivate me to do that. And I just know this is one of the reasons I was such a terrible employee because whenever I had to work on something for other people that I didn’t care about, I literally could not make myself do it. So there’s that. And then the other part is, holy shit, I’m glad not everyone feels this way. We need someone to make the dental practice booking software, and this is where Jason and I are these oddities and we’re all odd and weird in our own different ways. We just have accepted our own oddities and built a business to facilitate those oddities not getting terribly in the way. But we need other people to do this. Jason and I, terrible folks to ask for advice on that because we literally could not even motivate ourselves to barely think about it. You need to talk to someone who’ve done that, who built software for other people. And there are lots of people who do this and many of them do it well, and I have tremendous respect for the fact that they are able do this and I think the world is a better place because they do it. Not Jason and I.

Jason (00:53:30): Can I take Eric? Eric and Ilan both have a similar question.

Kimberly (00:53:34): That’s what I was going to cue up for you. So you’re good. It’s a pricing question.

Jason (00:53:37): So let’s talk about pricing because we’ve long had a policy that we don’t increase prices on existing customers. And in fact, for the past 10 plus years, we’ve changed prices a bunch only on new customers. So we have a new pricing model we experiment with. We put that on the website, anyone signing up, we’ll pay the new price. Existing customers continue to pay their old price. And we’ve done this for basically the entire existence of the company. Early on we had a little bit of price changes with couple different products, but it’s been a long time. In fact, some customers that we still have, we’ve had for 20 years, they’re still paying the exact same price they paid 20 years ago. However, just recently, we’ve decided that it’s finally time. Our costs have gone up as everyone’s costs have gone up and we’ve instituted a price increase on some legacy products, some existing products.

(00:54:31): It’s about 20% roughly, give or take on existing customers. We’ve given them about 90 days notice and the existing prices on the current site will not change moving forward, but we are bringing people a bit more up to date. Basically, our cost structure has just changed. We have a lot more employees than we used to have. We’ve saved a lot of money in the cloud, but our payroll has gone up significantly. As everyone knows, payrolls have gone up significantly for a variety of reasons. There’s inflation, there’s a whole bunch of other things. Costs are up. And at some point in order to maintain the kind of business we want to run, we have to pass some of that on. So we decided again after a long, long period of time that over 20 years or 10 to 20 years only to raise prices once about 20% seemed very fair, very reasonable and necessary for us to continue the business the way we want to run it. So that’s how we did that.

David (00:55:24): What to me is kind of fun to look back upon is, so we launched Basecamp 2004, we still had some customers paying essentially those 2004 prices, right? In 2004, we were paying developers including myself and I think Jason as well. I think it was 42 or $45,000 a year. That was the salaries, right? Do you know how much programmer you get these days for 42,000? You don’t get a whole person. You get some slice of a person somewhere. I don’t know if you want to leg or you want to hit or an arm, you’re not going to get a whole programmer, at least not at the cost basis that we’re looking at in our jurisdictions if you want to call it that. So if you compare that, what is the average salary for Silicon Valley type levels, it’s not 20% that’s gone up since 2004.

(00:56:14): It’s many times that, right? So at some point it just seems like out of sync because to maintain those legacy products, actually, sorry, lemme restate. To maintain those legacy services, that’s the key point here. We need to continue to pay talented people to work on it. That’s to make sure that those things are updated is that they’re still running or everything that goes into offering a service sort of requires human input. And that is the biggest cost that we have in our company. So even for example, as Jason said, we’ve saved some money on the cloud, very happy about that. In the grand scheme of payroll, it’s substantial, but payroll is so much larger than whatever those savings were. So I also think it’s just one of those things where I hate getting the drip drip. So I use ADT for my security system, whatever they freaking send me a, well, our prices have gone up two, three times a year and it’s always like, oh, we’re racing our prices 3.724%.

(00:57:18): And I always go like, that sounds bullshit. If you have that many decimals, something is just fishy here. I’d rather just go like, you know what? We’re going to do it rarely, but then we’re going to do a chunk. 20% first time in 20 years. Do you know what? I don’t find that all reasonably, and it’s so funny. What is reasonable? It’s such an individual conception. And I’ve had the same thing. I just had this thing with Disney plus, so I was on a Disney plus plan that was $99 a year. I don’t know, maybe that was an introductory pricing or whatever. And then I get this email saying, Hey, cool, it’s going to be $139 now, so a 40% increase. And I just went, no. Can I afford $140 for Disney Plus? Yes, I can afford that, but I don’t want to. And I was trying to look at myself in third person, why am I being petty about that increase?

(00:58:11): It just felt like it didn’t feel fair. And I think this is the key aspect of pricing that you should internalize is this sense of fairness. Now you’re not going to make anything fair for everyone. We got some pointed feedback on the 20% people saying that’s not fair, but broadly the feedback was what sounds about right. And I think that’s, you got to know that you’re dealing with human emotions, you’re dealing with a sense of fairness or unfairness. How often can you do this? How much can you do this? And you really have to respect those things or otherwise you could get yourself in trouble. I mean, we rude over this for some time. It wasn’t just like, all right, that’s what it is exactly, because we hadn’t done it for a long time. But I think given the feedback, it seems like it was sort of well received. But proof is always in the pudding. And the pudding is that the price increase will hit the first invoices, I think February 1st. So that’s when we’ll see the moment of truth are people going to pay.

Kimberly (00:59:10): Okay, last question that we’re going to take before we wrap it up. We’ve been with you almost an hour, is about AI. What are your thoughts on generative ai? Any plans for doing something? And this says Basecamp, but for any of our products.

David (00:59:23): I think AI’s the most exciting, interesting development in technology that I’ve probably ever seen. And I include the internet in that, which is saying something. So I’m hugely bullish on the future of ai. I think it’s amazing. At the same time, I don’t feel like I have to be the first in the pool swimming the hardest. Because if you paid any attention to startups doing AI stuff over the last 18 months, you’ve seen that two or three generations have already been steamrolled. You think, oh, I came out with this new idea and then burn the open AI steamroll. It just rolls right over you. You’re no longer a thing. You’re a feature in their setup. And most everyone right now at least, they’re not doing ai, they’re doing API AI. That’s different. You’re not doing fundamental research that’s giving you a lasting advantage here. You’re using the API of OpenAI or some of the other tools, which great.

(01:00:21): I mean, I’m not saying that’s bad. I’m just saying that to me it seems too early. I’m not actually an early adopter or maybe I’m an early adopter. I forget how the chart goes. There’s a segment of people who jump in on something as soon as it comes out. I don’t like to do that. I like to give it five minutes. Can the landscape settle just somewhat? Such that we don’t spend a bunch of time looking into something and then it just goes and then it eats all that work and swallow it up inside the Open AI machine. I don’t want to waste time doing that. I don’t think it’s clear at all where AI is going to land even a year from now. Is AI going to end up in a place where we’re even using graphical interfaces? Is everything just going to be spoken?

(01:01:05): Where is this actually going to be? So I sit with this paradox in my head. I think this is the most exciting thing that’s happening in tech and also I don’t mind being a spectator right now. Now eventually it’ll settle to whatever degree it settles and we’ll go right in on it. We’ve done a handful of experiments internally. The one everyone was excited about for a hot minute was like, oh, can summarize your boring emails. So we tried that and it’s like, yeah, okay, cool. Ish. That’s not the part of generative AI that actually gets me excited is that we take shitty writing and turn it into another shitty version of the writing that doesn’t get me fired up. A lot of the other things do, especially around media. I’m not sure it’s clear where we land yet, but hopefully it will be in whatever a year or hopefully not.

(01:01:56): Maybe this stays exciting for another year or two or three and we just go like, I don’t know what’s happening. Is anyone even going to work tomorrow? Or software developers all out of a job? I think we’ve never had that amount of uncertainty in plain sight. There’s always been uncertainty about what’s new technology going to do, but it always felt like something you had to dig for. Even the internet. I mean both Jason and I were there. '95 when the internet started taking off. And you have to dig, not everyone understood that the internet was going to be what it is. I think everyone understands today that AI is going to be a major shift, but we don’t know exactly what.

Kimberly (01:02:38): Okay, well I think that is a perfect way to end. Before we wrap it up, I have two requests. One, if you were just coming to our YouTube channel for the first time ever, please follow us. That’s 37signals. I know we are putting this live on YouTube, but we have a channel that we have videos that come out all the time, so make sure to give us a like and follow there and let us know in the chat. What was that David?

David (01:03:01): Smash the button. Smash the like button, ring the bell, do on YouTube and then get all the way up on the camera.

Kimberly (01:03:10): You guys know what to do. And my other request in the chat, let us know what you thought of this live. This is the first time we’ve done it. We’ve never done this kind of live situation with Jason and David kind of branding it as rework. So let us know if it’s something that you like and we should do. Again, if I didn’t get to your question, I’m sorry there was a lot going on. We will get to your question hopefully the next time if we do a live session again. You also can email us at rework@37signals.com or you can leave us a voicemail and that’s 708-628-7850. If you want to leave us a voicemail message, we often replay those in the podcast when we get those from listeners. Jason, David, anything else to add before we close it up and get back to work?

Jason (01:03:52): No, I mean we’d like to do these again. This is fun. So yeah, I’m curious to see what people want to know.

David (01:03:58): Thumbs up. Yeah, enjoy the energy of live questions. Yeah, that’s great.

Kimberly (01:04:03): Okay, thanks guys. Thanks for joining us and we will see you soon.

Jason (01:04:07): Thank you.