When to ship vs. when to keep building

`0:27:36`

tell In every situation, here's what you do. At the end of the day, what I'm going to tell you is very unsatisfying, but it's it's just a feeling. You have to cultivate this feeling for when something is done. You have to first of all, you have to be using the thing that you're building, and that will give you a really good sense of like, does it do what it needs to do? Is there something that's lacking here that really needs to be there that isn't? Sometimes you build features that like you're not going to use very often, but like are just exciting to build and will help round out this concept. Like there's this feature in Fizzy. We're building this new product called Fizzy, which is a a bug tracker, issue tracker, idea tracker kind of thing. And there's this one feature we're going to be adding to the product probably for version one, which really doesn't need to be there. I mean, I'm going to admit it doesn't need to be there, but it's such a cool thing. And it signals that

`0:28:23`

this product can be used in a different way than most bug tracking tools. It's basically a instead of like, you know, it for most issues, you describe the issue, right? you'd write down the issue and every issue and pretty much every bug tracker is text. But if you are um trying to report some issue, let's say I again I go through these like real world projects. So I'm renovating some stuff in my house and I'll do a like there's like an issue with the way this fits or these tiles don't line up or whatever. Like I can describe that and I can also take a picture of that of course and you can of course in all bug trackers describe it and then attach a photo. But I just want the photo to be the issue. I just want a picture of the tiles not lining up to be the issue. And so I want to be able to

`0:29:08`

create visual bugs essentially um or visual issues that don't need any words. They just need a picture. And then when you see the picture, it's obvious. And so we want to be able to lead with pictures as issues. And this is not something you typically see in the bug tracking world. Um and so again, I'm not going to use this very often. Most people won't use it very often, but it actually opens up a lot of interesting use cases. And when you display that and you demo that, people go, "Oh, that's interesting. I can't do that in my current thing. What else does this have that I can't do in my current thing?" And it begins to sort of bloom in a sense in someone's mind that there's some other thinking in this thing that doesn't exist in the other things I've used before. And it's a very simple thing to build. It's not a like a big convoluted feature. It's a very simple one to build, but it it means a lot in

`0:29:55`

other ways that aren't really quantifiable necessarily. So sometimes products will have that kind of stuff in it, but ultimately you use the thing and you get to a point where you go, this has everything that we actually need and maybe a few things less like it's just not quite what we need. But that's a good place to draw the 1.0 line and save a few things for the post-launch to add so you can build some momentum. And then you just know you just there's a point where you just know. And if you don't know, I think you got to hone that. That's actually something to hone. It's not something to it's not something you can follow a checklist on. It's actually it's a skill you have to hone and that just comes from delivering and shipping and and making things. Does that resonate at all or do you feel like the what um and this is my follow-up question. I think this comes from what