SEASON 2 - EPISODE 159 - AUGUST 6, 2025

Software as art

This week on The REWORK Podcast, 37signals’ co-founders Jason Fried and David Heinemeier Hansson explore a listener question about approaching software as art. They discuss the importance of having a point of view as you’re building products.

Watch the full video episode on YouTube

Key Takeaways

00:15 - Great software helps customers see things from the creator’s perspective
07:31 - A company’s worldview comes through in the product
14:09 - Your product’s point of view evolves as it takes shape
18:35 - The creation process is meant to stay flexible
20:05 - Solve one problem at a time to maintain a clear development flow

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 knocking out a customer question. This was a video question from Luke.

Luke (00:15): Hi guys. I’m building a tool that’s not just about making a broken process better and trying to help people see the whole situation differently, and I keep coming back to this idea of thinking about software as art rather than design in the way that art can change how you actually see or think about the world, not just how you do things. So design helps you do things better, but art could actually change your perspective entirely. So what I wanted to ask is have you guys ever approached software development in that way as something that can actually change a user’s perspective fundamentally, not just help them solve a problem, and then if so, how do you hold onto that ideal in the mess of actually shipping features, making it usable and selling it so people get, okay, I want to pay for that thing because it helps me, whereas you might have a higher objective of trying to help change their point of view at the same time. Would love to hear David and Jason talk about that, software as art.

Kimberly (01:13): So this is an interesting premise, thinking about software changing someone’s perspective versus just solving a problem. Have you guys thought about it in that way at all?

David (01:23): I think the art framing is interesting. I hadn’t thought about it in that term, but I certainly have thought about changing people’s minds with the software that we built and that has been true right from the get go. When we first launched Basecamp, we thought, do you know what? This is a system that has a point of view, it has a certain approach to project management that is not completely open-ended. We have a premise that is project management is primarily communication. It’s not charts and graphs, it’s not burned down mechanisms. It’s not all of these other tools that are common in the project management space. We’re not going to do any of them. We’re not even going to do them if a thousand customers ask for it. In fact, perhaps the most rejected feature in the history of Basecamp is the Gantt chart. We got probably dozens of requests for the Gantt chart the first week Basecamp launched, and in the 20 years since we have probably gotten thousands at this point and we’ve refused to do it. It does not fit within that initial premise of project management is primarily communication and that’s a way of taking a stance and saying, this product is for these things.

(02:36): It has this mission, vision, point of view, and sets of principles, and the other side of it is then trying to convince someone that that’s compelling. If you just go like, well, no, we don’t have to feature you’re asking for, go look somewhere else. Well, I haven’t taught them much, right? I want to actually be persuasive. I want to get someone to see things from my point of view such that they may appreciate the software I’m building from that point view, and that’s what we’re doing right here. That’s what we’ve done in our books, that’s what we’ve done in our writing. That’s what we’ve done in all the public appearances that we’ve done, is essentially try to persuade someone that the software we built is built from our perspective. If you see the world from our perspective, at least for a little while, you may come to appreciate why the software is the way it is and not just appreciate it, but realize that this is exactly what you’ve been looking for, even though you didn’t know it.

(03:28): That’s not always easy because it involves, first of all saying no. Someone comes to you with a request and says, I would like to pay you money if you did X, and your answer will then be, well, I understand perhaps why you want X, but let me tell you about Y. Let me tell you about the fact that we don’t have X and maybe I can persuade you. That dance is the essence of selling and that positioning is the essence of marketing. So I don’t think we actually have to dress it up in fancier terms than that. I don’t think art is perhaps a little too fancy. I think good marketing, good salesmanship already have these qualities of trying to get a customer to see the world from your perspective because that’s where you built the product. That’s what it’s optimized for. The more the customer can be persuaded to think like you, the more they’ll come to appreciate what you built.

Kimberly (04:24): So I have a question on that note real quick, David, do you think which came first, the chicken or the egg? Was it we built this software to lead to how we work or this is how we work and the software was built around that? Does that make sense?

David (04:41): It’s mostly the latter. It’s mostly that we built software to fit our worldview and what we prioritize, but it’s also a continuously evolving process. We will build a little bit of software from a perspective that we already have and then we’ll learn something new about the world. We will learn through the creation of software, what we actually value, what actually works, what actually supports the underlying values and principles that we hold. And sometimes we change our mind. Sometimes we go into the software creation process and think, I believe this thing should exist because this is how I view the world. We built it and we go, you know what? That’s actually cumbersome. That’s actually inconvenient. That’s not how I want things to be. So then you change your mind. You have to be open for that process to roll. But I do think it’s easier if you start with a set of opinions.

(05:30): If you start with a view at the world, you don’t just start with a blank slate and go, I wonder what the customer wants. Could we just ask the customer what they want? And then we write it down and we tap related and we count up that 75 people want a Gantt chart and then we build that first and then we built the second thing on the list. There’s software built like that. Most of it is deeply uninspired. Most of it is not cohesive at all because it doesn’t come from a fully formed vision of the world. It comes from all these fragments and you’re trying to piece the whole picture together from individual fragments that were created in different minds, spread out all over the place. You get these suggestions from this guy over here, you get these suggestions from her over there. It doesn’t quite fit, right?

(06:12): I think this is why we have this affinity towards version one being for us, that everything that we built, we built first and foremost for ourselves is that the vision can at least be cohesive with the image we have in our head. Now again, the vision evolves as we built. We don’t have everything perfectly mapped out how everything should work, but we certainly set out with a direction. We’re going to go over here towards that. Along the way we’re going to learn a lot of things. We might change a few degrees one way or the other. Sometimes we’ll end up going 180% the other direction, not that often, but it happens. But ultimately you have to want something. You have to want the world to be different in some way. You have to be dissatisfied with the status quo, and it’s difficult to conjure up the demotion if you’re just starting with this blank piece of paper and you’re just a scribe.

(07:03): You’re just writing down what random other people want and you’re asking them what weight even to put on their suggestion. They say they’re willing to pay for that, but will they actually pull out the credit card when the form pops up? Very unknown, very often not. To proposition someone with something compelling, I do feel like it is more likely to happen if you honestly believe something about some things, and that belief says, these things are good and we want more of that. These things are not so good and we want less of that. And somewhere in between there’s a product that we can ship and sell.

Jason (07:39): Yeah, I agree with all that, and I’ll take just a different approach just to broaden it a little bit, which is I think everything has a point of view, and even if you don’t know it, it’s there. And I’ve actually really come to enjoy trying to figure out the point of view of a company whenever I see their product because it’s in there. It’s like a fingerprint. Everything has it. So for example, if you buy something from a company and you have a question and you write customer service and you never get a response or their response is horrible or whatever, that’s a point of view. Their point of view is it doesn’t matter. Customer service doesn’t matter. We don’t really care. Now, they didn’t probably say we’re a company that doesn’t care about customer service, but they’ve demonstrated that. So that is their actual point of view.

(08:22): If they don’t put the energy and effort into that. If you buy a piece of hardware that’s just really well engineered, I’ve got this, this is a teenage engineering, oops, I dunno. I think it’s focused on my face so I have to kind of hold it back here, otherwise. This is just this incredible object. Their point of view is they care about design, they care about materials, they care about the way things feel, they care about the weight, they care about the fact that the back of this is leather and the leather is slightly textured. That didn’t happen by accident. There’s a point of view here, and I always find it enjoyable to try to dissect that point of view and begin to understand the company a bit more. So everything has a point of view attached to it, and I think for this question, it’s going to be represented one way or the other, but you can be more explicit about certain points of view that you have and you can make sure that people do notice those.

(09:12): So there’s some things people will absolutely notice and there’s some more subtle things that they won’t maybe notice initially but will eventually notice. And so I don’t think you can make something without a point of view. Again, if you make someone could go, well, this is a super bland to-do list. It does nothing. That’s a point of view too. The point of view is like maybe color doesn’t matter and excitement doesn’t matter and joy doesn’t matter and this should be pure utility and that’s not a bad thing, by the way at all, but it’s definitely the point of view is represented through the ultimate execution of the thing. I’ve always enjoyed looking at everything that way and I’m enjoying it more and more because there’s so many interesting products out there and so many different companies doing different things that you can learn a lot about what this company values based on what they actually produced and what they focused on and what they didn’t.

(09:57): So it’s always in there, I would say, and don’t think that you have to think about doing it. What you can do is think about what parts you really want to communicate very clearly, so your customers definitely notice that point of view. I think for us historically, we’ve tried to make things straightforward. How straightforward can we be about this thing? How obvious can this thing be? That’s something that we think is important in software, not always, but for most things it should be pretty easy to figure out, I think to some degree. So you don’t have to wonder how things work too much. But there’s other platforms, other things, I know David’s get big into Linux where it’s not necessarily easy to learn and easy to understand initially, and there’s a value there too. The value there is like customization and making something, dialing something in exactly as you want it. You can’t do that in things like Basecamp as we don’t put that kind of product out there. We put a different kind of product out there, but each one has its own unique point of view, even if you, again, don’t explicitly think of it that way,

David (10:53): I do think that it’s fun occasionally to think about it explicitly enough that you can identify the key elements. Jason, for example, talks about being straightforward and being clear, and we came up with a name for that at 37signals. It was Fisher-Price easy. That was the mental image. We were always thinking like, is this Fisher-Price easy? It’s a good bouncing ball to have where you can test whether what you’re currently working on actually lives up to the point of view you want to have. Occasionally, accidentally you will get a point of view into the product, but it won’t always be considered. And sometimes we need a little reminder of where are our aspirations, what would we like to communicate? And if you have phrasings like that, is this Fisher Price? There’s something you can weigh it against. A great book on this topic is Blue Ocean Strategy.

(11:45): This is a book that Jason and I have both recommended many times. It’s one of the very, very few business books that I recommend to people because it offers a lens on the world in exactly the way Jason’s talking about, trying to analyze why does this thing work. What is the point of view that this company have, what do they value, what do they don’t value? Because Blue Ocean strategy talks exactly about that mix. You can’t be the best at everything. That’s just delusional. You always have to trade off. Sometimes the trade off is we’re going to be shit on customer service. That’s just unimportant to us. I often think about Google when you mentioned that, Jason, is I don’t have a picture of Google in my head of someone I want to write an email to. Even if I find an egregious bug in Gmail, I’m not going to write an email to them about that.

(12:32): In fact, I just saw a viral tweet on X this morning about how a certain icon in Gmail has been fuzzy for like three months. The graphic is just wrong. And I thought, do you know what? The only way it’s possible that that bug stayed that obvious in Gmail for three months is because no one believes Google would actually listen to them if they wrote them directly. No one believes that Google is an organization that cares about customer service. And look at Google, we think about customer service. Look, well, every organization has to be customer first and customer focused and offer great customer service experience. No, they don’t. No, they don’t. Google is a phenomenally successful, massively profitable, hugely valuable corporation that does not give one shit about customer service. They’ve optimized for other things. They’ve actually managed to create something extremely compelling despite the fact or maybe in service of the fact that they don’t care about the customer service.

(13:32): Isn’t that fascinating? Isn’t it fascinating that if you drew the graph of what Google cares about, like customer service would literally be at a zero or maybe a minus five and you could draw a graph of someone else. I’d like to believe that if you draw a graph of us, my customer service would actually be quite high. We’ve invested a lot of time and effort into that experience. Then there are other things where Google is better, they’re out of 10. Every company is that mix. You can take however many parameters you want to look at. Whether you look at 10 or a hundred, none of them are all just going to sit at tens. That’s just impossible in this universe. They’re all going to have a wave, and your job to some extent is to figure out which wave do you want? What do you want to be really good at, and what are you willing to sacrifice?

Kimberly (14:17): Okay, so I’m curious about new product development. We’ve talked about, we’re building a new product called Fizzy. David, you’ve been working on some things, this idea of having a point of view. I always hear you guys saying, we make opinionated software. Are you guys starting from the beginning? Like before you create anything, before you go into any design meeting, is there already an opinion or is that opinion and point of view being formed as you’re going along?

Jason (14:44): I’ve been thinking about this in general, not this, but this other idea I’m going to share, which is like, I kind of think most things are more like a conversation where you kind know what you’re maybe going to broadly talk about, but you kind of figured out as you go and the conversation unfolds as it happens. So for example, with Fizzy, there’s some ideas ahead of time that I had about what this thing should sorta kinda be, but actually a lot of those changed along the way. It’s not like the point of view you have at the beginning has to be the point of view you have at the end, but as you begin to use something, you begin to develop more of a point of view on it. This is good, this is bad. Oh, this is an interesting idea. Oh wow, this didn’t work as I thought it would work.

(15:22): Can we make it work? Actually, no. Or yeah, maybe we can if we keep playing with this some more, but this idea is really essential to the whole thing and this is kind of how this should be, but we don’t know how to do it yet. These things tend to evolve and unfold, but you can still have a point of view on broadly, you can have a set of principles that you draw from. But what I would say is, and David can correct me, I know there’s a set of principles for Rails for example. He didn’t start by writing the principles. The principles are like in him and they’re expressed through the execution of this idea and then they’re distilled later in a sense and written down once they’re fully formed. But you have to make the thing for these things to come out and be represented fully.

(16:05): And I think then you can in a sense annotate and write down what they are. First you feel them, then you do them, and if they pan out, you write ‘em down. That’s kind of how it feels to me. It’s almost like writing down these are the things that are important in our culture and then trying to live up to those things versus living up to the ideals that you have that you feel like are right and then revealing those by writing them down later. I think how it actually happens. And so that’s the more honest point of view on it I think.

David (16:35): This is a theme we’ve talked about in the past where taste in this example is mostly a function of your gut computer. You know what feels right, what looks right, what’s off, what’s not quite there. And that all comes from the collective sum of your experiences and your exposures and your opinions. I do think you can cultivate that taste, you can develop that taste, you can develop an eye for seeing things that are just right or not there. And it’s through that process of cultivating your taste buds, cultivating your eye for detail that you eventually will figure out, well, this is where we’re going to go. And then as Jason said, you extract and you rationalize and you articulate in words after the fact. I always look at a piece of code and I have this reaction of like, is it right? Is the weight proportionate?

(17:31): Is there too much complexity for what this is trying to do? Is there too much line noise or too many abstractions? Now once I’ve had that reaction, that’s all coming from the gut computer, I can start to articulate and go like, well, this is actually why I believe those things. But it’s always later stage. What comes first is the implicit, and then what comes second is the explicit. Having a commitment to developing that taste though I do think it’s a choice. And having the courage to have taste at all, because taste means discernment. It means saying no to a bunch of things, or it means saying not good enough. And that includes sometimes a little bit of conflict. If you’re saying no to things that customers for example would like or your colleagues would like or whatever, you’re inviting a little bit of friction, a little bit of conflict, you need to develop some courage there to believe that your taste is actually important in the development of your product. If you want something that feels cohesive, it has to be a reflection of that taste. Even as you develop it along the way, even as you may change your mind along the way, it has to be a commitment to the fact that it matters.

Kimberly (18:44): I also think it goes kind of back to the point of not spending so much time in the preparation stage. We see a lot of people who are just writing all the rules before they do anything. And it’s like you have to do something. You have to move something forward and not just prepare to move something forward.

Jason (19:02): Yeah, there’s something in my view, there’s something false about getting ahead of yourself by writing down all the things you’re going to do later. There’s something true about doing the things and then writing down what you did. That’s kind of what it is for me. And people hear that and they go, well, so you don’t know what you’re going to do. I kind of do and I kind of don’t, but I know where I want to start, I think. And from there I just keep going and make it up as we go and figure it out as we go. Like you do in a conversation. We don’t sit there and go, we need to plan all the words out in a conversation. You don’t go like, we’re going to talk about this topic for 6.2 minutes and then that’s going to end. And then for the next minute and a half, you don’t do that. Yet we can all have great conversations. So why is it that we have to think everything through ahead of time for other things? I just think more things should be like that. More things actually unfold. And then you can review what you said and think about, oh, I can distill this down into these points that are a good summary of what I actually did. We just way more interested in what you did, not what you’re going to do. I don’t really care, frankly, actually what you’re going to do.

David (20:14): I think this is also the great bullshit filter. There are a lot of people who can sit and spin their wheels and spin their mind imagining things. There are far fewer people who can put those imaginations towards reality and come up with something. And I think that filters very helpful of figuring out, first of all, what’s bullshit and what’s just wrong. We can delude ourselves all the time into thinking that the ideas we have in our head are just these amazing, precious things. And then you actually try to put it into the world and you go like, well, that’s all wrong in all these ways. So it’s really helpful for yourself and it’s really helpful for others. And this is why I think credibility is built by doing not just built by pontificating. It’s not just built by talking. And if you look at the artifacts we’ve put into the world, both on the technical side, Ruby on Rails, 100% extraction. None of this was like, let me get the schematics ready for how we do Basecamp in Ruby and let me get that all sorted out was like, no, let’s just build Basecamp.

(21:15): And along the way, we’re going to need different things. And when I need a hammer, I’m going to build a hammer. And when I need a two by four, I’m going to find a way to procure it. I don’t even know what shape any of it should take yet. And the great freedom and release in trying to do that is you don’t have to be all that clever. The problems will present themselves to you. And when they’re right in front of you, it’ll be the easiest moment to solve them, rather than trying to anticipate them, rather than try to run ahead of them, just lean back and wait. There will be plenty of problems coming your way if you try to solve anything and you deal with the problems that actually show up. This is the other challenge. If you try to preempt and front run all of the problems you imagined that could arise, you’ll end up solving a ton of problems you’re never going to encounter in reality and not deal with the bunch that you are going to have to work on.

(22:11): And that’s how you can just waste a ton of time. So if you instead commit to being a little loose, being just directional, not as specified, you’ll just be using your time so much better. You’ll just be applying your talent and your attention to just what’s right in front of you. And you know what? If you keep doing that, keep solving just the next problem and then the next one and then the next one. That turns out to be a straight path to release, to publishing, to getting something into the world without all the other stuff around. So the books, everything that Jason and I have written has essentially been extraction. Here are the two of us looking back upon decisions that we made, how they panned out, what lessons, if any, we can take away from it. I’m going to share some of that retrospectively, not forward-looking. We don’t have any crystal ball. We can’t tell you what might work in your situation. We can tell you what we did and when we look back upon that, what we thought about the important ingredients to that decision, just like we can release software tools that we’ve actually used to put real software that people give a damn about.

Kimberly (23:20): Well, with that, we’re going to wrap it up. Luke, thanks for sending in your video question. If you have a question for Jason or David, we would love to hear it. You can upload or record a video on our website at 37signals.com/podcastquestion, and I will send you some REWORK swag if we end up using your question on a future episode. REWORK is a production of 37 signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube.