Eat your own dog food

One reason is to know what to build next. So, you know, 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, that didn't really do it

And then also just it sparks ideas. And you know, 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 more make what building this sort of thing and build things in general. And this is true for base camp as well. It's true for existing products. But mostly it's true for making a brand new product

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

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

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, 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

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

Who wants to work on something where they can't really tell what 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

I'm also just going to use like a quick chef metaphor. I think a good chef is tasting their food as they go. So I need to re-season this. What's the what's the dumbness 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

So dog fooding is not just about new product development, not just about new feature development. It's to happen. 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 Rye should be signing up for our product at least once a quarter

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. 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