Deep Dive
Shownotes Transcript
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 Freed and David Heinemeier Hansen. 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 when you guys want to jump in, why do we actually dog food before we release something publicly?
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. So there's that. There's also the 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.
Like we're currently making, we've talked about this, you know, we're making like 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 that 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. 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. Like 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
Like, when do you do this earlier than it feels like you're comfortable doing it? You should kind of 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. 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. 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're 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 googlygog in their designs, and you could get like paragraph to line up just nicely. And the shape of the text would be derived from how the designers wanted the page 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 delusions. You don't get into this mind space that you don't have to solve for real problems. In this app, for example, that we're building, we have this thing where there are 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 in this way, it's actually not helpful. It's distracting from the overall thing. And 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. 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 to running software, in part to work with these real materials, but also to, as Jason said, to drive the process forward.
If you were to sit down, as I once upon a time in my career did, where you try to lay out what is this product going to do? 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 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 giga 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.
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 program 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?
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, you know, listened to and absorbed. And then someone makes the call. It might be me. It could be Jay-Z. 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 like 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 right 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? It's like they know they have a sensibility. Yeah, this let me try that. Let me 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, like starting or stopping on a product given resources that we might have or not have, like 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, is not this, you know, quote, giving the people what they want in a sense. Like it's really understanding what they're trying to achieve, where they're trying to go. Uh, they want, 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, if you think it's a good fit for the product.
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 JC or Scott or any other designer that we have works on something with a designer and
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 and 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. And part of it also comes from that dogfooding. Part of it comes from they're using the software too.
In most cases, we build 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 food. 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.
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, right? Like 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 not solving it because they can't relate to the problem itself. And that's all inherent in this dogfooding paradigm. I'm also just going to use like a quick chef metaphor. Like 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 like, 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 you, you know, when you go to a restaurant and you get something like, who in the hell let this out? Who, who, who said this was okay? Then
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 what we're trying to be, a company that's tasting our dishes as we go. Let me just add one thing here. 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, 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. Like this part of it, like I filled this in, like 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 like it just wasn't working. I was filling in like, how can anyone buy anything if this part of it is not working? And then I remembered, oh yeah, we sort of used to kind of have that, right? Like 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 things in that flow where we kind of had to wince a little bit.
Like maybe this was okay three, four, 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, right? 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. 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 like 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 sort of 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. So you've got to figure some of this stuff out and there's a little bit of give and take.
Um, it's again, like, 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 like, well, I wouldn't make it this way. Or let's say you have like a, you know, a salt thing. You can't have salt because you have like a chef's going to want to salt their dish. And you're like, I just can't because I medically, and they're like, well, I wouldn't eat it this way, but I'll do it for you. You know, there are some things like that. Maybe this metaphor breaks down to some degree because 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. 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 Hay, but lots of products over the years. Have we ever dog fooded something and then been like, no, we're not even going to release this product at all?
We've built things that we've stopped using. We've built some things, a couple things that we launched and then sunsetted. Very few, but Basecamp Breeze is one of those things, which is like 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. Like you're 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 direction significantly. High rise was one of those things. We first started high rise. We imagined what we thought people would want. And then like a few months in, we'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 because 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? You know, which is one of the real advantages of dogfooding things is like we there's something missing here and you know it and you feel it and you 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. Like 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.
We actually had this happen twice with HiRISE. 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, HiRISE 2 was
We got quite far into all sorts of different takes on the CRM tool. And what we ultimately ended up doing was building hay. That Jason and I realized, you know what? We don't do a lot of customer relation management. We're doing speculative software. We sort of have a vague recollection of what it was like to have
clients 20 years ago that we're really tapping into. But that well is quite dry. 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 HiRise 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 HiRise and we'd be wasting our time. We'd go like, oh 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 control.
Should I work on this product? I'm sure that HiRISE 2 is a good idea. I am sure that CRM still needs a HiRISE-type product, but I'm almost convinced that we're not the right people to build it anymore.
Okay, well, with that, we're going to wrap it up. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com slash 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 slash podcast question to record or upload a video question for us. We just might answer it on an upcoming episode.