SEASON 2 - EPISODE 151 - APRIL 23, 2025

Eat your own dog food

Before anything ships at 37signals, the team puts it to the test—by using it themselves. In this episode of The REWORK Podcast, co-founders Jason Fried and David Heinemeier Hansson talk about the importance of dogfooding, or using your own product before handing it off to customers. They share how this practice keeps them close to the real problems, and sometimes even kills off ideas that just don’t hold up.

Watch the full video episode on YouTube

Key Takeaways

00:27 - Why every 37signals product is used internally before it ships
07:15 - Who makes the final call after internal feedback comes in
12:44 - The importance of building things you’ll actually use
16:48 - Some products and features don’t make it past internal testing

Links & Resources

Transcript

Kimberly (00:00): 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’re going to talk a little bit about a term called dogfooding, which is basically in software using your own product to test it out before you are sharing it with customers. We do this internally at 37signals, so I thought we would talk a little bit about the who, what, when, where, why we actually do this. So let’s start first with the why. I think that’s pretty simple, but if one of you guys want to jump in, why do we actually dog food before we release something publicly?

Jason (00:36): I mean there’s so many reasons. One reason is to know what to build next. As we’ve talked about in previous episodes, we don’t know the next six months worth of work. We don’t know what it’s going to be. We know what we’re doing now and then we build it and we use the thing we’re building while we’re building it. This is for new products specifically. And then we go, this is missing or this is lacking or this is good enough or we really need this. And then you build something and you use it and you go, eh, that didn’t really do it. What else could we do? You just don’t know and that’s the whole point. You don’t know going into it. You have an idea of where you want to go, you get into it and then you don’t know until you use it and then you feel it out and the whole thing.

(01:09): So there’s that. There’s also this sense of this is the best way to figure out if it’s any good and you typically are putting it up against something else you’re already doing because everyone’s already doing something. We’re currently, we’ve talked about this, we’re making a bug issue tracking sort of thing, and we’ve done this in other ways. We’ve used to-do lists, we’ve used Kanban card table in Basecamp, we’ve done it in other ways. Everyone’s doing something in some way already. So what’s nice about building something and using it as you’re building it is to go, is this better than the other way? Are we getting somewhere? Is there something interesting here? And then there’s a point at which when you’re first starting, you’re probably not going to surpass what you’re doing, but there’s a point where you want to get to where it feels like it clicks beyond and you go, now we’re better than what we had.

(01:52): There’s something else here that’s special and you can’t know that until you use it because you’re using the other thing. So you’ve got to compare the two things. And then also just it sparks ideas and there’s no better feeling than using the thing that you’re making when you’re a tool builder. This is the whole reason we’re building this sort of thing and build things in general. And this is true for Basecamp as well. It’s true for existing products, but mostly it’s true for making a brand new product. And I’ll maybe guess what your next question might be, and I’ll just jump in a little bit, but when do you do this? Earlier than it feels like you’re comfortable doing it? You should be building or using the thing you’re building as soon as you possibly can with a few people, and then you slowly layer in more people, but you’re always layering in more people a little bit before you feel like you should.

(02:37): You’re going to say, hey, this is not working the way it should. There’s things that are moving, things aren’t working quite right, this might change, that might change, but suffer through it with us because this is how we’re going to learn what we need to do, what’s missing, what’s there, what’s good, what isn’t. That’s the whole thing. So earlier is better, but I also think there’s a problem with allowing too many people in too early because then you end up with this huge collection of opinions and feedback and that can throw you off too. So I think you want to sort of layer in who’s using it but also be a little bit uncomfortable the whole time.

David (03:11): I think what’s key about using it directly and early is that you have to use real data. It’s not just that you’re using it because you’re trying to poke at it. No, no. You’re using it in anger to get something real done. Whatever the thing that this product is supposed to do, you are doing it and therefore you end up putting in real data. You end up putting in real edge cases and the design just evolves along with it. I remember when designers used to use Lorem Ipsum, like all this Latin googly gob in their designs and you could get paragraphs to line up just nicely and the shape of the text would be derived from how the designers wanted the pages to look like, and then real users started to using it and often it looked like total shit. When you work on real data in the real app, you just don’t get into those dilutions. You don’t get into this mind space that you don’t have to solve for real problems.

(04:16): In this app for example that we were building, we had this thing where there were images behind them. And there was some feedback there where the idea, the concept was really neat and there were some images that worked out really well and then there were other images when you put them in there like it crops a little funny and if it crops it this way, it’s actually not helpful, it’s distracting from the overall thing. Those are the kinds of insights that you cannot just reason yourself into. You have to see real data. Now, the way we work, it’s even more important. We put in real data, we start using it for real, and then designers work on the software directly. They don’t go through this other medium, they don’t go through a bunch of Figma iterations, they don’t go through a bunch of Photoshop iterations.

(05:03): We rush to running software in part so that the design exercise can happen in the real software, against the real materials, against the real data. And when you stretch the real materials, you find exactly where they break exactly where the line is supposed to go. And it’s just a shame to rob yourself of that immediacy of feedback by doing intermediary stuff, by either using fake data or using fake backends or using fake design elements as you would in something like a Figma. The sooner you get to real stuff, the sooner you’re working with something that could eventually turn into the software that you’re going to ship. And this is the other part of it. We rush a running software in part to work with these real materials but also to, as Jason say, to drive the process forward. If you were to sit down as once upon a time in my career did where you try to lay out what is this product going to do?

(06:06): We’re going to make a big index of all the things and we’re just going to work through that list. You very often end up working in a way where you’re either spending too much stuff on things that just don’t matter and end up changing or you end up working just on a bunch of ideas that you had decided about at the outset of the project, hadn’t learned enough about what the project actually was going to be, and then you’ve wasted your time. If you instead just go straight to the real software, to the real data, you’re being driven, the software is just going to take you wherever it wants to go. The next most important thing is in almost all cases, completely obvious, it does not require someone with a geek of brain that can have the entire future of this prototype in their head. They can just go like, what’s the next thing? Oh, we should work on that. And then you get also very quickly, yeah, this is good enough now. I’m not learning more here. Let’s just move on to the next thing. It’s a really pleasant, low ceremony, almost automatic way of working that ends up producing really nice software.

Kimberly (07:14): Okay, so we’ve talked many times that we work in two person teams, programmers, designers, a little bit more than that on a new product. When you start dogfooding a new product and there’s everyone in the company looking at something, providing feedback, who is then making the decisions on what happens next? Is it the programmer / designer on the team? Jason, is it you? Where does that kind of shake out when there’s now all of this feedback coming at you?

Jason (07:37): Well, it’s no different than a product on the market, which is that there’s always more feedback. There’s always more ideas than you can do. And so someone has to make those decisions and it’s all kind of listen to and absorb and then someone makes the call. It might be me, it could be JZ, it could be Jorge, it could be different people, it could be Brian, it could be David, it could be different people, whoever’s sort of running the product or running the show. But also that’s not even really actually accurate because some decisions do sort of filter up to the top to be made in terms of directional decisions. But there are dozens and dozens of daily decisions that are made by the people doing the work. And so feedback might come in that something’s broken or something isn’t lined up or something doesn’t feel right and they might just make some tweaks because they don’t need to ask someone, should I make these tweaks or not?

(08:21): It’s like they know they have a sensibility that, yeah, lemme try that. Lemme see. If we’re going to do a whole new feature or a whole new direction or change something. Some suggestion might come up or it might come down from the top or it might just be batted around and turn into something and morph into something. So decisions are made at all the different levels. I just think it sort of depends on is this directional. For example, starting or stopping on a product given resources that we might have or not have, that’s going to be something David and I are going to do. But deciding if some feature could be tweaked in this way or another way, it could be a decision we make, but it’s often a decision someone else makes. It sort of just does depend. I think what’s important though is not, and this is true about new products and existing products, is not this quote giving the people what they want, in a sense, it’s really understanding what they’re trying to achieve, where they’re trying to go. Everyone wants to get somewhere and then maybe you have a better idea of how to get there than their suggestions. So you don’t want to just implement things just because they’re popular. You want to think about what they’re trying to do and then come up with something that works well if you think it’s a good fit for the product.

David (09:26): What’s key here too is that when we’re not trying to spec everything out in advance where Jason doesn’t have a fully formed vision of every single screen, every single interface element and how that’s supposed to work, you actually gift the people who are working on the product an enormous amount of autonomy. And in that autonomy is job satisfaction. In that autonomy is the person who’s closest to the micro problem also the person who’s making decisions about that problem. Now, occasionally those decisions will get overruled, but that’s rarer than not. More common is when JZ or Scott or any other designer that we have works on something with a designer, they will come up with a great solution that is far more detailed because it’s fleshing out inside maybe Jason’s rough patch idea of where it’s going to be. And that comes partly because they’re really good at what they do, they have really good insights and when you work on the feature directly, you get into a dance with that software and it’s going to take you somewhere.

(10:36): And part of it also comes from that dog fooding. Part of it comes from they’re using the software too. In most cases we built software that everyone inside the company needs to use to some degree. Maybe they don’t use it as much as Jason or I do, but they use it for something. They use it for something real. And it’s amazing how much direction you can get from that interplay. I’m using a thing, oh, this thing’s not quite right, this flow is just not quite right. I’m going to change it. That all comes from the dog fooding. I find more often than not when I encounter truly shitty software, it’s because the people who worked on it, I was going to say don’t care, but I don’t even think that’s it. They can care, but if they don’t need it, if they don’t use it and there’s not a very strong force driving the quality of that, it’s going to end up kind of crap.

(11:32): I think there’s a baseline of quality you derive from something that the people who are working on it also have to use. It can’t just be broken. Flows can’t just be overtly annoying because the people who are working on it will encounter those annoying flows and they’ll fix them. They’ll encounter those bugs, they’ll encounter those features that aren’t optimal. They’ll try something. And if the people who are working on it are actually good at what they do, they’re good at their craft, they’re good at making software, that interplay is going to make good software as a minimum. Maybe not always great software, great software depends on a lot of things. It depends on unique visions and sometimes serendipity and all sorts of other things. But the bar in our industry is so damn low that good software in a well-defined or not even well-defined but in a craving market is typically going to do all right. And it’s also just, it’s just more fun. Who wants to work on something where they can’t really tell whether the thing they’re working on is good enough, if it’s solving the customer’s problems or it’s not solving it because they can’t relate to the problem itself? And that’s all inherent in this dog fooding paradigm.

Jason (12:45): I’m also just going to use a quick chef metaphor. I think a good chef is tasting their food as they go. Do I need to re-season this? What’s the doneness on this? They’re testing things, they’re tasting things, and that’s what we’re trying to do here. We’re not making dishes that we’re not going to eat. We’re making things we’re going to eat. And I think that when you go to a restaurant and you get something like, who in the hell let this out? Who said this was okay? Then you go, well, no one’s paying attention. No one really cares. They know how to maybe cook the dish sort of broadly, but it’s not a good one and no one clearly cares about it. And I think that’s where we’re trying to be a company that’s tasting our dishes as we go.

David (13:19): Lemme just add one thing here.

Jason (13:20): Yep.

David (13:20): Because occasionally we get this wrong. And we get this wrong usually in a way where we’ve designed something that we don’t encounter all the time. A great illustration is the signup process. Jason and I don’t sign up for our products every day. Sometimes we don’t even sign up for it every month or even every quarter. And then when we do, if it’s been a while, we usually go like, oh, what? How did we let this get out? There were just different things that changed or it didn’t keep up with the times or whatever. We were not dogfooding the signup flow, which is the first thing that anyone who’s a new customer will get to see. And I often see that when I sign up for other people’s stuff and I just go like, this is broken. This part of it, I filled this in. How could they, I was just in this e-commerce site, I think it was yesterday and I was going through this checkout flow and it just wasn’t working.

(14:15): I was filling in my like how can anyone buy anything if this part of it is not working? And then I remembered, oh yeah, we sort used to kinda have that. We had a signup flow, I think Jason and I went through our signup flow about a year ago I want to say, and we saw a bunch of thing in that flow where we kind of had to wince a little bit. Maybe this was okay three, four or five years ago, but today, oh, this is our first impression? I’m not proud of that. So dogfooding is not just about new product development, not just about new feature development. It’s a habit. Use the thing you make. And if it’s a part of the product you don’t use all the time, you actually have to force yourself. You have to force yourself. Jason and I should be signing up for our product at least once a quarter, just like whatever new ideas do we have. This is the whole business. The business depends on new people coming in the door. It also depends on existing business, but we will eventually go out of business if we have a crappy signup process. We need to dog food it. We need to kind of just shove it in there.

Jason (15:19): It’s also a good reason to not add things to your product that you’re never going to use. And we always battle this. This is always a difficult thing to do. We added time tracking to Basecamp recently after, we used to have it and then 10 years passed and we finally added it again to the latest version. And we don’t track time here. I think we did a pretty good job of the feature and people really seem to like it quite a bit, but I will admit that we don’t use it. We used it to make it kind of, but not really. And there are going to be things in every product that are like that. I shouldn’t say there are. There probably are. They don’t have to be. But that’s also, you might end up creating your own little island that no one else wants to join you on too.

(15:59): So you’ve got to figure some of this stuff out. And there’s a little bit of give and take. Again, let’s go back to the restaurant. Sometimes there’s some restaurants where you go and there’s no substitutions period, flat out. Other ones you can make a substitution and they’re going to understand that, well, I wouldn’t make it this way. Or let’s say you have a salt thing, you can’t have salt because a chef’s going to want to salt their dish and I just can’t because medically, and they’re like, well, I wouldn’t eat it this way, but I’ll do it for you. There are some things like that. Maybe this metaphor breaks down to some degree cause we’re not making custom software per person, but there are things that we do add that aren’t for us. But if you’re going to have those things, you want those things to be far and few between or few and far between, however you say that versus it just being littered with things that you’ll never see and never use.

Kimberly (16:46): Okay, last question before we wrap it up. I know over the history of the company, we’ve created lots of products, not just Basecamp and HEY but lots of products over the years. Have we ever dogfooded something and then been like, no, we’re not even going to release this product at all.

Jason (16:59): We’ve built things that we’ve stopped using. We’ve built some things, couple things that we launched and then sunsetted. Very few, but Basecamp Breeze is one of those things, which is a mailing list that we built and I think we sunsetted about a year later. It just didn’t really go anywhere. And I think we gave everyone’s money back. You just like, here take your money back. I forget how that worked out, but we’re generous there. And there’s other things we built that in the middle we changed directions significantly. Highrise was one of those things. We first started Highrise, we imagined what we thought people would want and then a few months in, you’re like this just, no. This is too complicated. That’s the other thing. When you build things that you’re imagining other people want, you lose your anchor to the reality of what this thing is.

(17:46): You can make it do anything, but you just lose that sense of like, does this make any sense? Is this just an imagined scenario? Which is one of the real advantages of dogfooding things is there’s something missing here and you know it, you feel it and maybe the thing you come up with the first time is not the thing, but you find your way there to the thing and you know for sure. But yeah, there have been some cases where we built some stuff and it just didn’t go anywhere and features as well. We built a few features in Basecamp that we even spent multiple cycles on that we just backed off on at the end. This just doesn’t feel right or it’s not quite there and let’s just not put more time into it. So it does happen. You just don’t want it to happen that often.

David (18:24): We actually had this happen twice with Highrise. Once before we released the product, as Jason said, we were quite far into it. I thought we spent maybe at least three or four months on a direction that we essentially nuked and started over with a clean sheet of paper, and it turned out to be a wonderfully well-received product that did very well for us for many years. But then when it came time to consider whether we should do a follow-up, Highrise 2, we got quite far into all sorts of different takes on the CRM tool and what we ultimately ended up doing was building HEY. That Jason and I realized, you know what? We don’t do a lot of customer relation management. We’re doing speculative software and we’re doing, we sort of have a big recollection of what it was like to have clients 20 years ago that we’re really tapping into, but that well is quite dry.

(19:19): It has not been replenished with new experiences and new expectations for literally two decades. That’s not a great foundation to come up with something novel with, even though we know there’s tremendous demand for this product. We’ve gotten probably more requests for Highrise 2 than anything else that we’ve ever done in terms of could you update this piece of software? And it’s tempting because we know the market is there. And in fact, the last time we did a comparative analysis of what does the competition look like, maybe there’s just a ton of great competition for Highrise and we’d be wasting our time, we’d go like, no, the competition kind of still sucks. All the other alternative options are still complicated. They’re still enterprises, there’s still all these things. But we said no ultimately, because we went like this is one dry, well. We’re not going to be able to dog food this very efficiently and we certainly aren’t going to be able to dog food it with the rest of the company because as little as Jason or I do customer relation management even less for the rest of the company. So that’s why it ended up not happening. So you can also use dog fooding as essentially a barrier of should I work on this product? I’m sure that Highrise 2 is a good idea. I’m sure that CRM still needs a Highrise type product, but I’m almost convinced that we’re not the right people to build it anymore.

Kimberly (21:05): Okay, well with that we’re going to wrap it up. Rework is a a production of 37signals. You can find show notes and transcripts on our website at 37 signals.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, we’re changing things up a bit. We’d love for you to leave us a video message! Go to 37signals.com/podcastquestion to record or upload a video question for us. We just might answer your question on an upcoming episode.