Your Product Is Probably Ready Before You Think

All right.

It's just more for me to edit, bro.

All we can cut it off the beginning. Or we can not. Because this week's podcast is just gonna be us talking about the shit that we've been working on for the past week or so because we can't come up with a topic.

Mm-hmm.

I'm all right with that.

We were just talking about, which I think we can continue that discussion. We're just talking about the idea of launching Herald. We talked recently about what Herald is at being kind of the first product that we're looking to bring to market. And we're using that as a test bed, right? It's it's a great product, but it's a very simple product. And it's allowed us to learn a lot of things from a technical technical perspective, from a software as a service pr perspective, but I think also from you know, marketing your own product.

perspective and what it takes to do sort of that end-to-end. And it's not something that we're unfamiliar with because we've run a digital marketing agency for 17 years. marketing mostly other people's products. this has been a different experience in that we're building a product ourselves, promoting the product ourselves, and then also advertising it and doing all of those sorts of things. So

What are some of the interesting things you've run across along the way? I have tons of technical ones.

Well, the the the thing that's interesting about building a product and especially coming from a world where we've run a digital marketing agency is that in marketing you have this idea these the four Ps, right? Product place, price, and promotion. Well, the first three Ps have always been solved for us in in most ways, right? You have internal teams at companies that we help support that have already done the work on the product.

They've done the consumer market research because we don't really participate in those pieces. They've done the the price comparisons and decided whether they're a premium product or a value product. They've done the placement. They've got negotiations with whomever they're they're distributing product through or whomever they're sourcing product through to redistribute. And then they come to us and they say, Hey, we need we need more people to know about this these great wonderful things that we've created and sourced. With what we've done with Herald and some of the other products that we're doing.

We had to do all of that stuff first. We had to do the first three P's, product, place, and price. And that's been an it's a it's been a learning curve a little bit, of of how do you do that in a way that doesn't delay a launch of a product by six, twelve, eighteen months, just trying to get, you know, perfect information and perfect data, but also having enough that you're like, all right, well, I believe in where where we're at with the product, I believe in where we're at comparatively with

Mm-hmm.

where the competitive landscape is and I believe that there's value here at this price point. so it's it's it's been sort of this tap dance of figuring out how much is enough to be able to say like, all right, let's let's throw some dollars behind this and and you know, see if this product that we've made for ourselves by and large adds value to other people too.

Yeah. I think we've seen that on the like just building the product side too, right? We've talked about the other product that we have kind of in the hopper nebula, which we'll bring to light and share more about in the future. But you know, we you and I have talked for a while and like it's I'm realizing now that that product has been ready for like the better part of two years.

But because it was kind of the first thing we we s had intended to bring to market, we kept coming up with like, well, if we add this, this, and this, then it'll be ready. And then we need to add this and the these other features and then it'll be ready. And then we need to polish this up and then it'll be ready. And we kind of got stuck in this perpetual perpetual loop of you know solving a lot more problems before we felt like it was commercially viable.

And the reality is it's been solving problems. Like we can see it all the way down to, you know, everything within our the metrics within our own own organization. It's been solving problems for us for since it has existed for two, three years.

So has been viable. It's just it's just kind of ballooned into this like behemoth of a platform that you know now it's a it's a lot more to consume. It's actually even harder to sell at this point because we've we've kind of built like a Salesforce-sized product with all of these other little pieces and parts and modules that nobody's ever seen. So you're trying to explain.

the whole ecosystem and how it all works together in one shot, and it's actually incredibly difficult. It would be a lot easier to explain sort of chunks of it, and assign like a value prop to it, which is sort of what someone like HubSpot does, right? Like HubSpot just sells everything as individual little product, which I fucking hate because every time you turn around you click on something and it's like, you gotta pay for twenty nine ninety nine more per month, you can access this feature.

but they just have dozens of them and that's kind of the model that they've taken. so I've learned that like the product is probably ready before you think it is. and just the importance to get like other eyeballs on it that aren't yours to say, like, hey, is this something that like solves a problem that's not exclusively mine?

When it that it brings up different things that we've yet to experience, right? And we'll have a lot more information and insight to report back on when we do experience it, which is like what happens when this does get in front of hundreds, thousands, tens of thousands of of different users? How do you how do you catalog and accept or not accept various feedback loops? And how do you we've we figured out how to manage that within our own team structures. And, you know, there we have no shortage of of

feature requests or any of those sorts of things and some of its noise and some of it's real. That once you amplify that, how do you get to a place where you're valuing and making your audience feel heard, yet not diminishing what the product's purpose and intent really is. And going back to like the the beautiful thing about digital products, which is what we're talking about here in the in the product world, is you can put something in market that is kind of

not maybe maybe it's not the gold standard of what it is, right? It's it's not what you intend the product to be, but it's enough to be able to get feedback. And I think you're right. I think yep.

Yeah, it's a classic Google loop. Google's notorious for launching a beta it's like the perpetual beta product. Like Google Gmail was in beta by label for like ten years or fifteen years, something like that.

Right. So in in our world, it you know, I have this sign above me behind me that says done is better than perfect and and that's it's supposed to be they used to hang in our in like the main area of our office. And it wasn't because it was it was meant to just to say like good work is is not what we aspire to do here. It it is to remind ourselves that the work is good before we think it is. And we need to make sure that we're being mindful of shipping and and not

gold plating everything that we touch. And I think that I think that lesson is true here with the products that we're talking about. And we'll apply those lessons for future things that we make and get things in market much, much faster so that we can get that feedback loop going.

Yeah, that's definitely been interesting, even on the even on the technical side. Like I use I use products, new products in the market all the time and you know, and completely used to a new product coming out and not having a certain feature or something being a a little weird or whatever. But you know, when it comes to something we're building or working on, it seems so difficult to just let that slide. 'Cause you're like, well

If we just push it back another week, we could fix all of that and make it so much better. but eventually you just gotta put a stake in the ground and say, like it's it's done, it's good enough. And we'll let it fly and we'll see what happens.

Yeah. And it's it's it's the same advice that we give our clients, right? We tell our clients, our dumbest day on the job is day one. And, you know, we particularly talk about this on like website redesigns. It's like, well, everyone gets to the end of a website redesign and we're like, Whew, I never want to do that again. I'm glad it's over. It's like, Whoa, whoa, whoa. That this is actually day one. Like day one is when we when we put it in front of other people that aren't us, they tell us what we got right and what we got wrong.

based on their user journey, what they did do and what they didn't do. Did did they do what we expected them to? Did they take different paths that we didn't think about? And what does that mean for how we should optimize the site going forward? And I think the same is true with with products, right? yes, the products that we're talking about are technically websites, they're web applications. but the same principles are true with that. It's all right, are people not just on the buying journey, but once people are in the product, are they using the product the way that we expected?

Or are they encountering things that we never thought about because we're so close to it that we didn't account for that as part of the user experience or the user journey? and that's that's the exciting part. It's the unknown of of what you're gonna get into and what kind of feedback you're gonna get.

I think one of the things I'm interested in is to see if all the features that especially on something like Nebula like the scale of Nebula where we have a ton of features, like which features go unused. I think will be interesting. especially if they're features that you know, we created or or had theories about and then just like nobody ever uses it.

something we've actually been doing on that product lately, and we did it on Herald too to an extent, but is sort of combing through the product and finding anything that's maybe like a feature that was a good idea but never fully fully worked out or just something that just doesn't feel right. And just like ripping features out before getting it in the marketplace. Cause once it's in the marketplace, if somebody, if people start using

Whatever like we had a overly complex permission system in Nebula at one point that allowed for like 9,000 permutations of of permissions. Like it was absurd. gave you really granular control, but what we found in practice is that you know, even with a few hundred users in it with our own, you know, team and clients, we used like three. So we

compressed all of that down to I think like

three permission categories with two levels in each one of them. and that's sort of like that's your permission set that you can apply to a person. which we can always go up, right? We can always make it more granular over time if we find that there's really a need for that. It's a lot harder to take all of that away, but the maintenance and involved in it, just even at the scale that it is now was

It was always just sort of challenging for us to work around. It was always a lot of switches and a lot of, you know, if statements and things to to make sure that we were making you know, enforcing the proper permission sets. so just paring it down to like its simplest version before putting it in market, I think is in important too, because along the way, right, you people bolt shit on and

You've got something at the end that's just like a little bit messier, a little bit more complex than it was intended to be in the first place. And I think that's probably true for all markets.

And I think what you're scratching at is maybe a bigger principle. And you you say this all the time, which is like don't add complication until it's necessary. And I think that's one of the one of the principles that we've learned in the product development side of of things too, of and your your permissions one is a perfect for instance, of we tried to plan around some corners and probably got a little bit too comp complicated and too verbose and robust in looking at it and trying to plan all the permutations of what might happen in the future and all the ifs and and whatnot.

Yeah.

when the more practical, simple solution was actually what was needed and what ultimately was was what won out in that particular feature. and I think that's probably true across most things, right?

Yeah.

I mean we've had plenty of discussions internally and you know I've heated debates in some scenarios about that exact topic, right? Where people are trying to solve a problem before it's a problem. And permissions has been one that's pretty common where you know they're like, Well, somebody could do, you know, XYZ. They're like, sure they could. But

We also have change logs and rollbacket capabilities and you know, all of these mechanisms in place that allow for that. But you also do the opposite in that you put these like stupid little fences in your way everywhere. So you have this permission system that's so tight that when when Jim's out of town, Bill can't cover for him because the permissions are so tight.

It just doesn't make sense, right? There's no other product that I've ever seen do something like that. And it just you're creating problems to prevent theoretical problems that have never been an issue. And you know, I've taken the standpoint of like you know, the enfor there are people when people ask, they're like, How are we gonna ensure that that doesn't happen? I'm like, Well, the first time it happens, we'll pull that person aside and say, Hey, don't fucking do that. And if they continue to do it.

We will just fire them and then your problem solved.

Or if you have multiple people that do it, even if it's is it's a known or un unintentional thing, then maybe you add fences to to whatever that

Sure. But but most of the time the things that we're worried about are are things that don't exist. Like I remember one of the platforms that we were working on, people were really adamant that we needed to block down being able to archive and delete projects. And like everything we have is always soft archive anyways, but or soft delete, it's like an archive. And I pointed out to him, I was like, Do you guys realize that, you know, in the seventeent years we've been in business, I think we've used Basecamp for like fifteen of them.

Every single person on our team has had the ability to archive a project in Basecamp or create a project in Basecamp. And we're all worried about like what if somebody goes and creates fifty projects that we don't need? And like, we're just archiving.

But the reality is that doesn't happen. And if it did, you just have a conversation with that person. And if you have a person on your team who's just like that stupid of a human being, probably shouldn't be on your team anymore. If it becomes a habitual problem.

Mean this this it kinda reminds me actually of of my life in the corporate world where most of the business was run in spreadsheets. Yes, there were systems, right? There were systems that powered a bunch of stuff and ultimately the data had to get pushed into a system and certain people had the ability to do that and whatever. But the vast majority

Yeah.

Yeah, but like you could have deleted the entirety of the information related to the entire Wisconsin branch of of Anthem.

Yep. So

Then s somebody would get involved and they'd restore it and they'd be really pissed off and, you know, there'd be a whole thing about it. But but there was not a system preventing you from doing that because it was all just a spreadsheet.

Yep, spreadsheets, Word documents, stuff that was, you know, very loose permission based things. And to your point, there were there were other IT things behind the scenes like rollbacks and backups and and whatever that were in place to prevent people from doing stupid things that were permanent. But those permissions were soft. And I think in in application development it's it's probably the same kind of rule, at least soft rule, which is like don't overcomplicate it until it needs to be complicated.

And that it's a it's a lesson that we've had to learn the hard way.

It it becomes a really difficult thing to enforce too, because you're you're trying to when you have the power to do anything, you you can, right? So it becomes tempting to just add features and settings and controls and dials and toggles. And the reality is like the fewer of those that you have, the better the product will be and the better the the experience will be.

the other thing becomes like how do you expose those? We're we've run into that a few times on that. We've dealt with this on Amarchi lately of you know, how do you just how do you expose user controls to somebody that allow them to do really complex things, but just in the way that they expect them to happen versus you know, the default is just creating like a settings panel. and like everything is like you go to settings and you find your section and you make your

You make your change. But the reality is like that sucks. And nobody really wants to go through that experience. So, you know, how do you expose the proper options and settings and flags and in the place that somebody's going to take a s a specific action so that they can just kind of toggle it there or drag and drop something or you know, right click and edit something? becomes really challenging.

Yeah, I mean user experience design has gotten infinitely harder, I would I would say, over the technological time period that we've been doing things. And it's gotten harder not because the tools are harder, it's gotten harder because the the capabilities of what's possible is so much more robust. And so with that, simple becomes hard.

and it's always been, right? But simple becomes hard. So how do you I mean even looking at like my Apple infrastructure, Apple used to have like twelve icons in the settings menu. That was it. Like that that's how you navigated around all of your settings. And it was very simple and very easy to use. Now their settings menu, while still relatively simple, exposes a hundred times more settings and and dials and toggles than it used to in terms of the capability that's there. Which and I I think that

That probably applies ever everywhere, right? So to your point, even in something like Omarchi, which would be a competitor of Mac OS, is probably struggling with the same thing. How do you make simple, really easy? You know, a complex feature is really easy for someone to achieve, and someone to to ex you know, be exposed to something like, I didn't know that was a thing. That's really cool.

It is definitely a challenge. And you know, that that is one where we're retooling pretty much the entire thing at the moment. and one of those, you know, at some point we did introduce the settings panel and had some things in the settings and have slowly like stripped that back. We're like, actually, we could put this over here and we should put this over here, and we should just, you know, there was a whole thing about like rearranging what shows up in your your bar at the top.

Or on the side if you go vertical. But it was like, you know, it was a logical thing, right? You have your three groupings and you can put your widgets in there and you can move them up and down and you can hit the settings to edit them. And eventually we're like, well, what if what if you could just drag and drop them where you want them to be? Now we don't need that, like that whole section doesn't need to exist because if I want to move the widget from one place to another, I just drag it to wherever I want it to be and it just moves.

which is ultimately what we did. So figuring out how to do those things has been an interesting experiment and just reminder that like keeping things simple, like simple isn't simple. and especially now with like like even worse when you have things like AI because you can just ask it to build whatever complex bullshit you can dream up in your head.

And it'll just do it blindly with absolutely no regard for whether or not that makes makes sense at all. and then you wind up with like setting panels on setting panels on setting panels that don't really make sense, but they exist.

Yeah. I mean, we've we've talked about this for a long time, that simple is hard. this is our journey in in creating our own applications has sort of been eating our own dog food in some ways, right? Of how do we how do we actually deliver on that in a way that has a payoff for the user experience overall while also not discounting that

Complexity needs to exist sometimes. It's been an interesting, interesting journey with that. I want to circle back to so the the way that Ryan and I kind of have split out some of our product development things on this is Ryan's the technical wizard and engineer and actually dreams up the products and actually creates these things. And I've been doing a lot of the market research, market intelligence, the other three P's of the of the marketing mix.

Mm-hmm.

And in in doing some of those other three Ps, one of the biggest challenges that I've had is making sure that whatever skills and frameworks and and whatever that I'm using to create these things and largely using AI to to do them and and come back with data points, that it's not just bad data and not just lies of on lies on lies on lies. The amount of time that I've spent fighting with AI and saying, please don't tell me what I want to what I want what you think I want to hear.

I need you to actually do the research. I need you to actually come back with real data. I need you to actually cite your sources is much higher than I care to admit across this product journey for Harold and Nebula.

I mean, you've gotten to experience the thing that I've you know, I've bitched about it often. I've bitched about it on here, plenty.

And I think it it it hits a little bit different when you are trying to solve a problem and getting actively lied to. especially when it's one that like it looks good enough. And it's not until someone's like, Are you sh sure about that? And then you dig a little bit deeper and you're like, this is completely made up. Or I don't know if yours did it to you at some point, but like my favorite at one point I had, I don't remember which model it was, but

You know, one of the ways I would curb it is say like cite your sources. So it would it would give me, you know, the GitHub issues, URLs and things and be like, this is the problem, like issue, whatever. Like, okay, cool. Then you click on that issue and it has absolutely nothing to do with what it said it was. Just completely made made like it just grabbed an issue number. And like, you lying, son of a bitch.

It it I don't I don't know how like it's it's it's such a big problem that I don't think most people still to the like even now really understand how big of a problem it actually is because they're just sort of blindly looking at it and thinking of it as a Google search result. And it's not. It's not a Google search result. It's not the same thing at all. It is i yes, it can be a

No.

Not to be confused with Google's search results because theirs are a little more accurate, like the the Google AI search results themselves. But yeah, and it it's it's something that like, you know, we have sort of our internal AI newsletter, so to speak, that that I'll push out like every winds up being like every second or third Friday. couple a couple of times a month. But

Well, about twice a month, yeah.

You know, because but as we've seen usage of AI within our team increase, we've seen the same loop and pattern sort of emerge. one of those is just trusting the motherfucker too much. And it's because it'll do such a good job at certain things and then you you turn it loose and it produces something, you're like, Well, that looks good and you turn it over to the team and you know, you start to get picked apart. And it's just a good reminder that like you can't

You really can't trust the systems right now. But the terrifying part is you know that like I mean our team's pretty technically inclined by comparison to most. So just thinking about like

The amount, the impact and the problems that are potentially being introduced by that hallucination within an organization that's not as technically capable or as as technically sound for the same reasons, because you have people who are taking bad data and passing it off as gospel, and it sounds good. So then other people are following that, and you just wind up with like decisions being made.

by hallucination. and the fact that like that's probably happening and will probably happen more.

It it is

Yeah, a hundred percent. some interesting things that has been have happened over the last couple of weeks within our team might be worth talking about. Maybe somebody else will get some value out of this. Like some things that our team, even though they're technically inclined, didn't really know about how to use AI. Simps simple like simple things. Like you actually have the ability within most of these models to create your own skill.

A skill is a set of repeatable activities. Stuff that you can that you do over and over and over again, rather than prompting and prompting and prompting and prompting and doing the same things over and over again. Ask your favorite model to create a skill out of it. And then anytime you ask it to do that, just say, Go find this skill and it'll do that. other things.

We don't know how to do that. You the whole idea of skills is

Cups keeps leaking on me. The whole idea of skills in the first place is a is a progressive disclosure model. So you create a skill, and part of the skill is like that top meta piece that explains like this is what the skill is, this is when to use it, these are the trigger words. And the whole idea of a skill is that you should never have to ask to use it. It just knows. So when you say, you know, build an artifact.

something, something, something, right? There's a skill in in all of our AI systems that is mosaic and it automatically triggers and says, like if someone's talking about a fucking artifact, you read this skill. And you can see it every time the agent will pull in the mosaic skill and it'll understand what that is and how to upload files there and whatever. So that without you having to say, you know, hey, create an artifact and upload it here using this skill, it just automatically knows it.

And that's the power of skills, is it's like, you know, sort of the benefits of MCP. I think MCP they're trying to get better with more progressive disclosure capabilities with MCP because one of the problems with MCP is that the every prompt has to carry like all of the tools and everything. So it's like you know, it's like showing up with a to a job site and taking every tool you could possibly think of upstairs with you to the

to where you're hanging a picture frame. And you're like, you know what? Maybe we just go in first and look and go, you know what, I think I'm gonna need a hammer, I think I might need a screwdriver, and you know what, for good measure, we're gonna bring drill. And then you go downstairs and you get those fucking things and you come back. And that's probably closer to like what skills would be versus MCP would be like you're hauling the whole packout kit upstairs to hang a picture with a nail and spending a whole lot of effort to do that.

And a whole lot of tokens to do that.

Yeah, which has always been my problem with with MCP. It's like at one point I had like two or three MCP servers turned on and I could send hello and it I would be at like fifty thousand tokens as my contacts. Like this is absurd. I I sent six. I should be at six.

That's great.

I mean, a another thing that I I think has been interesting and just kind of eye-opening is that I don't think everyone understands that each AI prompt is actually a unique session in in which you can have as many as you want going simultaneously. And so rather than just sitting and waiting for that particular prompt to end and then go on to the next thing, you can have as many projects, side jobs, whatever you want going on simultaneously within the same

AI engine. So if you're using Cloud and you have a desktop app, you can have ten chats going simultaneously if you want. if you're using terminal, you can do that.

Yeah. It's a big it's a big market right now with apps is around orchestration. There's a lot of like orchestration apps that are that are coming out trying to solve this problem. Like Herder is one that I like have been using in like lately. Tmux have solved this problem too from a terminal perspective. There are a bunch on the desktop app side, but I don't use those. but it's it is a challenge. It's also a challenge to like

resist the temptation to just kind of multitask on too many things. I've definitely done that in some days where I'm just like hopping from session to session to session to session and you feel really busy but like you're losing time. You're losing time to context switching and you're losing time to just like idle. Like you're just sitting there idle, not solving the problem because you've moved on to something that's like totally different. Cause you can't.

Yeah, I've talked to some team members that that are pretty adept at doing exactly that, like working in multiple sessions at the same time. And they say the exact same thing. They're like, I I have to resist the urge of having too many things going on at once. Cause if you do, you actually don't get nearly as much done as what you thought that you were gonna get done because you never finished anything. You just kind of moved everything ten yards instead of a hundred.

Now one that I will say is is nice are like long running tasks. So you know, I've got my harness pretty well established and especially on projects, you know, once you have projects and frameworks sort of built, it's sort of they they sort of build on top of each other, right? If you have a a greenfield project, you kind of need to do a lot more checking in, and maybe even some like hand tailoring of some stuff. But

Once you have a a decently sized project with like s a decent rule set, and if you're doing a lot of rinse and repeat activities, you can sort of span some of those together. So one of the things yesterday I was coming from you know Fort Lauderdale over to Venice, which is like a three hour trek. so I just spun up an agent and said, Hey man, here's sort of the definition of these these features that need to be built.

You're the orchestrator, spin up sub agents, make sure each one of them do it. I have a review agent that has proven to solve a lot of problems consistently, make sure everything passes the review agent, and then have each sub agent open a pull request. And then I left. And over the course of that drive, about every 15 to 30 minutes, I would get a ping in in GitHub where one of them had submitted the pull request.

And then continued the work. So it it sat there and churned on these these features for a good couple of hours. But there was a sort of a hierarchy of things where there was, you know, the orchestrator, there was the sub agent executing the work, the orchestrator making sure that everybody was doing everything and that everybody finished their tasks. And then there was the review agent that basically, when this guy said he's done, the review says,

No, you're not. And it would kind of sit in on that loop until you satisfied the reviewer and then it would allow it through to to open the pull request so that ultimately I can take a look at it. I've spot checked a couple of them already. They're pretty good. They're not perfect, but they're pretty good. and that allowed me to, you know, make some progress on some features that otherwise would have just sat completely still over the course of that, you know, three hour car ride.

Yeah. And what I think what you're picking at here is

There are different levels of productivity with using things like AI. And you can feel busy and not get anything done, but with a a little bit of care and a little bit of of thought put in ahead of what that hierarchy and the architecture needs to look like as part of some of that, you can get wildly more productive.

And and wildly more accurate with what you're doing. But you gotta you gotta figure out how to apply those frameworks. And for each person and each job, it's gonna look a little different. You're coming at it from a developer perspective. But I can I can say even on like the the other three Ps of marketing side, doing market research and whatnot, you can kind of have a s a similar workflow that I established as part of like go to market planning of, all right, well, here you're gonna turn on these tasks. We're gonna create these tasks, we're gonna create this little project plan, and then

One at a time, you're gonna go through and you're gonna in Basecamp, you're gonna tell me all the updates acros what you're doing along the way, cite all your sources, then move on to the next one and the next one and the next one. And that that was a fairly successful way to use it in a a more organic average person can do this sort of way than than what Ryan's doing on the development end.

Yeah, I mean there's lots of things you can do though. Like especially using sort of like loops or like Claude's been all about hocking loops lately, which I mean there's a benefit to it. I have some established with my now Hermes agent. but just you know, sort of like the daily I have like the classic daily brief that comes through, but it takes a look at

My emails and my my calendar just to sort of like help me surface things. I get a ton of junk mail, even you know, even filtering out as much spam as I I can, I still get a ton of junk or I have a lot of like emails that are that I'm on as just kinda like FYI. So it's helpful to clut to sort of just float the three or four up that I need to actually care about, if there even are any.

allows me to really focus a lot of effort. So instead of starting my day by like opening my email and churning through email and those sorts of things, I just kinda look at the daily brief that's plopped in my inbox before I even wake up. And if it the if it hasn't found anything that it thinks is important, there's nothing in my inbox worth reading. and I'll you know, I'll go through it at some point, but it's from a priority perspective, it helps to just like remove that from the equation entirely for me.

other people who are a little more, you know, e we're not very email heavy, right? All of our communication happens at Basecamp. So it helps to service some of those too. But for people who are more email heavy, I can imagine that, you know, setting up loops like that can be incredibly v valuable to clawing back time in their day versus spending it in an email client.

Yeah, for sure.

Well, I guess enough for today.

Probably. Till next time.

Collector.