SEASON 2 - EPISODE 182 - February 4, 2026

Product walkthroughs, the next open source product & other listener questions

A fresh batch of listener questions leads this week’s conversation. Jason Fried and David Heinemeier Hansson talk through how they approach product walkthroughs, what’s ahead for open code at 37signals, and why a little fun still belongs in serious software.

Watch the full video episode on YouTube

Key Takeaways

00:22 - Recording product walkthroughs without scripts or polish
11:45 - Writebook as an open source product
15:04 - How the 37signals team uses Basecamp and Fizzy together
22:52 - The quiet joy of Easter eggs and playful details in software

Links & Resources

Transcript

Kimberly (00:00): Welcome to REWORK, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes, joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. This week, we are going to knock out some listener questions. We always love when people submit things and we’re just going to knock ‘em out. We’ve gotten some emails, voicemails, YouTube comments, so I’m going to start with this one. Jason, this one’s specifically for you from Francisco. This is a comment on X. He said, “I admire your product walkthroughs. There’s so much to learn about everything you don’t say and how you point attention and in which order. Do you write scripts? Do you do many takes? What’s your process for releasing them?” I’m assuming this is related to Fizzy most recently since you’ve done some product demos on video for that, but you’ve done them for other products as well. Do you script write? Are you just winging it? Tell us a little bit about that.

Jason (00:52): Yeah, I don’t write a script. I go through it a few times. I kind of find my way by just going through the product and thinking to myself, if I was new, what would I want to see and in what order kind of roughly. And I do a few dry runs and then I just record a single take. The way I do it is if I screw up in the first minute, I start over. If I get the first minute right without stumbling on something, I just go, even if I make a mistake, I don’t care. But it bugs me if I screw up in the first minute. I think for the Fizzy one I did maybe four or five just kind of dry runs. And I’ll say it a little bit differently each time and I’ll try to use things that happen in the interface at a certain time to lead me somewhere.

(01:31): So I’ll be like, oh, see this column, see how there’s a bubble there? What’s that about? And then it’ll take me there. I won’t go look for a bubble, I’ll spot a bubble in Fizzy, for example, there’s a feature in Fizzy with these little bubbles come up. It says stalled for 12 days or something like that. I know I want to talk about these bubbles, but I’ll wait for them to occur naturally throughout the demo and then I’ll seize on one and go, oh, there’s that bubble thing. What’s that about? So I kind of let the product experience drive the conversation. So what’s always in my head is if I’m just going to sit down with somebody and I was going to show them the thing, I wouldn’t start over all the time. I would just keep going. If I messed up, if I missed something, I’d be fine. If I circle back and remember something later, that’s fine, I’ll just do that too and try to make it as natural and organic as I can possibly do. That’s usually how I do it, and I found that if I script it, that I’m thinking about the script and if I’m thinking about the script and if I miss a word or miss something, that throws me. So I find it to be better, not to be able to be thrown, just kind of walk through the thing itself.

Kimberly (02:27): Okay. You’re making this sound very straightforward. As someone who also does similar work to this, it is not easy. You’re making it sound very easy. When people are watching it, I think it comes across so natural, so casual, but it’s hard.

Jason (02:41): Keep in mind, I’ve been making the product, so I’ve been making this thing for a year, so I know it pretty well. I know how it works. I know the kinds of things I want to hit, but I’m always thinking about I’m just showing this to somebody else. I’m not thinking about it as I’m recording a tour. For me, it’s like I’m just walking through it for someone else’s benefit and I’m noticing things along the way and remembering, oh, I hadn’t talked about that yet, so this is now a time to talk about that. But if I watch it back, I go, I screwed that up. I screwed that. I should have said that one earlier. I stumbled over that, or that’s a weird word I said. I wouldn’t say that that way again, things like that. So I might notice some of these things that other people might not notice because they don’t know how I would’ve done it ideally.

(03:26): But I don’t think there’s an ideal version of these things, in my opinion. There’s just the best version you have in the moment and it’s more than good enough most of the time. And it just communicates that this is what this thing’s about. And I think people can kind of tell that it’s a real walkthrough versus a staged demo. We’ve talked about this before and this is a different parallel, but Apple’s keynotes today are staged and they’re missing something. And you go back and you watch, again, not here to like idolize Steve Jobs, but he was one of the best at this. But actually if you look at another good one is like James Dyson. James Dyson’s been giving some really great walkthroughs and tours of new products. They’ve been making Dyson vacuums, and I know he knows what he wants to say because he’s got some slides along the way that demonstrate the things he’s saying, but the way he’s saying it, it’s very much, I just know my stuff.

(04:14): I’m excited about these things. I’m going to talk this stuff through the way I’m going to talk it through. He’s not reading off a cue card or anything like that. And I feel like obviously Jobs was the same way. He kind of knew where he was going and would sort of play off the audience and kind of find angles and corners and talk about things that were exciting for him. And that’s kind of how I tried to do this. But yeah, it’s not easy and there are times when it’s really frustrating, especially in the early first minute where you screw up and you may have to do a few takes, but I still just like to do a single take.

Kimberly (04:43): And then David, you’ve done some similar work with Omarchy. Are you kind of using the same philosophy? One take wonder?

David (04:49): It’s very similar. It’s funny you mentioned the first minute because the first minute is by far the hardest to get into a rhythm and a flow. I feel it’s very similar to giving a keynote on stage. If I can just get through that first minute, I know the rest is going to roll off. And again, as Jason says, it’s not just because it magically comes to you, it’s because you’ve been working with it. You’re talking about stuff you actually know something about, that you actually care about. And getting into a flow of talking about those things is very different than rehearsing lines, preparing a script, where perhaps you are not the one building it. You’ve not been immersed in this for a long time already. I find that the main thing I’m trying to do both on stage at a keynote or in a video is not actually conveying information.

(05:38): There are all sorts of ways we can convey information, we can write it down and then you can edit it and make it more proper. And we do that too. Both Jason and I enjoy writing and there you can take your time to really get those paragraphs just right, but when you’re doing a video, the reason why is because you want to transfer enthusiasm. I keep referring to Jason’s wonderful phrasing of this, that the excitement that you have for your own product and trying to get that across to an audience, that’s what you’re selling on video. It’s not just the information. The information’s riding along. It’s got to be there. You have to have something to be excited about. But the key value is that excitement and it is very difficult to rehearse that. In fact, I would say if I try to rehearse too much, I can just see that enthusiasm level go down.

(06:29): I can just see the naturalness of it disappear. And it’s one of those areas where worse is better. And this isn’t just about whether you say something wrong or you backtrack it a little bit. Even at times about the production values. I try, I like to have a nice camera and like to do those parts of it, but I try not to overproduce it. I used to do that. And I compared the, I think it was the first Hotwire video I did. I got into my head that I wanted every word perfect and it meant that a 20- or 15 minute video took eight or nine hours to produce for me, and in the end it was perfect. There was no ummm, there were no ahhhs, no backtracking. Every word was perfect, and it was way worse. And one of the reasons why it was way worse was it was harder actually for the audience to absorb the material when I was just firing it off with just perfect precision.

(07:25): There was no stumbling, no weights, no nothing. And then I contrast that to more winging it style, knowing what you’re going to say for the first minute, but then letting the product drive where you go and I go like, Jesus, I like that better. I think we talked about this once before, this anecdote from Fleetwood Mac, when they were recording, what was the song? They were recording one of their songs and they come into the studio, they do the first take and then they’re like, all right, we got the first take. Now let’s make it really good. And they try another 30 times. They can’t capture the magic, they can’t get that in there. I think there’s just something really human about getting it right by getting it slightly wrong, by getting it slightly off and all of that is intuitive. It’s not something you can script.

(08:19): It’s not something you can just pin down. And I think trying to capture that is a lot about why TikTok and these other platforms have taken off where it becomes performative to put the fucking mic in your face like, oh, I’m not even prepared. You can’t even goddamn see my face because I got the mic in my face. All of those aspects that gets performative too. But there’s something in that that just attractive to an audience, who want to see humans. And this is why this Apple pre-recorded super slick, super overproduced show is landing so flat. You want to see someone fuck up. I don’t remember if we talked about this already, but with Zuckerberg on stage, I think he had one big presentation a few months back and he just screwed up like four demos. And on the one hand you can go like, well, that’s embarrassing.

(09:09): Or you can go like, wow, isn’t that human? Isn’t our stuff screwed up half the time? Now of course you don’t plan to screw up four times on stage before a world audience, but there was just something to that where I go, I want to watch that. I don’t want to watch the slick overproduced stuff that almost feels like it could be AI. It is almost like it’s so robotic in its polish. Even the jokes are robotic. I remember this, Federighi he’s running around and he’s jumping over and you could stand about four and a half seconds of that and then you just go like, Jesus fucking Christ. It’s just so cringe versus again, a human fucking up in stage is endearing.

Jason (09:51): The other thing I was going to add is something that I remember is I always do worse when I’m trying to remember what I’m supposed to say, and that’s what happens when you practice a lot is you tend to want to remember your lines. In a sense you’re thinking from behind instead of being on that edge where you’re actually performing, and I don’t mean it in a performative way, but you’re actually on the edge. You’re live. That’s the performance is when you’re live and that’s why it’s good when you’re live and you might make a mistake, but if you’re just trying to remember what you’re supposed to say, you’re just playing from behind and I feel like for me, I get bored with that, which is probably where the enthusiasm, then it’s pretty obvious that I just don’t care because I don’t want to say the same thing nine times that I said before and I’ve forgotten how to say it just right. That’s how I tend to think about this is where I’m trying to remember it’s no good.

Kimberly (10:40): I actually think it’s easier to do this kind of stuff live because you’re not analyzing so much as you are when it’s recorded and you have to watch it back. It’s like, how you say it is how you’re going to say it and then you’re done thinking about it.

Jason (10:51): And the Zuck thing was a great example because what did it hurt their stock price? It doesn’t matter. None of this stuff really matters. Anyway, the product message got out there. People who were pumped about it got pumped about it. People who weren’t didn’t care anyway. I think it actually made him and his team and the whole experience a bit more human, as David was saying. And you don’t want to plan for that either. You don’t want to plan to screw up because then that’s pretty obvious and contrived, but when it happens it happens and everyone just moves on. No one remembers any next week anyway.

Kimberly (11:19): I also think it’s interesting, David, you brought up AI because nowadays, you know, we didn’t have this concern three years ago that when you’re watching something you’re like, is that real? Is that a real person? Is that AI? But now we have that. Now we’re analyzing those kinds of things, anytime you see someone on video.

Jason (11:36): I feel like anything that’s recorded is not real actually anymore. I don’t mean that I can’t tell. It’s more like I don’t see someone on the edge. That to me is actually real.

Kimberly (11:45): Okay, let’s go to this question. Someone posted this on X, David, this is more a technology thing. Maybe you can take this one. This writer says, “I’m curious to know why can’t you guys open gates for contributions to Writebook as similar to Fizzy and Campfire? Wouldn’t it benefit from open contributions from the community?” This says, why can’t you? But I don’t know that you can’t.

David (12:03): Oh, we totally can and we will. We just haven’t yet. And I think that’s the bottom line of that story is that Writebook is already essentially open source, but we haven’t open sourced the repo, and part of that was just wanting to do it right, look through things, make sure it’s all easily set up, write some read me’s, do the rest of the stuff that we’ve been doing, for example, for Fizzy so that we can process those inbounds. Now the other part of it is we’ve just open sourced Fizzy and it turns out that people are very excited about sharing their changes or finding bugs or whatnot, and then it takes a fair amount of time to process all of that because the fun part about contributing to open source is to see your contributions merged. Now, that’s not a guarantee. It never is.

(12:50): Every single open source project I’ve ever worked on will have more contributions than things are merged. Not everything’s going to make it in, but you have to feel and see that something is making it in. Some things are getting into that product and it’s getting shipped, and that requires for us to have some bandwidth to be able to do that. And right now that bandwidth is dedicated to Fizzy. I want to make sure that we do that right. But a Writebook is absolutely going to be open sourced in the same way. I really like this growing fleet we have of real apps. The feedback we’ve gotten to open sourcing Fizzy has been incredible. Here’s a real production grade application built to our quite high standards for code quality and therefore it serves an incredible example for people building all sorts of apps, even if they’re not building a productivity tool.

(13:42): We’re approaching everything from logins to whatever in a dedicated, methodical, nice way, and that includes a lot of lessons for people on how to build their own kinds of apps. So, I love that we have committed to doing this. I love that people are responding to it. I’ve seen all sorts of really cool projects spin off it. People have built these AI-style guides based on our code quality and our code style and are now writing their own software more in the style that we do things at 37signals that they’ve gleaned off Fizzy and elsewhere. So we’re going to continue to do this. I think this is really healthy for juniors, it’s healthy for the AI learning how to become better at these things. That’s how we get better systems. So I love it. And I think most of the fear cases that plenty of individuals and companies imagine could happen when you open source your code like this hasn’t happened yet. I’m not going to say that nothing could happen, but it hasn’t. And the payoff for us has been huge. So Writebook’s open source release is absolutely coming. You can already get the code. I mean you download that Docker image and you can open it up and you can have a look inside of it, but you’ll also be able to contribute straight on GitHub soon.

Kimberly (15:03): Excellent. Since we brought up Fizzy, let’s go to this one. It’s a comment on YouTube and Jason, I think this is actually maybe your Fizzy walkthrough. Someone wrote “Would love to hear how you all are using Basecamp alongside Fizzy, especially as we expect Basecamp 5 to release at some point soon.” So how are we internally using both of our tools?

Jason (15:22): Yeah, so we’re using Fizzy primarily as a bug tracker, but also for mobile on-call and some other on-call, and some other idea generating stuff. And Basecamp 5 actually, and Lexxy. We’re using it in a lot of places primarily for issues. What’s actually nice about this is you can of course use Basecamp this way and we have for years and years and years with the Card Table and before that To-dos, but there’s something kind of nice about knowing that there’s a separate place in all the notifications, in the separate place pertain just to issues, that you can go somewhere else and know that whatever you’re going to hear about are issues versus having that woven in with all the other things that are going on in Basecamp because there’s 30 active projects in Basecamp that I have, I have access to more than that, but that are actually happening.

(16:05): So you’re parsing all the new ideas and other things that are going on in Basecamp and then any issues that will be coming in as well are part of that notification history. So there’s just a lot of other stuff not to look at if you just want to look at issues. So it’s actually been kind of nice, I think quite nice to see… when I go to Fizzy, I know I’m just looking at stuff that needs to be dealt with, that’s broken, that might be broken, whatever it is, and the notifications I’m getting there are about things we need to address. So that’s how we’re using it and that’s why I think it’s actually quite useful to have a separate place for this, but you don’t need a separate place for this. You can certainly use Basecamp, so I’m not advocating using both unless you feel like you might want to try and then you might find that you like it better or you don’t like it as much, that’s fine too. But for us, I think we found a good balance being between both of those products that way.

David (16:52): Part of it is also just dogfooding your own work. We built Fizzy for it to be good, we have to use it, we have to use it in anger, we have to use it on multiple projects at the same time, and you can also put it into Basecamp through the Doors feature. So you can connect Fizzy to Basecamp by adding a Fizzy door. We now have an explicit Door in Basecamp with the nice Fizzy logos so you connect these two things and you can jump back and forth. Then also sometimes, as Jason says, it’s kind of like the single purpose software. You can read Kindle on your phone or you can have a dedicated Kindle and it has different ergonomics and sometimes that’s just what you want to have. I don’t think we’ve found the final stage for how these things are going to be fully split, and I don’t think we will for some time until we’ve run both systems for longer, but I think you can just try it.

(17:44): This is one of the things I find so fascinating with software. In all these other domains, people have no qualms about like, well, I have this cup and I have the other cup, and what do you use that cup for? Well, sometimes I just pick one. There’s this drive in software, like I got to find the perfect solution and then that’s the solution and then I’m done. It could also be a little bit of this and a little bit of that. Now again, Basecamp’s pitch in large part is all of it is inside of Basecamp and obviously that’s working incredibly well both for us and for many other people, but it goes to just be a little looser sometimes. It doesn’t have to be as stringent, cut up, like when is it this and when is it that, and then you enumerate it in some feature table.

(18:31): That’s not actually what it is. It’s a lot more of what does it feel like using it. Some of it, it’s also just fun to do different things. I’ve found that in even our internal processes, sometimes it’s just good to mix it up, not necessarily even because the new thing is quote-unquote better or you can quantify in these ways just because doing something slightly different every now and then has a quality all of its own, and it’s part of just what makes life fun. Do you know what? You just pick something else today? Why? Well, I don’t know, because you fucking feel like it. That’s why. That’s enough reason.

Jason (19:08): Yeah, it’s like running a mile or 10 miles or whatever and picking a different route each time you’re like, I just felt like going this way this time. I don’t know. Of course the parallels aren’t exactly the same, but there is something to it. This idea of trying something new and giving something a shot and we’re using, or no, you’re using, I should say, Kimberly, Fizzy to sort of manage the podcast now. The thing that’s really interesting about it’s you just go and hit J, type REWORK. I’m right there. That’s all I need to see for the podcast. It’s like upcoming episodes, which ones are recording, which ones have been recorded, which ones are in editing, which ones are being published, which ones whave we done. It’s really nice just to be able to see that and I don’t have to go through all the other stuff that I need to normally would look at in Basecamp to get just to that stuff. So for me, it’s really nice. I know that you also then upload episodes to Basecamp.

Kimberly (19:52): Right.

Jason (19:52): So you’re using both in that way, but the idea of a really simple production pipeline just in Fizzy is actually really, for me, for someone who’s more of an observer is actually a really nice format for that. So I dunno. Again, try it all, see what works, see what sticks.

Kimberly (20:07): Well, and not to make a Fizzy sales pitch, but we were using the podcast in a Card Table of Basecamp, which makes perfect sense and now I have, David was saying a door to Fizzy. I could always go back to the card table, but I actually really like the visual aspect of Fizzy. It’s just fun to look at. So I’m like, I’m going to keep it as a door. I’m going to keep using both. So…

Jason (20:30): That’s the other side there is just, I like being in that product.

Kimberly (20:34): I like looking at it.

Jason (20:35): I like being in Basecamp too. I mean for all sorts of different reasons. We’re working on a new version of Basecamp which might inherit some of that stuff from Fizzy. We’ll see, but it’s also just nice to bounce into a different environment for a minute. Just good.

David (20:48): I’ll give one more parallel here, which is I’ve gotten into these mechanical keyboards. I’ve probably talked about it a fair bit, and there’s one right out of sight here that I do not have in Copenhagen, I have it here, and it’s this wooden keyboard by this Japanese company called Akko. I’ll show it up here. And you know what? It’s a fucking keyboard. I type the same words whether I use this keyboard or I use my beloved lofree 84, and do you know what? I like having both. And then occasionally, this week, I will type on the Akko just because variation is its own spice. I don’t have to find the final solution to getting words into a computer. I can have multiple solutions and I can go like, you know what? Today I feel like a wooden keyboard. Today I feel like this other nice keyboard that I use, I do the same thing with computers.

(21:42): I love hopping back and forth between different computers just because I like the variety. I like to see the different design. I like the fact that there’s just this, especially when it comes to mechanical keyboards, this different tactile experience. Same thing with cars. I love cars and sometimes I really like this car and I get this thought in my head, this is the one, I don’t need anything else. I just need this one car. And then three weeks later I’m like, oh, I’m really glad that we also have another car and I can drive that and you can jump back and forth between these things and it gives you just some variation and satisfaction in your life. And again, I feel like this is intuitive to lots of people when it comes to all sorts of other domains. I’m a bad example for this, but most people have clothes in different colors. Like today I’m going to wear the red sweater. Unfortunately, just have a wardrobe entirely consistent on black t-shirts. But when it comes to that, we understand that just a variety, just a flavor just to dip in tactile sensation. Just waking up today and going, it’s a red sweater day, it’s an Akko keyboard day. It’s a Fizzy card day is enough reason and it needs no further justification.

Kimberly (22:55): Okay, this one, this is the last question that I’ll ask you guys is a design-oriented question, so I’m not sure that you can specifically answer this, but we can give this person some advice. This is an email that came from Ravi. It says, “Hey team, quick question. I’d love to hear you tackle on the podcast. I work in a business to business SaaS company in a traditional industry, and our product org basically doesn’t believe in UI delight at all. The mindset is we’re B2B, we need to stay serious. Enterprise clients don’t want unicorns or playful touches, but like you said before with the harp sound and other little moments of delight, humans are humans. Even in enterprise software, small touches can make the product feel more alive and enjoyable. So my question is, what do you do when your product leadership, (I mean that’s you guys), but what do you guys think when your product leadership thinks delight is unnecessary or even harmful and only wants to ship functional features? How do you shift that mindset? I’d love to hear your take.” I know that’s hard for you guys because you are the leadership, you’re setting that direction.

David (23:55): It’s not hard at all.

Kimberly (23:56): What advice would you give our friend?

David (23:57): You do it anyway. The history of computer software development is full of Easter eggs, things that were put in by the people building the thing without the folks paying for it even knowing. That has a long, proud tradition and you should step into that tradition and just fucking ship it. Now, part of that satisfaction is also, it’s a little illicit. You’re a little bit of a rebel. You’re putting something in, you’re kind of sort of not supposed to, but does management even know what’s going on? There’s this wonderful guy on TikTok that has this whole series about working in retail about management doesn’t know what’s going on Haven’t you ever worked anywhere? That’s my reenactment of that, and I think it’s actually true. That’s why it’s funny because most of the time people who would even say that, that delight is, like that’s not for us or that’s not… they don’t fucking know anyway, so just put it in there.

(24:50): Make the delight for your own satisfaction and just have it in there and half that satisfaction is you going to run a tiny itty bitsy risk. I mean, I’m just talking for myself here. That’s part of the spice of life that something have to even smell or taste a little bit like it’s a tiny bit dangerous. This could be your tiny little bit of danger, like you’re not riding a motorcycle 200 miles an hour without a helmet, so instead you put in some secret little Easter eggs into your B2B software and you smile on a Sunday afternoon when you sit there and say, they don’t even know. They don’t even know. Peak human experience right there.

Jason (25:25): I love that answer. That’s a great answer. The other thing I would say is in the question, if I remember correctly, he’s like, how do you convince?

Kimberly (25:32): Yeah, how do change the mindset?

Jason (25:34): You don’t. You are not going to convince management of anything. You’re just going to do the damn thing and maybe they’ll convince themselves if they like it. Maybe some customer will speak up and go, this is really fun. Maybe they’ll completely miss it, which is probably more likely. I don’t think they’re paying attention to those sorts of things, but you don’t try to convince them. That’s the key here. That doesn’t work and there’s no need for it, so I would just build it the way you want to build it for the most part. Of course, look, you’ve got some guardrails, I’m sure. Someone’s going to notice if you turn everything yellow, right? Whatever it is. But yeah, sneak some stuff in there. Be subversive and bring a little bit of joy into software.

Kimberly (26:11): Okay, well that is a perfect place to wrap it up. Rework is a production of 37signals. You can find show notes in transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube, and seriously, if you have a question for Jason or David, but a better way to work run your business, the only way we can do episodes like this is if you send those in. So you can leave us an email at rework@37signals.com or leave us a video recording at 37 signals.com/podcastquestion.