The Secret to Getting Your Team to Embrace Change

Danny Nathan: Generally, I think that people don't think about how they want to make change within their organization until they have some sort of reason to do so. So until there's a pain point that's kind of slapping you in the face every day, be it, I, I missed a dozen emails 'cause I had too many or whatever. Um, people don't really view problems as problems. They view them as, uh, just the way we do things. And so if you can find somebody who has the ability to, um. Look forward and say, Hey, we're at a growth stage. This is going, this particular aspect of our business is going to become a problem. Let's figure out a solution to that problem. Now, before that happens, um, it tends to be

Sean Weisbrot: refreshing, but it's kind of rare. Welcome back to another episode of The Wheel of Build podcast. I'm here today with Danny Nathan, the founder, and CEO of Apollo 21, a venture studio and technology consultancy that builds new products and services, both for internal and client company use. So I originally found Danny through help a reporter. I was looking to speak with people just like him who are engaging heavily in automation, integration, and AI so that we could talk about what they've been up to, how they think about it, and where the world is moving. In this episode, we're going to talk about his experiences running the Venture Studio and how they think about these tools and how they're using them for themselves, how they're using them for their clients. And surely we'll talk about other things beyond that. So thank you for taking the time to talk with me, Danny, and I appreciate it. Why don't you tell us a little bit more about yourself and how you got into founding and running

Danny Nathan: Apollo 21. Apollo 21 came about sort of serendipitously. Um, in my previous role I was head of product for a video technology startup based in Los Angeles. And, um. For the last year or so of my tenure there, I was focused primarily on helping other companies in our investment portfolio, uh, build out platforms for their needs. And so that, uh, eventually kind of got me noticed by a few people and led to the opportunity to step aside and, um, start my own company doing much of the same thing. So, um. That led to the start of Apollo 21 in April of 2021, and uh, we've been running at it since then.

Sean Weisbrot: I actually know several people exactly like you, where they may not be running their own companies yet, but whenever they enter a company, the first thing they do, even as an employee. They just look for things that suck and then try to make them better. Um, my brother is one of those people he's really obsessed with, like, figuring out how to fix things and I, I think I'm like him in that regard as well. Um, so before we do go any further, I do want to, uh, have a disclaimer on this episode because as of today. I finalized an investment in a new company that is going to focus specifically on automation and integration. So one of the reasons why I started reaching out to people like yourself is because I wanted to see kind of how other people in the industry were thinking about these things, what kind of things they were experiencing, and. Maybe there's some pitfalls that we may be able to avoid, um, in the start of this century. Now, I'm not gonna be operationally involved, but, uh, I am, uh, I I don't have an insignificant amount of equity in the company. Congrats. I will, uh, I'll try to watch

Danny Nathan: what I say then. Can't give away all of the secrets.

Sean Weisbrot: With that in mind, I really got interested in this stuff in the last six months, I'd say. Mostly because, let's be fair, Chachi pt, I don't consider myself terribly sophisticated when it comes to putting things, putting systems together. I, I would never really say I'm like terribly operationally savvy and I never really tried to be. But in the last six months, seeing Chachi PT come out, seeing what's become available and having started to kind of put my own company we live to build. In more of a, a growth phase for myself, I started looking at these kinds of tools because not only are they valuable for me, for that company, but they're also valuable for my personal brand since a lot of people are talking about AI now, um, as well as for potential investees and, uh, things like that. So my first experience was really like Zapier, and that was a few months ago. And like I had a singular goal to. Create a, uh, an automated workflow for, uh, a passport company that I'm trying to, to form. Well, a passport company that I've recently launched that's gonna help people to purchase citizenship through, um, uh, like investment sit. Uh, usually they'll donate to a specific government's economic diversification fund, et. Um, and so I wanted to do a lean, I wanted to build an automated workflow for building a referral network. I spent weeks and weeks and weeks trying to make this process work, and eventually I gave up and did 80% of it manually. Um, and so I, I, the reason why I share this is because it's probably something similar to what you've experienced with your clients. When you first start talking to them, they're like, well, this is what I want to do, but maybe they. Don't know how to do it, or they don't know what the process is and how it can be done. So like, why don't we talk about, um, what you think or what you see the starting point is for most founders and most companies that you come across right now in terms of automation?

Danny Nathan: I think that, um, in our experience, a lot of the need or the interest in automation comes from companies that. Uh, fall into the realm of what we tend to call tech motivated. And so there are companies that are not technology companies, um, by trade, uh, but rather companies that are, you know, operating, doing their thing and growing, but who understand the technology can help them streamline those operations, can help them. Um. Move their business forward, grow faster, et cetera, without having to scale their human resources at, uh, the same pace that they would otherwise. And so, uh, a couple of examples. I mean, we've, we've worked on major automation projects for a financial services company, for example. And they came to us essentially and said, we do everything via email. We run literally thousands of transactions every day and. I mean, it doesn't take a huge leap to figure out that thousands of emails every day will be overwhelming, will cause things to be missed, and, uh, eventually make some clients unhappy, make some employees pretty stressed out. And so we sat down with them and really started at kind of square one and, um, evaluated their internal workflows, which frankly was a process they had never been through. Um, and so even just asking them to describe what the day-to-day looks like or what the, um. The flow of tasks through the, the company looks like, um, was more of an undertaking, I think, than we expected. And so as we began to kind of paint that picture, we were able to work with them to boil down their, their kind of core processes and workflows to, um, I think we ended up at four or five workflows that cover like 80 to 90% of their needs. We started building out an instance of our mission control platform that would automate those workflows for them. And so the edict essentially that came down was we never wanna look at email again, um, unless it's from a client. And we want a system that will help us keep track of all of these requests that will keep audit logs. Uh, we're dealing with financial data, so of course it has to be built with security in mind, um, and really kind of. Went step by step and evaluated everything along the way until we could achieve that edict of no more emails. We want to handle everything through mission control. And so, uh, you know, that was one of our early kinda major forays into automation. And I think last time we spoke, Sean, we were talking integration. Which of course becomes kind of a core part of the thinking around automation, or at least the expanse of cap, the expanding capabilities there so that your automated workflows can handle more of what you're trying to get done. So, um, we have another instance of mission control that's been stood up that functions much like a CRM and marketing platform and. In that case, the automation is focused primarily around, um, what happens after somebody sits down in front of mission control, creates an audience segment, and then wants to communicate with them. And so the automation there is primarily through integration and, uh, the ability to send out SMS push and email notifications all at a click. Um, and so, you know, we've spent a lot of time thinking about how to. Streamline operations through that, um, that automation capability and build those, those functions into mission control in particular, and then into the other products that we're working on as well, uh, so that we can make life as easy as possible for the people that are using them.

Sean Weisbrot: So I have a few follow up questions for that before I ask them. Um, I, I would like to share real fast that I am currently, uh, I, I do some mentorship. I do some paid advisory, and I've found that consistently these are, they're early, you know, they're, they're young entrepreneurs, you know, in their twenties and mostly not terribly sophisticated in their operations either. And when I talk to 'em about the documentation of their processes or the automation of their processes, they generally have not thought it through and they're just trying to get through the day. So I'm not surprised that that's what you've been experiencing. So the first question I'm curious to know is how old were the decision makers? How old was the company and how many employees did they have? So the financial services

Danny Nathan: company that I talked about, um, I think it's about five to 10 years old. And I realize that's a range. Forgive me, I can't remember exactly when they started. Um, but they are not. Exemplary of young entrepreneurs. They are, uh, a better example, I think of the, the kind of tech motivated mindset that I talked about. So the company's been around for a while. They know how to do what they do. They had hit a growth stage themselves, which was leading to them being kind of overwhelmed and drowning in email. And that led them to the moment of, we know that technology can make this easier. We just don't know The first thing about building it, because we're a financial services company. Um. The second company that I was talking about is a much younger company. I believe that they're coming up on two years old. And similarly, they are not run by young entrepreneurs, but rather by a team that comes from a pretty diverse background across, um, consumer applications. And in this case, uh, the company is focused on the western sports area. And so, um. That audience in general. And, uh, the industry is a little laggard in terms of how they adopt technology. Um, you know, as you can imagine, uh, a lot of the companies that are putting on rodeos are doing so every weekend, but they're doing it in places that are not, um, technology ridden, so to speak. You know, you're talking to your, uh, you know, your outdoor horse riding arena generally in small towns, things like that. And so. The technology space hasn't exactly caught up with the, uh, or the rodeo space, rather, hasn't exactly caught up with the flow of technology. And so I think that that's, you know, that's part of what this company was trying to bring to bear and to, um, help the world of rodeo kind of step up. What were the sizes of those companies? The financial services company was about 80 people and the Western Sports company was. Around 25, I think, when we started working with them and are probably 80. Now. The reason why I ask those questions

Sean Weisbrot: for anyone who is interested is that when you are trying to do anything with a company, those factors are very important based on what it is you're trying to accomplish. In this instance, what he's talking about is trying to change the way a company operates, and so the older the founders are, the decision makers are the. More resistant they might be to change. Despite being interested in knowing that change is possible, the and the size of the company will determine how long it will take to actually get buy-in and implementation and change. So I'm curious now that this information has been shared, how long did it take to successfully implement the changes in those two companies?

Danny Nathan: Our work with the financial services company, uh, took about. Six or eight months with a little bit of, kind of trickle through the final stages, uh, for a little bit, little while after that. Um, the work that we did with the Western Sports client, um, it's a little tough to pinpoint Sean because we started with a very specific ask from them, which was to help them get their, uh, data and analytics in order. That particular process was about six weeks and then. Uh, we found that we had a really good working relationship that developed into about a year and a half long engagement during which, uh, we built a ton of new products for them. We built mobile applications. We expanded on the capabilities of mission control. That's where some of the integration work came in. And I think that, um, the actual integration to enable the automation that I was talking about was probably. It's a couple of months worth of work at that point. But bear in mind, we already had mission control stood up and had all of their data ingested and everything. So we had a pretty solid headstart when they got to the point that they were looking for, for that type of work. Um, and then the other thing that we built for them that I think is relevant is a, uh, kind of an event management platform for. Executing rodeos, if you will. So, you know, if you think about it, every time you go to create a rodeo, there's a certain subset of the tasks that are roughly the same. You have to, you have to get the bulls to the arena and pick who's gonna ride which bull. And the same with the horses and the registration process and all of that stuff. And, um, the build out of that platform, I, I'm working from memory here, was about five months start to finish.

Sean Weisbrot: All right? So definitely not a short period of time.

Danny Nathan: When you're working on a project like that, especially something, you know, when you look at, uh, at our financial services client, for example, who was truly looking to automate all of their internal workflows and processes, you can kind of see from the start where that's not gonna be a, a quick fix and there's a fair bit of, um, iterative development that has to happen there so that, you know, we can test, improve and, um, make sure that we're covering off on all of the needs that they have so that the system. Does what they need it to, and so that they have the confidence in that system to begin using it on the day-to-day to manage their business essentially. So, uh, you know, to your point earlier about being resistant to change, uh, I agree completely, but it's also not hard to see where when a company is, uh, is putting their day-to-day operations into the hands of your software, um, it's gonna be a little bit of a process to get them over the hump and comfortable and confident to the point where. They're ready to roll full-time on that. Who do you think is generally the most resistant to

Sean Weisbrot: buying in

Danny Nathan: generally? I think it's, you know, who I refer to as kind of the key stakeholders, um, the folks, if you look at a company that has been around for a while, the folks who are sitting at the top of that company, um, you know, generally have been there for a while, they're looking at it saying, um, yes, I understand that we have some pain points here, but at the same time, we have built and grown our business based on the way that we've been doing things. So. Uh, instigating change in those situations always requires a certain level of reassurance. Hence the, the kind of longer build phase, the, uh, the deep testing that we do. Um, we spend a lot of time. Working with our clients, introducing them to the platforms that we're building for them, letting them use it in kind of a test environment or deployed for like one client of theirs, for example, so that they can get used to it. Give us all the feedback along the way. And in doing so, we build support from kind of the, the operational teams within those organizations so that when those key stakeholders or the C-Suite for example, has questions or wants to see. Um, proof in the pudding, so to speak, that the things that we're doing are, uh, driving value for their company. Not only is it, is it Apollo's team that is advocating for those changes, but generally we aim to have support from inside the company as well, so that somebody who has been helping us test the platform, for example, can say to the, you know, the stakeholders, no, no, no. I've been using it. It does exactly what I need it to do. I've worked with Apollo 21 to ensure that. We fine tune these few things so that, um, we know that it works for our needs. And so building kind of internal advocates in that way, uh, tends to help assuage the concerns of, of the folks that might voice them.

Sean Weisbrot: It's probably not very commonly thought of to actually talk to the people that are going to use something before it's built. I imagine you'd normally build something and go, all right, boss, this is what it's gonna do, and then you're all right. Cheers. Thanks. And then the person uses it and they're like. This is not what I need.

Danny Nathan: That is certainly one approach to, to building software and it's, uh, it's one that we're not a huge fan of. Um, at Apollo, we, uh, we do tend to try and involve the folks who are gonna be using things on the day to day, um, from the very beginning. And that, I mean, that starts at the research phase. You know, understanding workflows, core processes, things like that so that we can build out. Automations that will help streamline those, those workflows requires us to the, to talk to the people that are handling those tasks on a day-to-day basis. Because, uh, you know, generally the, the C-suite or the folks who are, um, you know, the folks who we talk to in early, early in the sales process, for example, are not the ones who are as familiar with the discreet, um. Pain points that we're looking to solve. And so, you know, while they understand how to, how to run the company and how many transactions are flowing through a financial services request, for example, um, they're not going to have as clear an understanding that, uh, that the guy who handles the bank transfers will around. You know, every time I go to Bank of America to make a transfer, I have this problem. Or I know that for this account from this client, I have to call this person to get, uh, sign off on it. And. So it, it puts us in a position where we really have to talk to those people, but we view it as a good thing because as I described it, uh, it ensures that we get it right and helps build that adv advocacy at the lower levels that then kind of trickle upwards. Do you often find that there's pushback from those, uh, people that'll be using it? I find that there is skepticism. So, you know, we come in and say, Hey, we're here to, we're here to change everything, or we're here to automate everything. And the first thing that people generally do is kind of go, whoa, I don't know about that. You know? Um, but I think that as we open up the conversations and as we start asking questions. Of the people who are gonna be using whatever it is we're building. Generally they come around to the mindset that we really are there to help make their lives easier. And once you hit that kind of turning point in the, um, in the interaction, generally things become a lot easier. And they become very excited to work with us because they can see that, um, you know, as you said, they're probably not used to somebody from the outside coming in and talking to the people who are going to be using the stuff on a day-to-day basis. Um, and so. It provides kind of an eye-opening opportunity to help them understand that you're there genuinely to help make their job easier.

Sean Weisbrot: The financial services company, I guess, hit a growth phase and then they went, oh crap.

Danny Nathan: Yes. Basically I, you know, they turned around, found themselves drowning in email and went, okay, this is unsustainable. And I, my sense was that they knew it was coming and it was one of those things where, um. They'd put it off for a little while because it's always difficult to, uh, to instigate that much change. But I think they, uh, they hit the straw that broke the camel's back moment and realized that, um, if they didn't get themselves off of an email dependency, that um, they were either gonna have to hire so many people to make sure that all the emails could be read or they were gonna have to, to change how they did things. And so lucky for us, they, they opted for change.

Sean Weisbrot: Do you think it's more common for that to be the case or for someone to look at their company and go, I think we're gonna grow really fast, you know, or we're planning for growth. Let's create this change now before it happens. Which do you think is more common and, and which do you think is smarter? The

Danny Nathan: latter is smarter, and it is definitely the less common approach. Um, generally I think that people don't think about. How they want to make change within their organization until they have some sort of reason to do so. So until there's a pain point that's kind of slapping you in the face every day, be it, I I missed a dozen emails 'cause I had too many or whatever. Um, people don't really view problems as problems. They view them as, uh, just the way we do things. And so if you can find somebody who has the ability to, um. Look forward and say, Hey, we're at a growth stage. This is going, this particular aspect of our business is going to become a problem. Let's figure out a solution to that problem. Now, before that happens, um, it tends to be refreshing,

Sean Weisbrot: but it's kind of rare. I try to tell people that I advise, you should think about these things before you start to grow. So generally one of the ideal clients that I work with is making about 20, 30,000 a month. They're probably by themself, maybe they've got a contractor, they're at a point where they can grow, but they need better internal systems. They need standardization of, of their operations, and they need to stop taking money and calling it their own. They need to consider that they're actually stealing money from their business. My goal coming in is I'm gonna advise you on how to turn, turn your business from 2030 KA month into a hundred KA month, but it's gonna be painful because you need a month or two to fix your operations before we can even talk about anything else. And generally they're like, ah, right. They're used to doing things in a certain way. And so, and I'm like, you call yourself a company. But when you take all of the money every month and you only have one person you're working with, you're not really a company. If you wanna be a real company and generate seven figures a year or more, this is what we have to do. And so I, I, I kind of see something similar, um, even though I'm working with people with relations.

Danny Nathan: Yeah. You mentioned something earlier, Sean, around, uh, around documenting process that, um, I think is not something to pass over lightly. And in fact, it's. It's a process that we've gone through multiple times in Apollo 21, uh, most recently, just a few months ago. And, um, you know, as we think about for us specifically, what it means to build products for our clients and also for ourselves in the, um, in the Venture Studio model, uh, having that repeatable process and having it documented clearly becomes incredibly important for us because it's part of how we build confidence. Both for ourselves and for the folks that we're working with that, um, to put it bluntly, that we know what we're doing. Um, and so, you know, we, we sat down and documented every stage of every engagement, uh, recently and put together a checklist of, I, I mean, I kid you not, I think it's about 75 items deep and there's sub items and whatever, and it sounds. Overwhelming, and I could see where the, you know, the one or two men show that you're describing wouldn't want to bother going through that process. But the reality is that, um, by documenting all of it and then following it, and, uh, consistently asking the question of what's working in that process, what isn't, and giving yourself. What I call sort of stringent flexibility. So, you know, you have to be stringent about going through the process, but you also have to be flexible enough to recognize when that process needs to change. And so we focus a lot on that and we're huge advocates for the level of documentation that you're talking about because it creates repeatability and it makes it so that, um, to your point, you know, if you're a one person shop who's looking to grow and add three or four bodies, for example, um. It's really hard to train those new people to do everything exactly the way that you do it. And, uh, frankly, it's kind of a bad way to work as well. I mean, when you hire people, you wanna hire people that you can trust, brings something unique to the table. And while they may or may not do things exactly the way that you do, you have to trust that they're going to get those things done successfully, which presumably is why you hire them. But the checklists and the, the process definition that I'm talking about. Create those guardrails or the, you know, the bumpers that you put in the bowling lane when you're a kid. Um, so that the new folks can look at the checklist and go, oh, okay, uh, at Apollo 21 we do this and then this, and then this, and then this. But how they accomplish those tasks or occasionally even the order in which they accomplish those tasks, um, is up for debate and up for consideration. And, you know, it opens the door for somebody new to say, Hey. The process says, do this, but I've always done it this way, or I find that for me, this particular approach is, uh, is successful. Have you considered this? And you know, again, if you're, if you're a good leader looking to grow your company, then hopefully you're open to that kind of feedback and at least considering what somebody's bringing to the table, whether or not you choose to, to kind of change your process, to fit their needs or to fit their recommendations, time will tell. But, um. I think that it, being open to it and having that level of care around how you approach projects and problems just makes business more sustainable and easier to grow. Definitely.

Sean Weisbrot: I remember when I was working on nerve, my B2B SaaS, I was in charge of product because we didn't have anyone else who could do it, and I was the only person that knew the product, even though we were a team of about 14 at the time. And eventually we hired someone, thankfully because I was miserable. I was tired of doing product. And, uh, this woman we hired came in and she spent a few months cleaning up the mess that I had created because I had, I had no experience of products, but I was forced into it 'cause it was my baby and nobody else understood it like I did.

Danny Nathan: That's kind of the, the beauty of starting up, if you will, is that, you know. You hit a point and everybody has to wear as many hats as they can just to, to find success. And then as you continue to grow, you have the ability to streamline and and so on. We, we had a similar experience. Um, we had product folks that were kind of running the program or project management aspect of our business. And while I'm a firm believer that, um, some measure of that type of responsibility is part of the product role. Once you hit a certain size, finding somebody that is solely responsible for that aspect of the business and the client relationship, um, just makes things easier. And, you know, that person, his name is Kevin, has stepped in and, you know, he's been pivotal in helping us do the documentation around our processes that I've described and ensuring that we're following them. And, you know, he's always the, the voice in the room that's saying, Hey, by the way, the checklist says this. Did you do it? Was it valuable? Do we need to keep it on the checklist? And he loves that. He's also very good at it.

Sean Weisbrot: That sounds more like an operational manager than a product manager. Am I wrong?

Danny Nathan: Yeah. He is a program manager slash kind of operational person. And so, um, I have, I have a head of product who sits separately. Uh, my head of product's name is Calvin and, uh, he's fantastic at the. The kind of product strategy and design aspect of product, if you will, helping to think through, um. How we translate requirements that come from a client to the thing that we're going to build and interfacing with our engineering team. Whereas Kevin, my program slash operations manager, is more focused on ensuring that we're running through repeatable processes, that we're hitting the steps that we need to hit. And, um, measuring the KPIs around each of those steps so that he can evaluate how well our processes are working and what are the other issues that a lot of companies.

Sean Weisbrot: That you probably talk to is that they probably don't understand that their organizational structure is probably messed up and do, do you ever, have you ever had someone say, okay, we need help with automation and integration, and as a result of all of your research, you go, look, I've discovered that your organizational chart is messed up. We, is it possible to fix that in order to make these automations actually function properly, or do you just leave that alone?

Danny Nathan: We have definitely run into that and how we approach it, I think. You know, falls onto a bit of a case by case basis and depends a lot on the relationship that we've built with that client. When that moment happens, if it's um, you know, if it's a new client that we don't know terribly well, we might broach the subject, but do so with a little bit more care, uh, a little bit more kid gloves around. Um. How we tell them that their, their stuff is broken or that their org is, is broken. Um, whereas if it's a client that either, uh, we have connections with or that we've been working with for a while and have developed, um, you know, a bit more of an open relationship, then we have an easier time saying like, Hey guys, you really need to consider changing this. Or, uh, you know, have you thought about this person in a different seat? Or things like that. But, um. It really, it depends a little bit. And you know, when you come in as a technology partner or somebody who is there to build something that, um, the organization views as, uh, a technical kind of endeavor, whether or not you have permission to make those suggestions really does just come down to the relationship that you've built with that, that client.

Sean Weisbrot: So I wanna go back to, um, kind of the documentation thing real fast. 'cause I was thinking about it. Uh, so one of the people I'm working with right now, he's also pretty early in his SaaS journey and he would like to hire multiple people for his business. He's not there just yet, but when I asked him about documentation, he said he had none. And I was, he is like, I'm busy developing and serving clients like, great, but you wanna build a team. What are you gonna do when you hire them? If you're having the documentation to train them on? And he is like. Hmm. Here's two scenarios. One, you slow down on hiring, but you spend the next few months documenting everything that you do. And it's gonna suck and you're gonna hate it. But when you hire people, you can hire faster and you can train faster. 'cause you know who you're hiring, you know why you're hiring them and they know what it is their job's supposed to be. Or you do the opposite of that. You hire faster and then you force them to build the documentation with you, but then you're not gonna have time to develop or serve clients. They're not gonna have time to develop or serve clients because they're working with you on the documentation. He is like, oh,

Danny Nathan: yeah. I, I guess my question there would be, does the, does the documentation of the process have to be a full-time job for one or two people over a period of months? I mean, you know, when we, when we did our documentation exercise recently, for example, we held a, you know, an offsite, we're a remote company and so getting everybody in the room together was a value for that exercise. But, um. Over the matter of about three days, we were able to get high level documentation created and then kind of assign out tasks to each of the individuals to go and round it out, and then kind of come back together to discuss as we move forward. And so, um, I think you've, I think you've hit the nail on the head with kind of the, the two options there, but I would question a little bit whether there's months involved or whether you can't serve clients and. Document your process at the same time with, with at least some level of success.

Sean Weisbrot: Well, the thing is, he's a technical founder and so he doesn't have like the backend architecture document, like he doesn't have anything documented. And depending on the complexity of the product, that could take a significant amount of time because you may find that maybe. You don't have coding standards or naming conventions possibly because you're just doing this on your own, so you don't really have anyone you're reporting to or managing. Right. I didn't, I haven't looked at his code, so I don't know what it looks like. And I'm, I'm not a coder, so I don't want to get there, but, but like, let's say you wanna hire a salesperson and you don't have a standard sales process. What's gonna happen to that salesperson? Right. So what, so what I do with him is I actually keep a, a weekly list of things that he's, he's committing to doing so that we can move him forward, especially 'cause he is on his own still. So, you know, one of the things that right now that we're working on is like, okay, I'm committing to documenting two things this week, like two documents this to completion. So like every week, let's, let's hit it a little bit, right? Let's work on some bugs, let's add some new features. Let's do this because like he's. He's a technical person, but he's not a CEO. So operationally, he's, he struggles and I, I find this a lot with people. So just gotta keep him on track for that so that he can get to his goals.

Danny Nathan: Yeah, absolutely. And as you're describing kind of the technical documentation, that makes a lot of sense and I, I can certainly see where that would take a fair bit of time. I was, I was thinking more around process and operational documentation. I see your point entirely.

Sean Weisbrot: Right? And like he also struggles with marketing. So like in next week's call we're gonna focus completely on the redoing the website content because he has a product but he doesn't really know how to market it very well and he didn't know how to price it very well. Thankfully I was able to convince him to multiply his price by five times 'cause it was too low. So yeah, making progress. But, so I, I am, I'm excited to see how. The new company I've invested in does with this. I imagine it'll end up being larger companies because we don't wanna work with people that are too small because otherwise you can't really make any money and grow. Um, but yeah, me personally, right? But me personally, I like working with small people, you know, small companies that don't really understand things yet, and so it can help them to, to get a leg up, um, even if they don't have a big team or millions of dollars to work with.

Danny Nathan: Yeah, there's a lot of fun and a lot of opportunity that hits at the early stage because it's such a, a malleable place to be where you still have the opportunity to define process and think about roles and seats and how people come together.

Sean Weisbrot: So I get it. There's a ton of fun there. Is there anything we haven't really gotten into that you think we should be talking about?

Danny Nathan: The only thing that comes to mind kind of quickly off the top of my head, Sean, is uh, you know how companies. Approach, that realization moment around the need for automation and how they go and find the right partner for it. And, um, I don't know that I have a, a specific point, but as we're talking around that kind of idea, um, you know, I'm, I'm sitting here thinking, uh, how companies find us that we work with and you know how companies find the folks that you're describing. And, um, you know, when you think about. When I think about how we market and describe ourselves, for example, there's always this moment of, uh, helping people understand what we do as a company and what we can bring to the table for them. That, um, to be blunt, I struggle with a little bit because I always wonder whether there's a missed opportunity in, oh, if I had told them that Apollo 21 does this or is this, would it have resonated more closely or would they have understood more quickly? Um. What benefit or value we can bring to their company. And so, um, I guess to turn it around, I'm curious, do you have any insights on, um, how to talk to the companies that are looking for that kind of automation or how to, how to kind of make it known that it's something that you can help with when at least we don't market ourselves directly as an automation company, but as a company that helps solve business problems, for example?

Sean Weisbrot: I think it depends on how they find you. Like if you're doing cold outreach, then it's about finding someone that you think would benefit from it. So for example, one of the things that I'm gonna be doing for the business is establishing a referral network because in the businesses I've worked with before that I've created that are successful, it's all word of mouth. I've never, I've never made money of doing ads. I don't even know how to do ads personally. And so. When you set up a referral

Danny Nathan: program like that, Sean, is it incentivized at all or is it just uh, encouraging word of mouth?

Sean Weisbrot: The most successful business I had, people were getting 10 to $20,000 commissions and they were very, very happy and you better believe they were trying to bring me new clients every day. Who doesn't want a brand new car? I mean, this was, you know, 20 16, 27, 20 18, you could still buy cars for 20 grand. Then one of the guys actually bought his mom a house in cash. He got a quarter million dollars in commissions working with me over like a two year period. He bought his mom a, a house in cash with the commission money. He told me he was like so happy. Wow. I like businesses that charge a lot of money and then build a referral network. So that basically what happens is. If you know someone that knows people that are your potential clients, and those clients trust that person, that's zero refer, when they refer that client to you, what's happening is psychology of trust, right? The, the trust is being transferred from the middleman or middle woman to the company that's gonna provide this service. And so the difference. Sales process basically goes away. Um, so before I built my ever, my, my first ever referral network for that first company that was, that went crazy. My close rate was 10%. And with those, and, and it would, it was very, it was very difficult to, took a long time and close rate was, was, uh, very low. And they wanted contracts and it was all sorts of stuff. After I built the referral network, I had a 90 plus percent close rate. I had a single call for half an hour maybe or an hour with people. I was charging 50, a hundred plus K to no contracts. A hundred percent paid in full before you start. So I changed the entire thing because it went from, hi, I am Sean and I can do this for you to, oh, that's Sean. He can do that for you. You need to work with him. He's the guy for this thing. And then giving them commissions upon success. Interesting. I like it. I'm gonna have to do on that. And they didn't even have to do much selling. They just have to introduce me to them and I do the close. I much prefer that to cold outreach because with cold outreach, like, well, who the hell are you? How do I know I can trust you? There's a bunch of questions, right? You can make content and people get familiar with you, but the se, the cycle on that could be one or two years before someone decides that they're ready to work with you. Um, there's all sorts of problems, especially B2B. The sales cycle is longer, so when you have a referral network, for me that's like. And I've, I've already identified the two perfect referral types that I wanna go to for this business. I'm not gonna share it with you. Sorry. We can't give away all of our secrets. I'm quite excited about it and, and I actually discovered one of them when I was trying to do cold outreach to build a referral network for my passport company. I started, I started talking to some of them and I was like, oh, they're the wrong people for that business, but they're perfect for this other one. So I held off on contacting them and, and once we have the website up in the next few weeks, I'm gonna start going to these people. And I, I think it'll be extremely interesting for them, um, and, and their clients. So, uh, so yeah, for me, a referral network is, is always best because. You can be trusted and, and so like, I've got the podcast, that's a, a form of social proof, right? Oh, how can I trust you? Well, I've done almost 150 interviews with a bunch of people that are running 7, 8, 9 figure businesses. Like, I'm not hiding anywhere, right? I'm not gonna run away. I've got a company. It's established. Like, you know, there's, there's ways to social proof for that. And so it's just a matter of getting people to, to trust you and making sure that you're talking to the right people that have clients that they, that can actually benefit from, uh, from the service. So I think that really cuts down the speed at which you can grow. Um, so I'm, you know, I think that's, for me, that's the best way to do it. So if you take it from that approach where clients are coming to you, it's a lot easier to sell them and. Chances are the hard work has already been done because that person has already maybe gone to them with some knowledge of your business and your, your pitch to say, you know, this is something that I think you could benefit from because I'm providing a service to you. And I can see from, you know, from what I've seen, this is something that you know, you could benefit from. What do you think? I wanna introduce you to them. I think they can help you. You know, blah, blah, blah. Um. But then again, like if, if you're doing cold outreach directly to the potential client, it's a very different game. It's a lot harder. Um, I've heard of people using Twitter, like DMing people on Twitter and getting closes, not for, for automation, but for coaching and, um, social media marketing as an agency. Like there's, there's a lot of agencies that employ, uh, Twitter and LinkedIn and Instagram dms as a way to outreach. Um, so yeah, I, I think it depends on your, your, your outreach whether or whether you're doing outreach or whether it's inbound. I always prefer inbound. Um, I think it, it can go a lot faster. I think it scales a lot better. What is the craziest request you've had for an automation one that you thought about it and you're like, oh, Jesus. What?

Danny Nathan: Honestly, handling the automation work for our financial services client was, was a bit of that. Um. My team doesn't come from the world of finance. And so sitting down and understanding, uh, what the workflow looked like for this company and then figuring out how to accommodate all of the different checks and balances, uh, that they wanted built in was, um, was a bit of that moment, you know, and eventually we got there. But there's a lot of, uh. There's a lot of moments of, well, if this happens then so and so needs to receive it, and if this happens, then so and so needs to get it. And uh, if it was this person that approved it, then it needs to be approved once more by somebody senior. But if somebody senior approves it the first time, then it doesn't need a secondary check and all of those things, um, kind of around that. And it makes sense because, um. The requests that are coming through this system literally handle the transfer of hundreds of millions of dollars on a daily basis. And so the, the system of checks and balances and the rules are there for a reason, which we understood. Um, but figuring out how to build all of that into a system that required as little kind of input as possible. Hence the, you know, the automation aspect of it. Um. Took a fair bit of thinking and it's part of the reason that you know that the project took a fair bit of time as well. 'cause we, we had to spend a lot of time understanding how it worked today, how they wanted it to work on this new system, and then ensuring that the system was capable of managing all of the edge cases that I'm describing around, you know, if this, then that moments,

Sean Weisbrot: if edge cases occur, then you discharge 'em more and go and, and support it. Yes.

Danny Nathan: Yes, there is that aspect, but, uh, it was outta scope. Yes, the scope conversation becomes a whole different thing, um, and a, a difficult one sometimes to figure out when you don't know entirely what you're getting into from the beginning. So, um, yeah. What are your favorite AI tools right now? I mean, I have boring answers to that because it's the same thing that everybody else is playing with these days, but, uh, I, I use chat GPT on an almost daily basis now. Um. I found myself interestingly using it, uh, in place of Google for search on things that Google doesn't do a great job with. So, hey, what are, you know, what are other services that are similar to X, Y, Z, for example? And, you know, Google gives you websites that show the, the compilations of services that do certain things or whatever, but they, they're never. They never catch the nuance, for example, of, you know, no, I like this one because it does this. What else does that? Um, and I find that chat, GPT is actually really good for kind of helping me discover things that I wouldn't have otherwise found. Um, and then the other one that I've been playing with a ton lately is Mid Journey. And, um, I've been playing with, uh, some voice AI things. Uh, there's a company called 11 Labs that has a really solid, um. Uh, kind of voice transformer that, you know, you, you submit five minutes of your own voice basically reading whatever you want and it clones your voice. And so, um, I kind of took on a little personal experiment of, uh, generating an introduction video for Apollo 21 using only AI tools. And so I had chat GPT generate the script, and then I cloned my voice in 11 labs and, uh, had it read the script. Then I took the audio file and, uh, an image generated from Midjourney and put them both into an application called DID that kind of pulls it all together and, uh, animates a still photo of that, uh, that audio clip. And so, um, it was just kind of an experiment to see how quickly I could get a video made. Um, but it was a, a fun journey of how do I string these tools together? And of course. Um, provides a lot of thought fodder for things that we might wanna build that provide value, um, based on what we're seeing in other places.

Sean Weisbrot: Well, I wouldn't say that was a boring answer. I think it's quite valuable. Well, I, I just interviewed a guy who uses some tools like 11 Labs, and he cloned not only his voice, but also he made a digital avatar of himself that, um, now creates videos for him with the audio. So he, he uses chat, GBT to make. The script. He uploads the script into 11 labs, downloads the audio, throws it into this other program, and it makes a video of him with his digital avatar and the 11 labs voice. The only, the only thing that's funny about it is he's, uh, from Ukraine and he has a heavy accent and the voice that comes out from 11 labs sounds American.

Danny Nathan: That's funny. No, what you're talking about is exactly what I, what I was attempting to describe. Uh, DID does the same thing where you give it an avatar and a script and it spits out a video of the avatar speaking the script. And so, uh, he might be using DID then. Interesting. Yeah, yeah, yeah. Um, you know, the idea, the idea that you can create video content faster and kind of churn it out based on, you know, oh, I want a video version of my blog post that I just wrote, or whatever it is. Um, suddenly makes that kind of workflow a very interesting opportunity. And, you know, of course, as we're talking about automation and we're talking about the four or five, whatever, different tools that, um, that it currently takes to string all of that together, uh, you begin to see opportunity in terms of, you know, that, that moment of video creation and how you, uh, how you string the pieces together into something that's more usable so that you don't have to, you know, go to the buffet line and pick a little from here and a little from here, and a little from here to create the final product. So how can people follow up? You can check us out@apollotwentyone.io. Uh, we're on all of the socials as Apollo 21, io, or some variation thereof. Um, feel free to email us at hello@apollotwentyone.io or IMD as in Danny, N as in nathan@apollotwentyone.io. And, uh, we love hearing from people.

Sean Weisbrot: All right. Thank you very much for your time and energy. I appreciate it. Danny, don't forget that entrepreneurship is a marathon, not a sprint. So take care of yourself every day and. If you're listening to us on iTunes, please leave us a review. We've been doing this for three years almost, and we only have four or five star reviews, so I would love to have some more of those. And if you're listening to us on YouTube and you're not a subscriber and you've gotten all the way to the end, please subscribe because 99% of the people that listen to my videos do not subscribe. So thank you very much and we'll see you in the next episode. Thank you, Dan.