SEASON 2 - EPISODE 118 - JULY 17, 2024

Scratch Your Own Itch (Replay)

In their book REWORK, Jason Fried and David Heinemeier Hansson write about the benefits of building products and services that you use yourself. “The easiest, most straightforward way to create a great product or service is to make something you want to use.” In this episode, originally aired November 2, 2021, Jason and David sit down with Shaun Hildner to discuss creating products that scratch your own itch.

Key Takeaways

00:43 - The origins of Basecamp and how it fulfilled an internal need
04:38 - Building to solve your own problems vs. someone else’s
06:27 - The evolution of HEY and how it was created to solve their own frustrations with email
09:50 - How building for yourself leads to better quality control
14:25 - The problem with creating MVPs (Minimum Viable Products) and building based on customer feedback alone

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. With summer upon us, we’re taking a little bit of a break from recording new REWORK episodes, but this week I’m digging into the podcast archives to bring back a previous episode that’s still incredibly relevant. In their book REWORK, Jason Fried and David Heinemeier Hansson write, “The easiest most straightforward way to create a great product or service is to make something you want to use.” The 37signals team continues to build products they want to use, and then this episode, Jason and David sat down with Shaun Hildner to talk more about this. This is Scratch Your Own Itch from November 2021.

Shaun (00:43): To start off, let’s go way, way back, what a thousand years or so to when you started thinking up Basecamp. What was the itch you were trying to scratch?

Jason (00:54): Back then we were a web design firm and were doing work for clients and we were doing what everyone else was doing and many people still are doing, which is hacking it, like using email and phone calls and jotting stuff down in different places just to kind of try to keep track of what’s going on as separate calendar perhaps. And when you’re doing one or two projects, you can hold enough stuff in your head really. I mean at some point you kind of can’t, but you kind of can for a while. And then if you start to get a little bit busier and you start to grow a little bit and maybe you bring another person on or you bring another client before long, you don’t know what the hell you’re doing. You don’t know who’s doing what and what’s due when and who’s on top of what and who’s not, and you don’t have the feedback in the right place.

(01:38): Not everyone’s seeing the same stuff and you just kind of lose control and you start to feel like this is getting really hard and your clients start to get pissed and you’re not really putting out an organized image because you’re not. So we started looking around at figuring out what to do about that problem. The tools that existed at the time, there’s only a few, Microsoft Project was the most popular one. It was really more about charts and graphs. It wasn’t about communication. We needed a communication tool to keep all communication in one place and also to communicate updates and schedules and who’s on what and responsibility and all that stuff because that’s also communication. It’s not just data. It’s telling other people things. When you say who’s responsible for something, initially we actually built a blog, like a manually updated blog per project and we would just post new stuff and edit HTML files and post new stuff when there’s new stuff to show a client and gave them a URL, I think with HTTP authentication or something to kind hide it behind a password.

(02:38): If we even did that at the beginning, I’m not even sure if we had a password. It might’ve been just some crazy URL, right? But the thing was, it was working okay now, there was at least a place, one place, it wasn’t sophisticated, but it worked better than what we had before where we had many places and tools that weren’t really right, and then eventually we said we should build something that we actually want to use here that will scratch the itch that we really have and we won’t have to update this manually and publish new files to an FTP server when the new H TM L is ready. Let’s make something. And so that’s what we did. We set out to make something, and it started out, actually, the first feature I think was just the message board because that was the fundamental part of it, which is like we need to communicate and when you post a message, an email goes out, so it’s still sending an email, but at least there’s a central repository in the whole thing.

(03:25): So anyway, it was just something that we desperately needed and we started using it with our clients and our clients started looking at this and go, what is this thing that you’ve made? Or what is this thing not that you’ve made? What is this thing? We’re like, it’s this thing we made, I don’t know. And it turns out that they felt like they could use that and kind of the light bulb goes on over your head and you’re like, ah, there’s a product here, and then we kind of polished up and put it out there and called it Basecamp.

David (03:47): I think what’s so neat about scratching your own itch is exactly where to scratch first. As Jason said, the message port was the thing we built first because it was the most important. This was what gave rise to the whole idea of the epicenter, that when you work on a whole product, there are features that are more important than others, and if you are working on scratching your own niche and solving your own problems, you know exactly what those things are. This is the blessing in terms of almost automatic product management that comes for free when you’re building for yourself because the list of priorities is just very clear. This is what I really need next, so I’ll build that. Versus when you’re trying to build for other people, it’s so much harder because you talk to one customer and that customer goes like, I really need a p and C.

(04:38): Then you talk to another customer, well, I need three, four, and five. Then you talk to a third customer, I need yellow, blue, and red. Now it’s up to you and go, I don’t know, what should we build? I remember from that time reading a writeup about how the Microsoft, maybe it was their office team, they dealt with that and they had this master spreadsheet where they would record all the requests that came in and then they would essentially vote it up like a little mini Reddit they had inside where they would get another request for, I don’t know, italic in footnotes. Okay, well there’s another customer’s requested that, and so that has three votes, right? And I thought, what a miserable way to build software. You’re just computing this all as raw data coming through and whatever gets the most votes is what you’re going to build. Really, that’s how you’re going to come up with a great product is you’re simply going to tally the votes on what people think they want and then you’re going to work on their behest In that regard. It’s like, no, no, no, no. Listen to your customers, absolutely, but you got to do work on their behalf. That’s why you’re the software developer. If they were the software developer, you’d be buying their stuff.

Shaun (05:50): I mean, is that just taking the pressure off of actually having to come up with any of your own ideas if you’re just outsourcing it to your customers?

David (05:58): I think that’s part of it is that you don’t have to have any taste, which was of course the longstanding Steve Jobs joke about Microsoft is that they had no taste, that there was no coherent overarching vision behind the products. It was simply just a grab back of features. Again, clearly that approach can be quite successful. I don’t see Microsoft hurting too bad these days, so clearly that works, but I just always thought it was such a privilege for us to be able to build things for ourselves just that we didn’t have to go through that.

Shaun (06:27): So how had your needs, maybe the needs and wants of the business, but also because it’s a consumer product, how would your personal needs changed in the 20 years when it came around to developing HEY?

Jason (06:39): Well, HEY is a different thing. First of all, it actually didn’t start out as a personal product. It started out as a business product. We were originally thinking about building this for business use, which of course there is a business version, but actually before that it wasn’t even an email thing. It was started out as an improvement. We were trying to redo Highrise, which is our CRM tool. So we started looking at Highrise, we’re calling it Highrise two in our minds, and as we started exploring that, we started with the itch which we had, which was the reason we built Highrise initially was primarily to keep track of conversations we had with vendors, and most of those are happening via email. So we started scratching around the email vendor contact world, and we got to this place where we realized what we were building was not a CRM tool, but actually an email service or an email, not even a service, an email thing, let’s just say an email thing, and it wasn’t fully formed, but we were going somewhere that was exciting and we’re like, I want this for all my email, not just this business email.

(07:39): And we sort of focused then not just on CRM, but really getting back into the email side of it and then we kept figuring out what don’t we like about email? What’s cool is when you’re headed somewhere, when you’re going down some path, you start to ask different questions, and now it’s like, well, gosh, if we can make an email thing, we’re in front of Basecamp all day and we’re also in email all day email primarily for the outside communication, Basecamp for internal communication. So if I’m going to be in front of email all day, what frustrates me about email? Well, one of the things was anyone can email me. That’s actually a fundamental frustration. And so we started to think about that and that’s how we came up with the screener where you can say yes or no to people. If you don’t want to hear from ‘em, you say no, you never hear from ‘em again.

(08:22): Now, other email systems have blocking. You can block someone, but it’s a thing you can do later. It’s not a fundamental flow. So the first time someone emails you in, Hey, you can thumbs up or thumbs down them, and started playing with some ideas around that, and then we got into replying to emails and all these other things, and these are all itches that we were scratching, and we got to ask ourselves, where are all the itches? So we followed the same approach that we did with Basecamp. In fact, I think with hey, the first thing was like, can you receive an email? I don’t think it was even, can you send one? It was more like, can you receive one? That was the first thing, and we sort of built from there.

David (08:59): I think what was so exciting about HEY as well was unlike with Basecamp where we had the realization, oh, it’d be nice to have something sort of soon in advance of building something with HEY. It’s 25 years of itching that has gone unscratched where both of us have been using email. I think I sent my first email in what, 94 or something like that? That’s a long time ago. Over that entire period, I’ve been just sending tons and tons. I mean, it’d be interesting to figure out how many emails have you actually sent? I surely tens of thousands. So you’ve just picked up on so many itches, I wish this was different. Oh man, if we got a chance to make it, I would totally do it like this. Which I think is also why hey premiered as such a quirky, interesting, weird product because there was just so much material.

(09:50): I feel in many ways it was writing rework, so we didn’t sit down to write rework. We had worked on that material for a decade in advance. By the time we sat down to write it, it was more like editing and like, okay, let’s put the greatest hits into it. That’s how I felt a lot about, hey, I spent 25 years making mental notes about how emails should work. There’s a lot of material in the book. In fact, the hard part is picking which one of the problems we want to solve, and then it just even more than base camp, and we live in base camp all day long. I’m in Basecamp all day long, but I’m in HEY longer still. I’m in, hey, literally from early morning whenever I check the first email, probably too early, right until the evening sometimes when I do follow up on things that are mostly a personal nature, but I thought, hey, Basecamp is one of those dominating products you just have open all day.

(10:43): Well, your whole workday and then HEY is your whole workday plus most of the rest of the waking hours that you tie yourself to some form of email. So it has even more of this. It’s just all your own itches to scratch, which makes it feel just a lot of fun to work on. That was the thing. That was the thing with as a software developer, as software builders, I would often think like, ah, why can’t I just fix this thing in Gmail? Do you know what if I just had access to the source code, I could just fix this thing and it wouldn’t be so damn annoying. Now the source code is sitting right in front, so there’s no excuse. There’s something that’s just really bugging me. It’s like just go in and fix it and push deploy in half an hour later, that feature or that bug is solved.

Jason (11:28): One of the really neat things. There’s of course scratching your own itch, which is what we’re talking about, but there’s a deeper level which is actually creating the scratcher, which is like when you make the tools you get to work with every day, that’s even a deeper degree of satisfaction. It’s one thing to scratch an itch sort of that you kind of use occasionally, but when you get to make the tool itself, the back scratcher and you have a lot of itches, it’s really wonderful because you actually have a legitimate impact on your day. And of course the days of hundreds of thousands or millions of others if you have a successful product. But to make your own tools is great. And I think about Sean, we were talking about this before we started, and David’s a fan of watches as well. Really, really, really great watchmakers make their own tools. They actually make their tools first before they make the watches that they make with those tools. And that’s kind of what we’re trying to do, and it’s a really satisfying extra deep level of itch scratching.

David (12:28): What’s funny about this, particularly with HEY, so we’re scratching our own itch on the product side, but exactly as Jason said, to build HEY, we had to build so many tools. We built so many tools. All of Hotwire are a new approach to front end development came out or came together as part of building HEY. So many of the advances in Ruby and Rails over the many years have come straight out of the products that we really go down, not just building our own tools, but figuring out our own unique screws that fit into this. And then you got to come up with the screwdriver and there’s just such a satisfaction in going all the way down and knowing that you have the power and the capacity to deal with any of it. And this was one of the big things I think has been a theme at Basecamp over the years, particularly on the product development side, this idea that we’re tool makers.

(13:19): We don’t just take other people’s tools and put those together in variety of ways. Sometimes we do. Obviously it’s not like we built everything from scratch. I’m not sanding down my own silicon and building my own chips and whatnot, but at a certain level of abstraction, we always keep the door open that if those tools that are on the market are not good enough, no hesitation in building our own. Which is funny because in much of the tech world, that is the righted a bit as not invented here, and I’m sympathetic to that, but also not really in the sense that if you can invent, if you have the capacity and the competence to do it, where so much of the satisfaction is I get as much satisfaction in many ways out of building the tools that makes it possible for us to build HEY as a gift from building HEY. And then when you take both of them together, it’s just like the galaxy brain explosion.

Shaun (14:12): One of the examples you use in the book is the Mary Kay Wagner using her own cosmetics. You talk about the importance of being able to assess the quality of what you’re building. If you’re scratching your own itch,

Jason (14:25): Judging quality by proxy is hard. So this is one of the hard things about doing client work. Let’s say you’re a development shop or whatever and someone asks you to build a product for them and you work with them to build a product, but it’s a product that you’re not ever going to use. Not only is it something you’re not going to use, but you don’t even necessarily understand. It would be like if someone asked us to create a medical records system, we could do it. I’m sure we could do it, but I wouldn’t know if it was any good. I don’t know what it’s like to be a doctor. I don’t know what it’s like to have a patient in the room with you. I don’t know what it’s like to have to look up what kind of data would you be looking up?

(15:00): What kind of information would you like to see? Now you can interview doctors and you can do all that stuff, but you’re still a degree or two away from actually understanding at a fundamental level what you need and what’s good in the scenario that you’re in. Again, you can research forever, but it’s still not direct experience, and I think direct experience really helps you evaluate whether or not what you’re making is going to be useful. Without question, I think that’s the biggest thing. Without question that this is going to work for what you need it to do, you don’t need to ask anyone, is this what you meant? Is this what you thought? Is this what I understood you to mean or is this what I heard you say? It’s like, no, I know this is what we needed to do. So that’s the thing that’s great about building something that you’re going to use yourself is that you have answers to questions that you might never actually be able to really truly get from somebody else. Again, it’s possible, certainly possible, and there’s great products built by people who don’t use them, of course. I just think you have a leg up, you have an advantage if you’re the one who you’re building for,

David (16:07): And that difficulty I think explains so much of why the history of software development is a history of huge failures because so many large systems, particularly government systems or medical records systems or something else like that are built for other people where you’re trying to fumble around in the dark and just hope that you stumble across something that just barely works. There are just so many large IT projects that simply fail and after years of development, they just go like, actually, we’re in a dead end here. We got to scrap the whole thing and start over. That would not have happened if you somehow could empower the people who knew what a good system looked like with the capacity to build it, but you can’t. So I think this is, again, the word privilege really applies here. Such a privilege when you get to build your own stuff, not just because you’ll get the satisfaction of doing it.

(17:05): As we just talked about, the satisfaction building your own tools and your own tools for those tools is very high, but also just the likelihood of success. I think of this all the time. When we look at the number of features that we start building that we end up shipping, we have a whatever, 98% ship ratio, something like that. We were just talking about this the other day and we were thinking what was the last major thing that we built that we didn’t ship, and I think it was two or three years ago, and it was something called, we called Client Side 2.0, which hilariously failed because we were building it for other people. We were like, we don’t actually do client work anymore. We’re fumbling a bit in the dark. We’re trying to remember what was 20 years ago. And I mean, we made the second mistake, which was to call it 2.0, which is the worst thing we can ever call any software project in the history because that’s the second system syndrome where all your hopes and dreams goes to die. But that was the last major thing where we were like, we spent full six weeks and we did the hard thing, the hard shape up thing. It wasn’t ready. We had even given it. I think we gave it one half go or something, and it still wasn’t ready and there wasn’t a path to getting ready, and we said, do you know what? We’re just going to flush it. So that kind of efficiency, that shipping rate is just quite unique thing when it comes to software, and I think if you can have it, wow.

Shaun (18:32): Yeah. Well, both of you have experience building things for others. I wonder if you can talk a little bit about that, Jason, 37 Signals was a web design firm and you had clients that you needed to build for, right? Yeah. And David, you were hired on to build Basecamp to sort of scratch 37 signals itch.

Jason (18:53): We definitely did build things for other people, and as I mentioned, you certainly can. There’s lots of great consulting firms and product design firms that do build great products for other people. I just think there’s an advantage if you’re building it for yourself, but it’s certainly possible. I remember David and I worked together. I think the first project we worked together on for a client was something called Summit Credit Union, which was a credit union intranet, and I did the UI and David did the backend. The guy who was running the project for Summit gave us a sense of what they thought they needed, but I think we kind of cheated in that. We’re like, what would we want in an intranet if

Shaun (19:33): We were a credit union?

Jason (19:35): Well, what do I want if I’m working with other, I want to be to look people up and I need to download these forms. We asked some questions about what are the things people tend to do, and then I think we kind of decided to do it in a way that wasn’t what they said, but was what we thought you would want. Was it any good? It lasted for a long time and I think it was quite good, but again, I don’t know for sure. Again, you’re getting feedback by proxy. You’re learning about what other people think about something through somebody else. It’s always one or two degrees removed and in the game of telephone, the message is always distorted at some level. The other thing is is that some people can’t really explain what they want because that’s not how they think. They don’t think about how to explain what they want or they’re not good at explaining it, or they are good at explaining it, but they don’t take the whole system into account like, well, we could do it that way, but then that prevents us from doing it this way, and that’s going to be confusing in this scenario.

(20:36): So it’s very hard to hold all the possible scenarios in your head if that’s not what you do for a living, first of all. And also if you’re just asked on the spot, it’s hard sometimes to really explain it, and then if you’re going only on what other people can tell you, the fidelity of that feedback is fundamental to what you can build. And if it’s not great feedback or people aren’t really sure how to explain it, that’s the source material you have to work with, and then it’s hard to really get somewhere. Great. I think with that. Anyway, that’s a little bit of a riff on it. I would say

David (21:08): This is why I’m not in full alignment with the whole MVP movement. Yeah,

Jason (21:14): I don’t like it either. That

David (21:14): All you have to do is build the minimum thing possible, get something in front of customers, and then they’ll tell you what you’re supposed to build. Sorry, what is this MVP movement?

Jason (21:25): It means minimal viable product.

David (21:27): Yes. Well, that’s what it stands for, but the cartoon that goes with it is even better. The cartoon is like, Hey, instead of starting with you want to build a car, you shouldn’t start with a steering wheel and a prop shaft that doesn’t do anything on its own. Hey, come up. What you’re actually working on is mobility, and if you started with a skateboard, you’d have something useful and then people would tell you how to morph that into a scooter or whatever, which it was a very, I think, impactful graphic that actually made no sense when you thought about it more deeply, which a lot of graphics are like that, but that’s why that doesn’t really work, that this idea that you can just iterate your way into a coherent vision. I don’t believe that’s true at all. I think if you look at most of the defining products out there, they don’t come from that background.

(22:15): They don’t come from let’s just build the minimum viable thing and then let the committee run it from here. They come from someone who thought about the problems very deeply, and sometimes that can be done by proxy. It’s very hard, and the odds of you hitting on greatness is much lower. But if it comes from scratching your own itch, hey, you can build something complete together. And I think that was Jason. You put it in the way with Hey, where we thought, do you know what B one is not going to be a minimal viable product. It’s going to be a great product built for me or us. And then from there we can talk. We hear the feedback because I think the problem with MVP two is when you barely have to think defined that it doesn’t really have a hard shell. It’s so easy to twist it in a thousand different ways, and you’ll get all this feedback and you’re like, well, should we take in this direction?

(23:04): Should we take that direction? I don’t know. Both sound equally good. There are people advocating on either side. How do I even decide? I think that’s healthy. Have something with a strong vision, or if you can have something with a strong vision, it’s much easier to adopt and know what to say no to. All feedback is not created equally. It will not all flow into a beautifully cohesive product as we often would say, we’d give a thousand feature requests, and if we implemented all those thousand feature requests from everyone who requested it, every single one of those requesters would hate the final product. This is the Homer car syndrome. You just listen to consumer feedback and you end up with like, Hey, everyone’s request is in there and the final product is total shit.

Jason (23:46): I’m not sure if we’ve talked about this so far in the book, but we often reference chefs and food analogies, and I’m going to try one here because the MVP concept has never made sense to me either because it’d be like baking half a recipe of bread. It’s like you can’t do that. You have to make the recipe to evaluate whether or not it’s any good. You can’t be like, if I just mix flour and water, why don’t you taste that and tell me what I should add next? It’s like, that’s not how it works. You can’t do that. You need to do the whole thing, and then you can evaluate whether or not it’s any good. So I think you need to make the whole dish. You can make a simple version of the dish, but it needs to be like the whole dish.

(24:29): It can’t be a partial dish. And then ask someone, what do you think? Because that’s not what you’re selling. You’re not selling partial dishes, you’re selling a product and a product has to do what it needs to do as a full product. It can be a simple version of that product. It can be a very light version of that product, but it needs to be the whole thing and not just a piece of which someone can then imagine and fill in all the blanks about all the other things it can do. It just doesn’t work that way. So I’m not a fan of the MVP approach either, even though it’s pervasive. I mean, it’s everywhere in our industry and it’s been taken as gospel. This is the way to do things, and it’s always fun to push back on that, but people sometimes just are so indoctrinated in that point of view that they can’t imagine any other way than just to build a partial thing and show people and expect that they’re going to tell you where to go next in the right way. It’s a strange approach, but it’s common.

Shaun (25:27): Well, let’s end with one of the side effects you mentioned of scratching your own niche and building for yourself is that you get to fall in love with what you’re making. Can you talk a little bit about falling in love with Basecamp or HEY or any of the other products that you’ve been

David (25:42): Making? I’ll talk about it actually from the opposite direction first, which is…

Shaun (25:47): I hate Basecamp

David (25:48): Not about Basecamp, but when we were building for other people, I would occasionally get enamored with something we would come up with, and then the customer would come back and say, no, actually no, that’s not what I want. I want this other thing. And I’d go like, no, no, no, no, no, no, no. The thing is good. What you’re proposing makes no fucking sense. You’re going to make it worse. And this was one of the reasons I was not well cut for consulting work because that’s what I mean. You’re making something for other people. So if they tell you straight to your face, that’s not what I wanted, here’s what I want instead, you’re supposed to go thank you for the information. And I would go like, oh, fuck. Can you get out of here? Let me just build my perfect thing in my vision of the, and that’s of course not what the arrangement is, but that’s what this arrangement is.

(26:34): That’s what Basecamp is, that’s what HEY is, that we got to build the thing as we wanted to build it, and we got the power to say No, this was something else That crucial, particularly early on, was that we didn’t have any individual customer be able to tell us what to do. We didn’t have these mega clients, mega contracts where early stage software in particular get the great misfortune of landing a huge account that has so much power over them that their software almost turns into consulting wear, and now they’re constantly following up with that client. The client keeps telling them what to build, and they go, I can see how maybe that makes sense for you, but it doesn’t make sense for the broader product. But they feel like they have to. From day one, Basecamp had hundreds of customers. I don’t know how many signed up on day one, but it was probably more than a hundred. And then after a few months it had thousands, and after that it had tens of thousands to the point where no individual contract or sale could determine where we were going to go. And that just gives you an incredible amount of freedom to really follow our vision through and stick with it and go, do you know what? I can say no. And it can cost us some money, but it won’t cost us all the money. It won’t risk the existence of the company. That sense of freedom is intoxicating.

Shaun (27:53): We have a big whale using Campfire.

David (27:55): Yes, it was Twitter. Yeah, that’s right. It was Twitter. The only whale we’ve ever had in the history of Basecamp was Twitter using Campfire. And it was funny, we found out, because this was years after, I think we’d even stopped selling Campfire. We found, where’s all this resource consumption coming from? Oh, there’s one account that’s accounting for basically 40% of all usage of it, and it was Twitter, and they were paying us something like $99 a month for us to spend thousands of dollars on infrastructure to service them. And we went like, do you know what? This doesn’t work. So we actually, we ended up giving them the fuck you price, which was like, I don’t know, let’s fucking just charge them five grand a month. They probably don’t want that, so they’re probably going to leave. So I wrote, I forget who it was, but I wrote like, Hey, now the price is five grand a month.

(28:40): And they went like, okay, sure. And I went, fuck, we should have charged 50 grand a month. Clearly. But the problem was as soon as it was five grand, I felt an obligation. It wasn’t even something they asked for, but I personally felt an obligation that I had to be their account manager. So now this person had a direct line and I felt like, ah, they’re fucking paying us five grand a month. I got to answer this, and I actually got to fix whatever is bugging them. And I was like, I don’t like this arrangement one bit. Oh my God, I’m so happy we never had to do that. And this is a beautiful reminder of why we should stick to those guns since that we don’t end up with single customers who are half the revenue of an entire product.

Shaun (29:19): Right. Jason, do you want to say anything about falling in love with the products you make? No. Okay. Well this is a great place to end.

Kimberly (29:28): We’ll be back with new episodes of REWORK in just a couple of weeks. Until then, you can find show notes and transcripts on our website at 37signals.com/podcast. And check out our new Rework shop from T-shirts to motivational mugs. There’s something for every Rework Fan. You can find that at 37signals.com/podcastshop.