In short
“Software as art” and how opinionated software can change users’ perspective, not just solve problems.
Guests
Kimberly Rhodes (host); Jason Fried and David Heinemeier Hansson, 37signals co-founders.
Guest backgrounds
Fried and Hansson built Basecamp and related products; they also write and speak publicly about their principles and “opinionated software.”
Key claims
Software always has a point of view (“fingerprint”); art-like framing is persuasive marketing/sales—customers should adopt the product’s worldview. They argue “no” and tradeoffs are essential (e.g., refusing requested features). They start with principles/taste, build first, then distill principles later; they learn and sometimes change their minds.
Notable examples
Basecamp’s repeated refusal to add Gantt charts; Google’s apparent indifference to customer service; “Fisher-Price Easy” as a clarity test; Rails principles emerging from execution; Fizzy as an evolving point-of-view project.
Written by AI. May contain mistakes. Listen to the episode to check what was said.
Chapters
Tap a time to open that second in VOExploring Software as Art
0:45 to 3:18
Discussion on how software can change user perspectives beyond functionality.
“fundamentally, not just help them solve a problem?”
Basecamp's Unique Approach
3:18 to 6:04
The founders share their commitment to a specific vision in software development.
“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.”
The Evolution of Software Design
6:04 to 7:40
How software development evolves from initial ideas to user feedback and insights.
“You get these suggestions from this guy over here.”
Identifying Company Values
7:40 to 10:04
Discussion on how to discern a company's point of view through its products.
“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.”
Fisher-Price Easy Philosophy
10:04 to 11:43
The importance of simplicity and clarity in software design as a guiding principle.
“So your customers definitely notice that point of view.”
Balancing Priorities in Product Development
11:43 to 14:01
How companies make trade-offs between various aspects of their products.
“This is a book that Jason and I both recommended many times.”
Evolving Point of View in Product Development
14:01 to 16:42
Learn how initial opinions in product development can shift and evolve.
“whether you look at 10 or a hundred, like none of them are all just going to sit at 10s.”
The Role of Taste in Software Creation
16:43 to 18:54
Discover how taste and discernment impact software quality and decisions.
“Like, you know what feels right, what looks right, what's off, what's not quite there.”
The Importance of Doing Over Planning
18:55 to 21:50
Understand why action is more valuable than extensive preparation in development.
“And it's like, you have to do something, you have to move something forward and not just prepare to move something forward.”
Learning from Retrospective Analysis
21:51 to 23:19
Explore how reflecting on past actions leads to valuable insights for the future.
“you deal with the problems that actually show up.”
Transcript
Automatic transcript. May contain errors.0:00David Heinemeier Hansson: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. 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.
0:36David Heinemeier Hansson:So design helps you do things better, but art can 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 on to that ideal in the mess of actually shipping features, making it usable and selling it so that people get, okay, I want to pay for that thing because it helps me. Whereas you might have a higher objective of like trying to help change their point of view at the same time.
1:09David Heinemeier Hansson:We'd love to hear David and Jason talk about that software as art. 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? 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's not completely open-ended.
1:47We have a premise that is project management is primarily communication. It's not charts and graphs. It's not burndown 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 charts. 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.
2:25It 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. 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. So if you just go like, well, no, we don't have the features 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 of view.
2:59And 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. That's not always easy because it involves, first of all, saying no.
3:34Someone 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 why. 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 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.
4:16That'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.
4:24David Heinemeier Hansson:So I have a question on that note, real quick. David, do you think, like, which came first, the chicken or the egg? Was it we built the software to lead to how we work or like this is how we work and the software was built around that? Does that make sense? 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.
5:08And sometimes we change our mind. Sometimes we go into the software creation process and think, I believe this thing should exist because this is our view of the world. We built it and we go, do 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, 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. Can we just ask the customer what they want?
5:39And then we write it down and we tabulate it and we count up that 75 people want a Gantt chart and then we build that first and then we build 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.
6:10It doesn't quite fit, right? 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 build. We don't have anything 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.
6:45Not 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 emotion if you're just starting with this blank piece of paper and you're just a scribe. You're just writing down what random other people want and you're asking them what weight even to put in 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.
7:28And 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.
7:39David Heinemeier Hansson: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. It's 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 the response is horrible or whatever, Like that's a point of view. Their point of view is it doesn't matter.
8:11David Heinemeier Hansson: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. If they don't put the energy and effort into that. If you buy a piece of hardware that's just really well engineered, like I've got this, this is a teenage engineering, oops, I don't know. I think it's focused on my face. So I have to kind of hold it back here. Otherwise, this is just like this incredible, object. Their point of view is like 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.
8:49David Heinemeier Hansson: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. 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.
9:22David Heinemeier Hansson:Again, if you make something, 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.
9:57David Heinemeier Hansson: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. Like 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 like pretty easy to figure out, I think, to some degree. So you don't like wonder how things work too much.
10:26David Heinemeier Hansson:But there's other platforms, other things. I know like 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. 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. I do think that it's fun occasionally to think about it explicitly enough that you can identify the key elements.
11:00Jason, for example, talks about being straightforward and being clear. And we came up with a name for that at 37 Signals. 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?
11:40Like there's something you can weigh it against. A great book on this topic is Blue Ocean Strategy. This is a book that Jason and I 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 is 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.
12:13Sometimes the trade-off is, we're going to be shit at 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. In fact, I just saw a Bible treat on X this morning about how a certain icon in Gmail has been fuzzy for like three months. Like the graphic is just wrong. And I thought like, 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.
12:56No one believes that Google is an organization that cares about customer service. And look at Google. Like we think about customer service, like, 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 customer service.
13:32Isn'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 drew a graph of us, like customer service would actually be quite high. We've invested a lot of time and effort into that experience. And then there are other things where Google's just better. They're at a 10. And every company is that mix. You can take however many parameters you want to look at, whether you look at 10 or a hundred, like none of them are all just going to sit at 10s.
14:05That'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? Okay.
14:17David Heinemeier Hansson: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? 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're sort of kind of know what you're maybe going to broadly talk about, but you kind of figure it out as you go and the conversation unfolds as it happens.
14:59David Heinemeier Hansson:So for example, with Fizzy, there are some ideas ahead of time that like I had about what this thing should sort of kind of 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. 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.
15:30David Heinemeier Hansson: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. Like 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 like 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, and I think then you can, in a sense, annotate and write down what they are.
16:11First you feel them, then you do them,
16:13David Heinemeier Hansson:and if they pan out, you write them 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 like 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. That's, I think, how it actually happens. And so that's the more honest point of view on it, I think. This is a theme we've talked about in the past where taste, in this example, is mostly a function of your gut computer. Like, you know what feels right, what looks right, what's off, what's not quite there.
16:49And 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:31Is 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 the 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.
18:09And 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.
18:44David Heinemeier Hansson:I also think it goes kind of back to the point of not spending so much time in the preparation stage. You know, we see a lot of people who are just like 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. 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 people hear that and they go, well, so you don't know what you're going to do?
19:21David Heinemeier Hansson:Like I, 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, like 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.
19:56David Heinemeier Hansson: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 sort of summary of what I actually did. So I'm 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. 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 that filter is very helpful of figuring out, first of all, what's bullshit and what's just wrong.
20:35We 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.
21:13It was like, no, let's just build Basecamp. 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 that. 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 Rather than trying to anticipate them, rather than try to run ahead of them, just lean back and wait.
21:47Like 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 imagine 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're going to have to work on. 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.
Read the full transcript
22:30And 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.
23:07we 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 real software that people give a damn about.
23:20David Heinemeier Hansson: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 slash podcast question. 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 slash podcast. Full video episodes are on YouTube.
From the publisher
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.
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 and Resources:
