SEASON 2 - EPISODE 179 - January 14, 2026

Making things that multiply

Good ideas rarely belong in just one place. This week, Jason Fried and David Heinemeier Hansson share how 37signals lets concepts move freely across products, turning one solid idea into many useful ones. They talk about borrowing from the past without getting stuck in it, giving new concepts time to catch on, and keeping space for creativity as products evolve.

Watch the full video episode on YouTube

Key Takeaways

00:11 - Letting strong ideas travel between products
02:49 - Giving each product its own design voice
07:26 - Bringing back old features when it makes sense
12:03 - Avoiding nostalgia just for the sake of it
17:55 - Using real-world use to guide product improvements
22:10 - Keeping your creative process flexible
23:57 - Leaving space for fun in the design
31:13 - Designing around feel instead of rules

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 your host, Kimberly Rhodes, joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. Well, this week, I thought we’d talk a little bit about, I’m calling it making things that multiply, but using some of the same ideas in one area of your business and translating it to another. For us, that sometimes is features from one product that get moved to another, but I thought we would talk about that with our whole portfolio of products and how we’re thinking about that. So Jason, let me just start with you. You mentioned this actually recently in a live podcast that you did, talking about a HEY feature that might be making its way to Basecamp 5. Kind of talk us through how you’re thinking about translating some of those ideas that we’ve had in the beginning and moving them to other parts of our portfolio.

Jason (00:51): Yeah, sure. I mean, I think one of the biggest advantages of building multiple products is that you get to discover new things. We don’t set out to discover new things, you just do. And then you go, “Oh, that’s a good idea. We can maybe use that in other places.” Or, “That design idea makes sense. I hadn’t thought about that before and wouldn’t have had a chance to think about it had I only been thinking about one product.” So you get this blank slate to explore. And one example that comes to mind right now is in hHEY, when we first built HEY, we had this idea of these two stacks at the bottom of the screen. We had Reply Later and Set Aside, which are these two little stacks of little cards that actually pile up physically and you click it and it kind of fans open.

(01:26): And that just came out of HEY, hadn’t come from anywhere else, but from hHEY. And then we’ve now been bringing this idea across the product. So in Fizzy, we have a stack in the far right corner and the far left corner, different positions and not necessarily the same idea, but the same concept, which is these stacks that fan open and hold different pieces of information and they kind of pile up in a sense. So trays, piles, stacks, whatever, but that idea came from HEY, and now it’s in Fizzy and we’re exploring it now in Basecamp 5 as well. It’s sort of just a good pattern that we’ve discovered. And again, we wouldn’t have discovered that had we not explored a new product. It wouldn’t have probably come to Basecamp or come to Fizzy had we not done it in HEY first. So sometimes you stumble on something that just works and you have to maybe modify it for different products for different reasons, but there’s some really good ideas in that.

(02:11): So that’s one example that I can think of. There’s a handful of other interface ideas and other things. For example, when we built Campfire and Writebook under the ONCE label, we really radically simplified the UIs to the point where we came up with this different menu system, which turned into another idea, which turned into a unified menu, which is something we have in Fizzy. We actually also have that in HEY that actually came from HEY initially now that I think about it. And it’s coming to Basecamp 5 too, a single menu at the top of the screen versus a bunch of links at the top. That actually came from other products too. So we do kind of weave things in when they make sense, but we don’t set out to find something new. It just, you stumble upon it and then you realize that you can thread it through other fabric basically.

David (02:49): And this is one of the reasons on the technical side why it’s also just a lot of fun to explore brand new products. Because if the only thing we ever worked on was Basecamp, you’re just going to be saddled with a certain architecture. You’re going to be saddled with a certain set of decisions that are going to be quite difficult or expensive or slow to change. And if you want to explore new ideas, there’s just no better way to do it than in the lush green field of a clean code base with no existing conventions, not a ton of baggage that you have to drag around. And if you look at Rails, it is basically a history of 37signals launches, at least as far as goes for my contributions and the rest of the contributions we’ve been making here at the company, you can literally plot whenever we do a new product, there’s this surge of new activity, new features, sometimes entirely new frameworks that are being put into Rails because they have a chance to be developed on that green field.

(03:54): And then sometimes we go back and we put some of them back into Basecamp, but a lot of the times just that initial progress, that initial move forward for the whole system comes because we’re trying new ideas, because we’re building something new in a brand new shell. And I think unfortunately for some people, for some programmers, they’re robbed of that opportunity to really flex all their talents and their creativity because they only ever work inside of one limited code base and maybe they do so for a very long time and they just start taking certain decisions for granted that that’s concrete. We just can’t mess with that. We can’t experiment with that because it just be too painful, just be too hard. And I’ve always felt that the joy of being a developer, being a company that creates new products is that you get to use the best of your abilities, your very best ideas, your very best techniques.

(04:52): And in fact, evolving those things is that your ideas themselves improve because you’re applying them in a new domain and you really just don’t get to do that unless you start something new. So I’d say, if you look at our whole portfolio, as we’ve said many times, Basecamp is the bread and the butter. That was the slam dunk success that has outshown everything else that we’ve ever built. But even under those circumstances, if nothing else we built and mounted to something that really moved the needle like Basecamp has moved the needle, it’d still be worth doing because as Jason says, many of those design techniques or new ideas, new patterns we develop in these new products, that’s the kind of stuff we can take out of these labs as they actually are to some extent and then put them into a Basecamp, where less likely we were going to pioneer some of this stuff and experiment with it and expose it to customers as a first idea and just constantly move the cheese around unless we had these labs, unless we had these experimentation rooms where we can just do things like that.

(06:01): Now, if you look at Basecamp, over the years we’ve rewritten the chassis, we like to say, three times. There was the original version we launched with in 2004, then we wrote a version two in 2010, and then we wrote a version three, which is basically the chassis underpinnings we’re still on and released that in ’15, right? That’s not a lot. That’s not a lot of opportunities over 20 plus years to do that. And if those had been the only opportunities for us ever to do any of that core experimentation, I think we’d just be worse designers. We’d be worse programmers. We’d probably also get a little bored. I think that’s the reality too of these green fields, whether it’s Fizzy or HEY or something else is I at least need it, I know Jason does too, we need sort of just some fresh air sometimes where we can go away from the main product that’s funding the business, explore that, stretch our legs and then come back. And then be re-energized and look at something like Basecamp 5 that we’re working on right now and just be super excited about all these things that we’ve tried, all these ideas that we have, all this technology we’ve developed, and taking that back and putting it into Basecamp.

(07:17): I don’t think we were going to arrive at that level of enthuusiasm for a new version of Basecamp unless we’d had these other opportunities.

Jason (07:26): What’s also cool, I’ll just add, is now that we’ve been around for a while, you get to go back into the back catalog and find some of the early ideas that actually made a lot of sense. So for example, working on Basecamp 5 right now, and I was just going back to Basecamp two to just kind of like look at a couple things and like, oh, you know what? A couple of these ideas are really good. They’re really, really good and they’re not in Basecamp three or four because we changed it. And they actually are, gosh, I’m kind of annoyed that we left these behind actually. So bringing some of that stuff back, maybe we’re exploring to see if it fits because the model’s different and the design is different and everything’s different. But are there some ideas from earlier versions that made a lot of sense?

(08:03): In fact, Basecamp 5, if you’ve been around for a long time, has some classic elements in it, Basecamp Classic. And it might have some Basecamp two stuff in it and there’s a bunch of new ideas from HEY and from Fizzy and just new ideas in general. So it’s kind of like you see some brands going to the back catalogs and like this is common in the watch industry, it’s common in the shoe industry. Nike brings back a bunch of reissues of old shoes designs that were actually quite good and they’re out of fashion and now they’re kind of back. And so it’s kind of cool to have been around for a long enough time to go reach back into the back catalog and go, “That was actually a good design. We should think about bringing that back.”

David (08:37): And I think what really is fascinating with bringing some things back is you don’t actually know what’s golden until it’s had time to marinate for maybe five years, maybe 10 years, maybe 15 years. It’s that distance that gives you the clarity to really evaluate, do you know what? That was actually a great idea. I use this technique all the time when I look at our technical infrastructure, and I’ll go back to the back catalog of the way we used to build things in the olden days and I’ll contrast what we’re doing now to kind of give it a reality check. Is this reasonable? Is the amount of complexity we’re applying to a given problem today, is that reasonable compared to how simple things used to be? Now it’s not that everything used to be simpler, but a lot of things did used to be simpler.

(09:29): The early ways to build web applications just were a lot simpler because there was a lot less. So you had to build more from scratch and you couldn’t spend all your time just creating these towers of complexity. And now that we’ve had several decades to accumulate ideas that didn’t always pan out or weren’t, it’s not even that they didn’t pan out, it was that they weren’t worth their weight, that whatever advantage they gave you, it was just too heavy. And you pile this on and you get boiled, like the proverbial frog, you’d get boiled and you’re like, every little ounce you add on the weight, like that’s not too much, like two ounces. The whole fucking thing weighs five kilos. I’m really mixing Imperial here. And you don’t notice until you look back 10 years, until you look back 15 years and you go like, we didn’t make it better enough to warrant all the weight. Could we shed the weight again?

(10:26): What if we just reset, hey, here’s a fresh new code base, here’s Fizzy, let’s try some brand new things. Let’s try a completely different way of doing it. And it’s funny because that’s also where the cloud exit in part came from. Having that look back and go, not only 10 years ago were things simpler, they were faster and they were vastly cheaper. What have we done? I don’t think there’s enough of that long scale retrospection in our industry. There’s a lot of retrospectives where, how did the last project go? How did the last six months go? It’s not enough time, dude. You need 10 years of distance to be able to sift through. What would the actual core great ideas? There’s a great parallel here to books, that the best books are old books because they survived. That’s how you know that they have wisdom in them.

(11:23): If a book made it hundreds of years, there’s something in there, otherwise it would’ve gone by the wayside, like all books almost do, right? Anything that manages to survive decades or centuries or millennia, they have something that tells you that, do you know what? Yo should probably take another look there.

Kimberly (11:42): This reminds me, I was recently reading an article about a new movement of people who are getting not smartphones like old school flip phone, just use it to make a phone call because technology has just made us go into this rabbit hole of always being on it. So this kind of going backwards in time and bringing back old things, it reminds me of that a little bit.

David (12:03): And I will say, on that note, you have to be careful when you look back that the thing you see in the mirror isn’t just nostalgia.

(12:12): Nostalgia’s fun, but it can be pushed so far that it’s a form of stasis. You’re not pulling something from the past forward because it was legitimately just better. You’re pulling it forward because it’s giving you a vibe. Now, maybe that’s fine. I mean, it works in fashion, it works for certain kinds of design. I mean, Jason mentioned watches, much watch design literally has a hundred years on it and there can be something to that. But inside of technology, you really do have to carefully thread to here that you’re not just loving the past because it was in the past. You’re not just loving the past because as a … I’ll speak for myself here. Now, 46-year-old programmer, I think, oh, remember when I was 25, that’s 20 years ago. So whatever was there 20 years ago is there for good because blah, blah, blah, right? Now, you got to really be careful that the nostalgia is, if it’s the purpose for being, it’s like seasoning, right?

(13:10): It’s nice to get a loop back, a reminder, a nudge to like, remember that without being just soaked in it and now nothing new can be good and everything has to be vinyl and film cameras and whatever. It all has its place, but it doesn’t appeal to me if it’s just about being suck in the past.

Jason (13:34): Yeah. And I’ll add to that too, just to be concrete about this, I’m talking about going back to the back catalog, seeing something in Basecamp 2 that makes sense. It’s not like going back to the back catalog and taking these stylistic cues from 2012.

Kimberly (13:47): Sure.

Jason (13:48): It’s actually, for example, I’ll be very specific. In Basecamp 2, if you go to a project, there’s an activity block at the top of the project as I think the last five things that happened in the project. And we’ve moved that down below the fold essentially, if we’re talking about folds and screens, whatever, in future versions of Basecamp. But I’m actually looking back at that now I go, it’s actually really nice to drop on a project and know the last few things that have happened. So you can sort of orient yourself like, is this fresh? What’s going on here without having to go hunt for it? So I’m not going to lift that design, wholesale and move it over, but conceptually there’s something really good about the thing we did before that I think we’ve lost in subsequent versions. So that’s the point. It’s not nostalgia in terms of an aesthetic.

(14:28): It’s more like that actually was a good idea. There’s a reason behind that idea and we lost that good idea and we can bring the good idea back. So I like the idea. It’s just like no build is a good example of this too. Before it was, there wasn’t even an option. That’s just how it was and we’re bringing that back now because it just makes more sense. We don’t need to pre-process all this stuff. We didn’t have to do it before. Why do we have to do it now? That’s another example of an idea that’s time has come back and it makes a lot of sense.

David (14:53): I like to think about this in terms of benchmarks. Jason mentions this design here is like, if you evaluate the project page in Basecamp for can you quickly see whether something is fresh, can you quickly see what’s been done?That’s a benchmark and you can measure different designs on that. Do you quickly get that sense, right? An old design can score better on that benchmark than a new design. As Jason said, it doesn’t mean you should copy the old thing, but you should now respect that benchmark and go like, okay, if we want to move the new design up, we have to change in certain ways. Maybe we borrow some ideas or some concepts, not about the status of it. Same thing with the technical stuff. Same thing with cloud versus on- prem, no build versus bundling and transpiling. If we set the benchmark of how long does it take to deploy, how many dependencies does it have?

(15:49): How quickly can someone get up to speed on a project they haven’t touched in a long time? Suddenly it gives you a lens to see whether you’ve actually moved things forward or not whether you move them forward. I think in almost all cases, some things move forward among semi axes. On one angle, this is correct and better, but is it the most important angle? If we brought back these other five angles and evaluated the whole thing together, you can then go, do you know what? Maybe we took a bit of a detour here. We got to get back on the path we were on, not for nostalgic reasons, or at least not only, and then follow that again. And I think that retracing of your steps is actually a completely human, normal way of learning and experimenting. If you think everything you’re going to try is going to work, you’re delusional.

(16:38): Most things you try don’t work, shouldn’t work because they’re just these experiments. And the intellectual honesty of being able to back trace, being able to look at your former catalog and go like, eh, do you know what? That was actually a better idea. Fine. Okay, I’ll go back and I’ll try again along the route that was maybe in the other direction. It’s just a lot of fun because it gives you that opportunity to interrogate your own work and let it teach you something. There’s so many lessons, many of them we’ve written down in books that are like, I’ll forget. I’ll forget. And then sometimes I’ll catch someone, often because someone is tweeting something out of Rework, for example, and they go like, oh yeah, Jesus, that applies to the conversation or the decision we made three weeks ago. This is the hard part about wisdom.

(17:28): It’s not about just like how much can you accumulate. It’s can you recall it in the moment of need? Can you use that wisdom to apply to your actions so you make better decisions in the moments? That’s the tricky part and that the accumulation alone is not enough. It’s a recall. It’s the, do you have that lesson at the right time? And interrogating your back catalog is a wonderful way of just evaluating all that.

Kimberly (17:55): Okay. I’m curious where you guys think about the line or if there is a line between repurposing some of your other ideas into these other products versus keeping these products very distinct and different from each other. For example, I’ve heard a lot of people ask about Fizzy in regards to Basecamp’s card table. When is card table going to get the things Fizzy has? I could see the argument being like, they’re two very different products. I could also see the argument being like, there are some good ideas, maybe we will move them over. So how are you guys thinking about that delineation?

Jason (18:28): I don’t know. I mean, I think Fizzy actually became a lot more like card tables over the past six months. So really Basecamp influenced Fizzy in that. Even though Fizzy is a brand new product, I think Basecamp had more influence on Fizzy than Fizzy might have influence on Basecamp. However, and this is not actually from Fizzy, it’s really from Omarchy, which is the keyboard commands, which are littered all over the place in Fizzy, and I mean that in a good way, are coming to Basecamp. So we want to be able to move through things quickly. I mean, that’s a little bit of an aside, but I don’t really know. I think we’ll see basically is how we’re building Basecamp 5 right now. Card tables work really well in Basecamp 5. They’re kind of, of Basecamp. Kind of turning it into Fizzy might feel incongruent in some way that may not make sense.

(19:12): I don’t really know yet. We haven’t explored that because card tables work really well in Basecamp already. But I’m sure everything else will get a little bit of this, a little bit of that. And sometimes you get subconscious too, you don’t realize it. For example, Fizzy is very colorful and very vibrant. It leads with like an optimistic kind of feel to it because of the colors and the gradients and stuff. And Basecamp doesn’t have a lot of that and there’s good reason for that, but maybe you could use a little bit of that. So whether or not it’s like we should do this because Fizzy has it or we’re just sort of in the mindset of like, maybe it’s better to have a little bit cheerier, happier, color, more colorful interface in general, that might make its way into different things. I don’t really know. I’ll tell you this, I don’t really love the pastelly colors in Basecamp.

(19:54): In card table, you can color the columns and they have this sort of pastel shade, which is pretty common across software. Typically, you don’t want super saturated colors if you have to read text over those things. It’s okay to have saturated borders and shapes, but when you’re reading text over a bright red or a bright green, it can be quite jarring. So people tend to go to the far side there and go really light colors, but then you only have a few pastels available to you. I like to see if we can get a bit more vibrant and that might be because Fizzy showed that we could do some of that. I don’t really know, but I don’t know, it’s a long answer to maybe not even answering the question, but that’s sort of what’s on my mind after hearing you ask the question.

David (20:31): I think part of the benefit here with something like Fizzy is that we don’t have to do anything right now. We can let Fizzy breathe and live and our take on what worked and what didn’t evolve over months or maybe in some case even years before we pulled some of the stuff that we really have grown to appreciate and that stood some test of time back into Basecamp, that Fizzy is in some ways a scouting expedition. And we’re not clear what the terrain looks like. Even though this thing is out, a lot of times you’ll put your heart into a certain set of ideas and you’re very enthusiastic about those ideas when you first launch them, but then three months later, six months later, it’s a great test. It’s a great filter. Of all the ideas that we put into Fizzy, what are we still really excited about six months from now?

(21:28): I guarantee you that we’re not going to be able to exactly predict which is which. Sometimes the design that you like right now, I don’t know, ages in a way that you don’t like or whatever it is. The great filter of time, you need to love it at work. You need to let time work and sift through what do you really want to keep? Of all the ideas we had in Fizzy, what are the mainstays? We don’t know right now, and we should actually not be overly in a rush to find out or to declare already what is the top five things we should bring into Basecamp. I bet you it’s going to be quite a different list in a while.

Kimberly (22:10): I also started thinking the structure of our company makes it such that it is probably easier for us than some other companies to reuse our ideas or to be inspired from one product to another because it’s the same team working across them. It’s not like project manager on Basecamp is not looking at HEY and is not looking at Fizzy and they’re in these silos of organizational work. It’s like the same group is working across all of these products.

Jason (22:39): Could be. I think the other thing is that we don’t have formalized style guides or like brand guidelines for better or for worse. Some people think it’s kind of a mess. Everything doesn’t look the same. If you look at Apple, Sony, these kind of brands, they’re very consistent across their lines of products, right? Very consistent, even from the hardware and the software being consistent. Our stuff, each product kind of looks a bit different and has a different vibe and different feel. We’re totally fine with that. And also allows us to say like, hey, you know what? There’s a great idea in HEY let’s pull that over here.

(23:10): The style guides are basically the living products themselves like, oh, that’s a good idea. Let’s bring that over. Not like, oh, we can’t do that because Basecamp wouldn’t allow that because we wrote this thing down that says it has to work this way or look that way. So we’re very fluid here in that way. And I think ultimately it’s just more fun, frankly, to be like that. And that’s a plenty of reason enough to do anything. It’s like that’s just more fun. Now, we’re fortunate that we can have fun because we’ve got a very profitable product in Basecamp, and we can do some things that other companies may not be able to do and may not be able to experiment with and try, and may not be able to say fun as a guiding light necessarily. But you play the cards you’ve been dealt and we’ve been dealt a good hand here, so we get to have some more fun perhaps than others and be more fluid and let one thing drive another versus sort of setting something in stone and saying, this is the way things have to look and have to be.

David (23:56): We just had an example of this yesterday where I worked with Sean, our marketing designer on the new page for the O’Saasy license agreement. We basically took the license agreement out of Fizzy, made it generic and said, hey, if you want to use it, you can. Here’s a site dedicated just to it. And Sean took this in a totally new direction. I had not seen this expression from him. My first instinct when I saw the O’Saasy dud dev site was like, oh, this has this cool retro future look. It doesn’t look like Fizzy. It doesn’t look like HEY, it doesn’t look like Basecamp. It looks very unique. He picked this very particular font that we hadn’t used before and it was just such a delight. I hadn’t even expected that we were going to do something fresh here. I just wanted, hey, let’s have a site where we can put up the license and anyone can copy it.

(24:46): And then it just looks great. It just looks cool. That’s enough. That’s enough reason. It just looks fun. It just looks cool. As Jason says, having fun in and of itself is actually a key component of keeping talented people engaged. I think there’s some minds that probably work well with Apple style. The style guide was set by some guy at the very top seven years ago and your role here is to copy that across the domain and apply it to some new page. Okay, fine. I mean, that’s there, right? I mean, I’d freaking jump off a bridge if that was what I had to do all the time and I just had to apply everything that I’d ever worked on in that rigid fashion. The fact that we can just be a little loosey goosey with it is part of what makes all the little neurons fire and sparking like, ooh, that one was fun here.

(25:43): Can we apply that here? This was a big part of the attraction with the Omarchy summer I had, which is like breaking out from that Apple aesthetic, breaking out from that Apple rigidity, a very nice aesthetic as it is, but very rigid, very not fun. I don’t think you would apply that word to Apple’s brand. Fun is not it. Cool, probably, whatever, but it’s not fun. And I thought Omarchy can just be crazy fun. It can just have wild colors. It could be a theme where everything’s green, it’s looking like a hacker movie. We just do things and we just experiment with it. And this is one of the things that Jason called out with the desaturation of the world, as we’ve talked about in other episode, that so much is trending towards or was inspired by that Apple aesthetic. It’s aluminum and it’s white and it’s just these grades.

(26:40): And okay, fine. Let that exist. Let that be a thing, but then let’s also have some wildness to it. I don’t know if we mentioned this before, but Jason made the new 37sigles.com site, which is not that new now, but just have a crazy color on every refresh. And I got to say, when I first saw it and I refreshed it and I got some screaming pink, I was like, “Whoa, whoa, dude, calm down a little.” And then I refreshed again and I got this also very bright and vibrant orange or whatever it was. I’m like, “Okay, yeah.” Just not everything just needs to optimize itself on readability. I saw someone comment like, “Oh, the ratio of accessibility, whatever look on the font is not the highest it could be.” Okay, can there also be some of that? Can there also be something that exists outside some mathematical equation of readability for the sheer art of it, for the sheer fun of it on a site that is whimsical and philosophical in nature, right?

(27:40): No one needs to read 37signals.com to, I don’t know, get their pacemaker to work. We’re not operating at that level of criticality. We’re peppering you with seeds of philosophy and insights and bad ideas maybe, but do you know what? That’s a perfect environment to do those things in. And perhaps that’s the thing that annoys me the most about the Apple-ification of design, especially in web applications is not everything have the stakes that Apple needs to deal with where you’re doing a mass market product that has to appeal to so many people in so many different domains that you’re almost forced, as Jason would say, with the pastels into this very specific design. We can have all these pockets that don’t have to carry that weight, that does not have that responsibility to everyone, everywhere, all the time. We’re just like, hey, do you know what?

(28:33): We’re going to make it special because it just doesn’t matter that much or it matters to these people in this different way. And the world is just more interesting when it’s not all fucking gray and white and black and whatever. Crazy colors, flamboyant designs, some of that nostalgia for the earlier web, I think it’s actually just a nostalgia for that. And nostalgia for diversity of design, for wild colors, for a fucking guy that’s digging as that was your underconstruction little GIF, right? That’s just fun. When was the last time you saw something that had that level of fun that you just had a GIF going like dig, dig, dig, dig, dig? We can learn some of that, even if it’s not the exact aesthetic from the past.

Jason (29:13): I’ll add one more thing. I don’t remember the name of this. I was going to look it up, but my phone’s in airplane mode, so it doesn’t make noise. Carlos Segura, who’s one of the original partners in 37signals was famous in maybe in the 90s, I think it was, for a design magazine, and I can’t remember the name of it, but it looked unlike any other magazine you’d ever seen in like text was overlapping, the font was tiny, text went to the edges of the page. So when you open the fold of a magazine, you couldn’t even read part of it. And it got a lot of… Someone’s going to remember this, maybe I’ll remember it later, but it got a lot of flack because it was like, well, it’s kind of unreadable. Some pages, I can’t read them and every page was different and every article was designed custom, unlike traditional magazines where there’s a format, right?

(29:56): You flow text in, maybe there’s a big picture at the top, maybe there’s a little bit of artsiness here and there, but for the most part, it’s all about reading it. And this magazine was not about that. You could read it if you wanted to. You could try to read it if you wanted to. Some stuff you couldn’t read at all, but it was just a statement like, you know what? There’s plenty of magazines that you can read perfectly. This is not one of those. This is an art project. And designers thought it was cool because it was someone saying, well, magazine could be something else. I don’t know. Maybe readability is not the number one thing. Maybe just seeing a page and seeing a layout that’s different than all other layouts is inspiring enough. Maybe realizing that maybe I can make something that’s more about the texture of the page and less about the words, even though there’s words on the page.

(30:36): I don’t really know, but it was a free expression moment and it was really cool. It just always has stuck with me that not everything is about, like David was just saying, our site, 37signals.com. Part of it is the contrast is not perfect in some places. Who gives a damn? I just don’t really care. It’s not about that. And by the way, if you really care, you can read it. If you care, it’s not that hard to read, please. It’s not impossible to read. So if it’s 3% off of what it should be, because this should be darker than whatever, figure it out. I don’t really care. Change it around if you want on your own. Copy the text, paste it somewhere else, read it, whatever. But for the most part, it’s just fun for us. And I think that that’s worth it half the time.

David (31:13): It’s funny because I was just watching 2001, A Space Odyssey on the plane coming here to Malibu. And I hadn’t watched that movie in, I don’t know, a very long time. I didn’t remember the plot at all. And I realized after watching the movie on the plane, why I didn’t remember the plot. The fuck it doesn’t have a plot. There’s barely anything going on for two and a half goddamn hours. And yet I loved it. It was such a wonderful, vivid, vibey, designy experience. Here’s a movie that came out in 1968. And the aesthetic of the whole thing was so far ahead of its time that that was its contribution. Its contribution wasn’t some big philosophical inquiry into even AI, a topic that’s actually quite relevant today that Hal doesn’t want to open the goddamn gates because it’s gone mad, the machine has gone mad.

(32:15): No, no, that wasn’t the point because there was so little there. What was there though was a cohesive aesthetic for what the future could look like. And when you consider the fact that was ’68 Kubrick made that movie, and just how sharp it was. I wish there was more like that. Where you take a medium like film and you do actually a blog post, it wasn’t some artsy, fartsy little thing. This was a major movie that spends 50 minutes at its start, just having some fucking monkeys run around because he wanted to make a point about an opolis that doesn’t even goddamn make any sense when you connect it to the rest of the plot. And he spends 15 minutes just setting the stage, setting the vibe. You’re like, holy shit, that doesn’t happen anymore. None of that exists that we’re just going to take this long prelude, 15 minutes on something that doesn’t even connect to the plot itself.

(33:07): That’s the kind of stuff I wanted. Could we get more of that back? Could we get some 2001 back? Could we get some of this where the point is simply the vibe of it? And I think in its small homage, the 37signals.com site has a little bit of that, right? A little bit of that, that the most important thing is not Jakob Nielsen usability contrast ratios.

Kimberly (33:28): Okay. I think that is a good place to wrap it up. REWORK is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube. And if you have a question for Jason or David about a better way to work and run your business, leave us a video recording. You can do that at 37signals.com/podcastrecording or send us an email to rework@37signals.com.