SaaStr 856: AI-Native GTM 101: The 5 Decisions Every Founder Has to Get Right with Owner's CRO

Unpacking GTM AI: An Introduction and Owner.com's Success Story We are going to talk about all things GTMAI and I'm going to lay out five decisions that I think every company should be considering and making as quickly as possible before we jump in. And we talk about all the cool stuff that owner's done in AII. Want to actually share a big AI fail because I think properly sets the landscape of what we're all dealing with. Yeah, we're going to talk about a bunch of really cool results and things we've built. And yet in building this deck, I probably spent three hours messing around with deck generation tools and other platforms to see if I get one shot the creation. And then I end up spending an inordinate amount of time editing stuff and AI is all the rage. We've got all sorts of cool outputs and tools and yet there's still a long way to go. And even somebody who talks about this topic a lot, I am extremely fallible and I'm still learning myself with that. I'm going to hop into a little bit about owner 1st and then we'll dive into the topic. So we're a vertical AI company that and we serve independent mom and mom and pop restaurants. So you can think of us as HubSpot Plus Shopify for little tiny take out places. And so we'll do everything from their website, e-mail and text message marketing, online ordering, custom branded app, a bunch of other tools to help them grow online. We're approaching 100 million ARR. I've been with the company for about four years. We I started around 2 million ARR and we serve this mission passionately. Our mission is to harm the Davids of the world, to fight their Goliath, the big, huge corporate restaurant companies who are squeezing out independence. Our job is to give them the tools that all these big companies have and let them find success for themselves, because we all very much believe that this is the local tapestry and heart of the neighborhoods we live in. I want to start with our bona fides and some of the outcomes that we've been able to draw with a very aggressive application of cross of AI across go to market. And so a few of the ones that really catch people's eye is at the bottom. You can see we've got a 20X close one to OTE ratio, 150 K Rep is bringing in over 2 million in ARR per year. And that's an average number. That's just not, that's not just one or two special reps. And we're also not selling tokens. We're not one of these companies that sell an account and then they just burn a zillion tokens and monetize in that way. We're selling traditional SASS with a bunch of AI into it. Also compared to our benchmark peers, because we sell to SMB, which is a challenging market, the ARR per Rep is about 4X what I see from our direct competitors. And so this is the output, This is what we've spent all of our time and energy doing, driving incredible efficiency into this motion by making reps better, more productive, scaling marketing with all of these investments. Even on the outbound BDR side, a topic of much discussion are outbound BDRS as of last month per BDR close over over $100,000 in ARR per month. So they are generating 100 and K in close one per BDR across that team. And again, that's an average. And so when people say outbound is dead, obviously we disagree with that. But the way we do it is really different. We're going to get into a bunch of that today. Navigating AI Maturity: Understanding the AI Sophistication Ladder So before I lay out these five questions, I want to frame us in this sophistication ladder. And so you can use this as a way to think about where you sit in the maturity curve of adopting AI in your go to market. So level 0, most people aren't there anymore, but that's like random reps using ChatGPT as a replacement, as a search engine. And maybe they copy paste some stuff in, rewrite this e-mail and make it better. We'll call that level 0. Then many companies are here at level 1. You have people, maybe individual reps, maybe your Rev OPS, those teams building custom skills, some custom GBTS, things that are reusable. You have to slack your teammate the markdown file, and then they put it into their own system. And now we're starting to get a little bit more leverage from AI. But a lot of people who are here also feel like we're doing all of this stuff and the outcome isn't there. I'm not getting the output that I want. And we'll talk about specifically how to progress the organization from level 1223. No one's really at level 4. Level 4 is like a recursively self improving system that inspects itself and builds new tools to get better. Owner is not there. I talked to a bunch of the smartest people in the space. Most I haven't found any evidence of this yet, but that's the that is the end state which we will end up in in the not too distant future. Level 2 is where you start to see go to market engineering teams. For us, it's an applied IT by organization and they are automating end to end workflows. They're building tools that just get a job done and that could be manufacturing pre call research that you bring to the Rep or it could be lead scoring. But these are workflows that are running with some level of full automation. You've got agents, whatever we feel like just defining as an agent these days. And so a lot of companies are finding themselves in Level 2 and starting to get that real positive feedback. They're seeing win rates rise per BDR and AE production, improve retention rates, and we're starting to get some real value. And Level 3 is what we'll spend a lot of time on today. How to get to to Level 3 is I think what is in front of many of us today and is very possible. And so this is infrastructure and true leverage when you're building systems and tools that can be plugged in across the organization and make everybody better. And so this tends to be centralized. And so it's a deployment platform. So the app that your sales manager designs on his weekend can be brought to a full production capacity and launched across the organizations. It's shared skills that everybody can plug into. It's a context library that makes everything that you build better because it has a core set of understanding about your business, your product, your company. And we're getting real leverage here. And this sophistication ladder was inspired by Brendan Short, who writes The Signal like a very forward thinking AI practitioner. And what he's noticed in, in, in spending time with so many of these companies is that this gap is widening fast. The the companies who are firmly in Level 3 are starting to widen the gap compared to their peer set, because this is exponentially valuable for us as organizations. It's not like a 10 or 15% lift. You're starting to see the doubling about put on a per person basis or things being done without touching humans anymore. And so Level 3 is like really where we want to get to and because it is competitively existential for us. Decision 1: Centralized vs. Decentralized AI for GTM Innovation All right, so I'm going to lay out the five decisions that I think people should be thinking through today. So decision one is whether or not to have a centralized versus a decentralized model for AI and go to like who owns the mandate for AI innovations #2 build versus buy. Everybody's talking about it right now. I'm going to talk about where to start in a decision making and a prioritization framework. We'll talk about the people stack, like what do these teams need to look like? What are the skills that you're looking for? This is a really important decision for organizations to make and then layout a framework to think about whether or not you should be building things that are assisted copilots versus fully agentic workflows and what role do humans play in this whole thing. So these are the five decisions which we're going to unpack. All right? Decision one is centralized versus decentralized. And the decentralized approach is a mandate to your entire company that everybody's got to be AI native, everybody's got to be building stuff, everybody's got to be doing things and building their own quad skills and apps and vibe coding. And this tends to be like a let 1000 flowers bloom and see what happens. And there's a lot of benefits to this. You build a lot of AI literacy in your organization having a fully decentralized approach. However, the downside is these tools and skills and workflows tend to get locked away in small groups of early adopters and it doesn't deliver to you the broad impact that you want. And what I see is a decentralized approach often has companies stalling out at level 1 or level 2 of this maturity curve. I will caveat this and say because the companies that counter argue this point are generally the ones that sell AI. If you are a rapid clod, you have to be fully AI native. That's a part of your job. You have to be able to sell the product. And so if you're selling tokens for a living or if your product is a wrapper around tokens, then a decentralized model can make more sense with centralization bolted onto it. So that's, that's the important caveat I'll say because I'm going to make the argument for a centralized approach, if you haven't already figured that out. And the centralized approach is a small group of experts that are building this for your teams and bringing things in into production. And we'll talk about the best ways to do this, but the key here is that the quality bar is so much higher. And you there is a compounding nature to an approach where it is more centralized because the expertise is there. They're building all of these, all of these things into one cohesive package as opposed to being it being disparate. And this is how we get to level Level 3 and level 4. The other thing that is a real problem with a decentralized approach, and this is a quote from Audrey Rosencrantz, who is the Sierra Web Flow. I have a podcast called the Revenue Leadership Podcast. And so if you like this stuff, this is all I talked about. And what he said a couple weeks ago was a director and brought him a really cool app that he had built. And it was interesting. But the question that Audrian asked was like, is this helping you be on more customer calls? Is this helping you actually move the needle? Or does this feel like work because it's exciting and fun and we're building stuff? Or is this like AI performance theater? And Stewart Butterfield has a great quote. He talks about hyper realistic work, like activities and things that feel like I'm doing my job but aren't doing my job. My your job as a Rep is to be in front of customers and help them make great decisions. And you playing around for three hours to build a clod skill that writes you mediocre emails is not a part of that core role, and it's probably not a great use of their time. And so this decentralization can feel like it. It is empowering everybody to go do lots of interesting things, but often times it actually takes people away from their core responsibility so much so that the value can be negative. This doesn't mean we don't want ever to get interesting ideas from the bottoms up. Of course, that is a great place that innovation comes from. But my argument is that you need a central team that is bringing these things into production because in our experience in working with our applied AI team, what what the applied AI team builds isn't just twenty 4050% better than what a Rep might build? It's 510X better. Like I'm pretty savvy. I build a bunch of my own stuff for personal work flows. And when I see an output that YG, who is my partner in sales applied AI, what he builds is just like infinitely better. And I could have never imagined getting to that level of sophistication and building it. And so why have 20 people build something to a like mediocre level of proficiency when you could have those ideas centralized and build something that is just like way better? That is my core argument for centralization. And there's some things that are required. You need central resources. They need to be empowered to go build. We sell the restaurants, we say common thing, we say owners let them cook. Like you have to let this applied AI team go and chase really interesting, new and novel ideas and give them a lot of agency to deeply embed in the functions that they partner with. It requires a bunch of data foundations, which we're going to come back to, and context, which is like a thing that's really difficult to answer and is like one of the unsolved problems. But if you have a proper team doing this and spending their time on it, it is my argument that you'll go much faster. And so in the centralized model, the Rep is no longer spending a bunch of time building tools and running their own agents. Like you see vendors be like, oh, and then the Rep can kick off these agents and do this agent stuff. I actually don't really want the reps running agents per SE. I want to run that all centrally. So the quality is extremely high. And then I want to share the outputs of those work flows and those agents in the surfaces that they're already using in sales force, in sales loft in, in whatever your engagement tool of choice is. Because again, it can be a distraction if you're running and managing agents as opposed to saying, here's what we've, here's what we've produced for your pre call research with your, for your follow up e-mail for your, your tiered and scored account list. And just give it to them in the surfaces that they're already using because we have so much surface for all. All right, decision #2 build versus buy. Decision 2: The 5-Question Framework for Build vs. Buy My opinion is that you should be buying your infrastructure and building your intelligence. And so these are 5 questions that you can ask yourself if you're thinking about if you should build versus buy this thing. And we'll talk about some examples. So how important is stability and uptime? Is this a critical piece of business infrastructure? And if it goes down, things are bad. Like people are panicking, OK, that might be a candidate that you're buying that piece of tooling. How customized you needed is what you can get off the shelf like 90 percent, 95% of the way there. What is the ROI? Like, how technically difficult is this thing to build? And what is the ROI on those resources? Because it's easy to get excited about something, build it, and then the gain is incremental and you just spent 2 super expensive engineers working on something for a matter of weeks. Again, that's like a good direct, a good framework for which direction you should go build versus buy #4 is you. In my opinion, you have to own your intelligence. If you're using tools that lock away critical business context and critical intelligence and behind a black box, I'm concerned about that. And we'll talk about some examples, but your proprietary lead scoring model or the way that you want to run a specific deal and manage an account, those are important pieces of intelligence for you as a business. And I generally want to build those things myself. And lastly, does it give you a real competitive advantage? Because if it doesn't like, why are we spending our calories there when there are so many interesting things to go build? And so I'm going to give you 2 examples that I think highlight this pretty well. So we've thought about building lots of stuff, but it's just like an an assumption that yeah, we're not going to go build a dialer. Like why would we? Why would we try to go rebuild Twilio that they have spent immense amount of dollars on this critical piece of infrastructure. And so let's go through this framework. So is uptime critical? Yeah, if your dialer breaks for a course of hours in a day, your team can't do their job. OK, that leads me to buy. How customized does this experience need to be? Does the ability to click a button and have a call go out? Is that a highly bespoke experience for your team? Uniquely, Probably not. Lean to buy. What's their ROI? Twilio is a monster company with a lot of engineers. You're probably not going to want to go reinvent the wheel. There's a big engineering cost. Same thing. We use tools like One Mind, which is AI avatar that lives on a bunch of surfaces and the technical problem of solving for latency and a bunch of other things. It's just not a great endeavour for us. Is it core intelligence? No, a dialer isn't core intelligence. It's just a tool. And does this give you a competitive advantage? Is having a dialer that is slightly better than your competitors going to help you move win rates, move productivity? No. OK, so that's a pretty clear buy. And so if you ask anybody without this framework, would you buy, would you build your own dialer from scratch? You probably say no. And this is what I think is going on behind people's heads. Let's look at a different example, which is something that we have built internally, which is a IPCRAI pre call research. And so how important is stability for our PCR solution? It's not that important. If it breaks in the day, it doesn't matter. All the leads are batch enriched the night before anyways. You can call some other leads. So Bill makes sense there. How custom does it need to be for us? Very custom, our unique positioning in the market, our unique type of customer, nobody's building independent restaurant marketing specific research products. And so again, lean, lean to build. What's the ROI in engineering? This wasn't that hard to build. It was the evals and iteration that that took a bunch of time. And then we saw really big returns on the volume of calls people could make, the quality of those calls, the book rates. And so two weeks of one person leading to a group of 50 BDRS now being able to book 85% more OPS tremendous. That's how we got to that $100,000 ARR close one per BDR number Is these types of investments. Is it critical intelligence for you and you alone? Yes, for sure. Is it a competitive advantage? 100% it is because when we show up and make a cold call it we're we are delivering a very different level of experience, a level of personalization that are that are competitors don't. So this is a pretty clear build and you can use this framework and it's fun to take a bunch of things that you're thinking about and do these side by side. And I think it'll be really informative. You can see some of the things that we have chosen to buy versus what we have built internally. This is why I am like a pretty big bull on a sales force. I think if you take that framework and you apply it to sales force, This is why I don't think that they are at a disruption risk. You got a bunch of AI tools in there like momentum, which again is like a hard technical problem. It's something that I cannot go down for us because so many work flows flow off of it. Datalene hyper specific difficult technical problem of our is our SIM platform again like solving for AI Sims is not worth the engineering the engineering input because I can customize on top of that platform. So this is these are a few examples and I wanted to just share some of our stack. Decision 3: Starting with Data and the 5P Prioritization Framework OK, where to start? All right, this is one of the other big questions, one of the things I get asked all the time. What, like where the heck do I begin this whole journey? I'm at level one. I'm trying to figure it all out. It's like cliche, at this point, just start with the data. You have to start with the data unless you have really good third party data of your entire market. Who are your top accounts? Do you have them scored? Who are in those accounts? Who is the right fit? What is their contact information? And then enriching them with why is your product a good fit for that person or what is your hypothesis of need Having great a third party data and this map of your market is a critical starting point because if you slap a bunch of agents that are doing cold outbound or inbounds SDR ING and your data is mediocre, they're going to have mediocre conversations. So third party data is that entire market map and we need to spend way more time on this than we ever have before. It's always been important, but it's never been more important than today. The other thing that you want to do is capture first party data. So what is happening across your customer journey so I can have a really firm understanding of what's happening and how do I optimize it? I can't run interesting AI experiments if my customer journey isn't well instrumented, if I don't know what has happened across each of these stages and why. And so for us, we use momentum. It basically takes all of our it's our call recorder, and it takes all of our transcripts and fills out as many sales force fields as we want. Anything my brain wants to know about our sales and customer experience, I can write a prompt for, build a sales force field for it, have momentum injected into that call. So when we change pricing, when we evolve positioning, when we're dealing with new competitors, I can have this perfect understanding as you can't ask a Rep to fill out too many fields. They don't do it well, they don't do it at all. But these two things are the foundation for all of the interesting stuff that you're going to build on top of it. OK, let's assume we've got good data. So this is how I like to help people think about the use cases that they want to start with. And so it's this 5P framework. So first I want to map the possibilities. What are the different areas of opportunity that I have in my business to solve for not just solve the AI, but solve for as as business critical. Then I'm going to map the payoff of these possibilities. If I solve, if I solve X problem, it's a $10 million ARR hit improvement. Or is it like a modest improvement of reducing the cost of customer supports? This will mapping these payouts is really important. Then the probability, what is the chance that this thing actually works? Some of our, the AI projects we've taken on are like extremely speculative with with a pretty low likelihood of working out. But if they have a really big payoff and they're extremely innovative, we might consider them. And so those two things, payoff times probability gives you the expected value of that investment. And so this is a riff on a bunch of Andy Duke's work who wrote Thinking in Bats and How to decide. And so now I've I get the expected value of these projects and I want to I want to understand like how much effort is there? That's perspiration. What is the effort by how many people to get this thing to to work? And I want to map not just the effort to build the tool. What is the effort to get this thing adopted? How big of a workflow changes in am I asking people to fundamentally invert their behavior? 180 OK, that's a lot of perspiration. Human change is difficult. And if you take your pay off times your probability, which is your the expected value from this project and you divide it by your perspiration, you don't actually have to write out all these numbers. This is a mental model. You can sketch it, sketch it out into a table. It is helpful. But the actual math here isn't the important part. But you're going to get a priority score. You're going to understand, all right, these are are high expected value bets, high probability, high impact, and they're not that much effort. Bingo. Let's start with those. The other thing that to think about in terms of where to start, especially for companies that are earlier on in this journey, or if you're a big company trying to go through an AI transformation, the change of management is the number one challenge that you're going to go that you're going to run into. And so no matter what you do and what you build, if your reps don't use it and if your reps don't lean in, it's going to be really hard. And so I, if you're newer to this journey, what I encourage you to do is to think about building things in your prioritization framework that are just clearly net positive for the Rep, build momentum with your organization, get them excited about what the supply AI team is doing. When I tell my team, hey, Y GS going to come, he's in New York, OK, he's going to come into Toronto and work on some stuff with you. All those reps are fired up. The managers are excited because they know that he's going to spend 4 days ripping with them solving some problem and then they're going to make more money. Their job is going to get easier. And so when I asked them to change a workflow or prioritize a different list, they're much more open and amenable to it because they have this understanding that and they've gone over the fear that we're trying to replace them because a bunch of companies have not been helpful in the market with this everybody's getting replaced messaging. So there is some fear. And so I think being able to assuage that fear is really important to get the momentum that you want. I knew I had too many slides, so we're going to skip this one. Decision 4: Building the Right AI Team and Rethinking Job Functions All right, decision 4. This is the people stack. Who does this thing and what are they going to do? So we talked about centralization. I believe that you need a centralized team of super experts that you got probably got to pay a bunch of money for and they need to drive this transformation. They can bubble up ideas. You want your reps talking to them and bringing them their wish list 100%. But this team needs to own it and you need to build it and then cascade those things down. We do small pilots as we work out the kinks and then we roll things out more generally where this lives minded to it. I've seen it work a bunch of different ways. A lot of people have it in their revamps team. Our apply AI org lives inside of our data function. Sometimes it reports directly to the CEO or the CRO. That depends on how your own org is designed, but it has to sit with somebody who is cracked themselves. They are really excited and AI pilled and willing to push hard because you're going to push through a bunch of things, getting budget, forcing behavior change. Somebody has to be there that is going to shepherd this thing along. They should have some technical acumen. When we originally put the applied AI leader in the budget, it was in my org. We started the process and I just noticed my VP of data. I'm like, you're going to be way more helpful for this person to solve problems. Let's put that roll over there. They're still embedded with us and do work exclusively on our projects. But you, you have to be thoughtful of where this thing lives. The most important thing here is you got to live with somebody who really cares. That's the key take away. This is so in a, in identifying the AI talent, it is definitely a different job. This is a different job. And there's not many of these people out here. You'll see that top right is Clay's information about how many GTM engineering jobs are posted, which is just insane. And that's probably way more than that today. And so this person, this type of person can come from a few different places. They can be technical from ACS and engineering background. I've seen Rev OPS people convert themselves into the supply day. I function if they're just deep in it every single day. But the big difference is it's not about building the old stuff and doing the old stuff better. It's about trying to do things in a very different and novel way and reinventing the wheel. And so generally we like to hire these people from an engineering and data background. Our Rev OPS team uses AI all over, like all the time. But this person who's building technical foundations, I think should have a more technical, a more technical background. The other thing that's important on thinking about the people stack here is AI should make us rethink the job function. And so when I recorded the podcast with Jordan Crawford, who I learned a lot of this stuff from, he had this great framework. He was like jobs, just a big bundle of tasks. And in this AI world, we need to unbundle all those tasks and think thoughtfully about, OK, where do those tasks actually need to live? Should it live with a machine or should it live with a person and get people doing the things that people are good at and get the machines doing things that the machines are good at. And so you can just take the BDR job, for example. Most BDR job descriptions have building prospect lists and they're doing research and a bunch of companies spend 60% of their BDR hours just like finding the right people to call. That is a bad job for a sales Rep to be doing. And so we're unbundling that and we say BD Rs don't do that anymore. That is done centrally through a core data team. And you can think about this in a few different ways. And so I encourage everybody to be thoughtful about the jobs to be done and mapping that across the customer journey, because we're seeing things that used to be done by sales are now done by on boarding teams or things or rules collapsing on boarding functions and CS functions, AM and CS. You want to, you want to unpack all of these jobs and think through where should these things live and how much of these tasks can get done by AI? And then of the remaining tasks, what is the right grouping? And it this is a big thing that a lot of companies are struggling to think through. And we don't have the answer either. Decision 5: Agentic vs. Assistive AI and Human-in-the-Loop Evals All right, Decision 5 is like, what version of AI needs to be done in what function? And so assistive is copilots. So like a Rep has a tool that they are invoking themselves and in in it's a tool kit that they have, but they're doing all of the decision making. They're coming up with the next actions that should be taken versus on. All the way on the agentic side is just AI workflows and loops that happen totally autonomously. There's no human in the loop. Things just happen. And then that output either happens for the customer and to the customer. It gets done for the Rep. And then there's this in between where, and I'm going to talk about lossiness in a second. There's this in between where we have a deterministic framework where decisions get made because sometimes we human by humans with generative steps because what we see happening a lot is this is lossiness. So the accuracy of the model in each of these steps, there's always some level of degradation or hallucination between steps. And I'll give an example. If you let an AI crawl your website and come up with your value prop and then figure out who your ICP is and then figure out what your positioning should be and go decide who your competitors are and then write you an e-mail based on all of this stuff, you have 5 different generative steps. If you slap them all on top of one another, the e-mail that's going to come out at the end of it is going to be AI slop. And we all know it. We all get it like hundreds of times a day at this point. And what I encourage people to do is be thoughtful about how many generative steps you are chaining together before there is a human in the loop to make a decision inspecting output. And you can do this in that workflow where things are delivered to reps OK, say you're an enterprise Rep, you who wants to be more selective about their book and AI can give them an output and say, hey, I think these are the right accounts For these reasons. But you probably don't want to just send go on the prospecting engine. You probably want an enterprise Rep who might have some other context and nuance to, to be thoughtful about that list before, before that thing gets sent. And so we, we don't need too much of the time we think about all AI or all human and we want to be thoughtful about how these things overlap between one another. And this framework of having deterministic, deterministic components in this chain, I think is really helpful. The other thing that's really important here is evals. And so where AI slop comes from and these like and having too many generative steps on top of one another is you building an app or a program or a workflow and then just sending it out into the world. The unfortunate reality, going back to my brutal experience trying to create this deck, is you are going to build something, you're going to try it, and the output's going to be like, OK most of the time. And then you have to go back to the prompt that that was used to generate at the context you fed it the steps of that workflow and go back over and over and over until you get an output that you feel good about. And a lot of the time, you can automate the evals if you have like a data set that you can compare your outputs to and give the model what the answer should have been. And then you can build like traditionally what people think about as evals when building AI tools, but like we are the eval as well. And so especially for this group as we're thinking about building GTMI, think the human eval is probably the more important step here because we need to spend the time and inspect these outputs and be and bash your head against the wall. Be like, it's not quite good enough. It's not quite good enough. I'm going to tweak this. I'm going to tweak that. It's getting worse now what's going on? And you have to go through this process. And I think this is the biggest place that people fall down is they give up, they build a thing and then they just launch it or they build a thing they tried a couple times, that's not good enough and then they give up. Building The thing is really easy. Building the MVP is really simple today, but iterating on it and spending the time and grinding through it is the thing that I think helps breakthrough to like real to real value. I know that is for me with all of my personal AI productivity stuff. It's just you're grinding through it. And it was funny because last night I was at A at an event and somebody was like, Oh, didn't you try cloud design with it? No, I didn't try cloud design. And then it one shot of the deck earlier today, which I didn't use that version, but like you, you learn as you go and you'd have these conversations and you like, now I will be better anytime I need to generate something like that's where I'm going to go. But it is that learning loop that's really critical. All right, these are the takeaways. These are the decisions that I would go encourage everybody to think through centralized versus decentralized. My personal opinion is a centralized model is the way to go. You could have decentralized innovation and ideas, but making sure that there is a team bringing these things to production grade is really important. What do you build versus buy? Build your intelligence, buy your infrastructure. Buy the stuff that needs uptime, that is boring and undifferentiated. Where do we start? Start with the data, then your prioritization framework. Then go give your team some wins. Earn trust, build momentum. The people stack, who owns it, who runs it? It's that centralized team and it's got to be technical. You these have to be like legit technical folks with engineering chops if you want to get to Level 3 and eventually level 4 and then agentic versus assistive. We've talked about the importance of human in the loop evals and spending the time and grinding. All right, I want to talk about 1. Cultivating Your Personal Compounding AI Stack: A Call to Action So we're talking a lot about AI for our companies and how to build this, but what about us? I think this is probably under discussed and we really need to think about as leaders our personal stack, our compounding AI system that we are going to build and is basically our intellectual property. It's our GitHub repos, it's our skills, it's our personal context that we're using and and bringing with us wherever we go. And so Gary's hand has awesome stuff on it. Go follow him on Twitter and just go through all of his articles. I'm talking a lot, taking a lot of inspiration and I'd really like this quote where he talks about a lot of people want productivity. What are your productivity hacks with AI? And he doesn't think about productivity. He thinks about how do I build things that compound over time, that learn over time, that get better over time and skills on one on top of another give you a a competitive advantage. And so whether it's your meeting notes getting ingested and then adding to your personal context file about how you make decisions or the action items that you need your, your areas of opportunity, these things get better over time. And then you read something you're like, Oh, this, I really like this principle from this book. You can add this to your personal second brain. He calls it G brains, but your personal productivity and personal compounding AI stack. But you got to build. You just have to go do it. There's no way to learn other than getting in the tools and doing this yourselves. And so these are the four places that I would suggest people start. So 1, you got to learn the fundamentals. What is it about these models that make them act the way they do? What is pre training and post training? What's the difference and why is that important? You want to go learn the primitives so that things downstream make sense. There's a 2 under Carpathy videos. They're like three hours each and they give you the best baseline I think exists. And then I would direct people to the Garry's Hands stuff and Peter Steinberger, who was the Open Claw founder. Start there, Start learning about these things. It'll be overwhelming at first, but pick some harness that you want to commit to. It could be Open Claw, it could be Hermes, it could be just using the clawed stack or codecs. But pick something and be like, I'm going to go all in and I'm going to build my infrastructure here and cram in my contacts, my skills, all of this stuff, all my connectors. Your system gets better the more you invest in it with connections to other things, with compounding assets like skills. And then just pick a project. Just pick one thing that might seem silly at first, but just drive it to ground and do not give up until the output coming out of that you're really proud of. And you're going to spend hours, like 2368 hours just grinding through that didn't really work. I'm going to change this. I'm going to do some research. I'm going to ask Claude, hey, the outputs this, why is that? And just go over and over, give me that again, give me that again, do it again, run it again. And then your manual, you are the human eval until that thing can get to to a good place. And then you can turn that into a skill. And then that's replicable for the end of time, the way that you want to coach one of the people on your team or the way that you want to make introductions to your network. You can build skills for any of these things. You just have to do it a whole bunch and test and iterate. These are some of the things that I've built in my personal system, I think are just useful examples. The workflow I built was a guest agrees to come on the podcast, my agent sees a positive response to our outreach and then just automatically sends the intake e-mail. So it's like a pre written e-mail. It doesn't need to be generative every time it sends this one structured e-mail. And then it's got a tally web form and I picked tally because it's got web hooks. And so the guest fills out what are some of the topics they have interesting non non consensus beliefs about. What do they want to what do they want to spend time discussing? And then this gets pulled into my open client instance. It kicks off a research skill. So ingest everything about this person that you can find online, and then you find these little things like it can't scrape in their LinkedIn stuff. You go, all right, what are the tools to scrape LinkedIn? And you can add that to your tool kit and your skill, and then you run it again and run it again. And so this workflow took me forever to build probably I probably put 6 to 10 hours into it and I iterated on it every once in a while and now it saves me like hours a week. I don't do any podcast prep. It does all the research. I basically have it give me like 5 ideas of key topics. I pick the one or two that I like and then it one shots the docket. But I, it wrote a lot of dockets that were really bad and obvious and boring until I got it to a place where the thing came out of it and it was useful. The generation of the newsletter even like creating assets that I can pair with publishing the podcast, like LinkedIn carousels, surprisingly annoying to build, but it was worth it. And these are compounding systems. And then every time I do a podcast, it ingests the whole thing and puts it into my into my knowledge graph. It breaks apart the transcript into what we call atomic ideas and stores them. So if I want to reference those things later, I can go and it's all properly stored. And that's again, like Gary Tan thing based on the LLM Wiki work that Carpathy did. So that's a good example. There's a bunch of unanswered questions, which I'm not going to spend much time on because I want to have some time for questions. But the last thing I will leave us with is this Colt Arms from our great host, Jason Lemkin. He said this on the last one of the last 20 VCs is you got to leave from the front. You have to leave from the front in this. You have to go build your own tools. You have to really make the commitment. You can't have your team be the source of all the innovation. You got to do some stuff on your own. And there's a bunch of super smart people in here. I love the Jeff Charles quote from ramp. Your job, if you want to keep your job, is to automate your job and then do a new job that's on top of that job. And so I, I would just say if you haven't already, now is your call to action, Go and build some stuff. It's going to suck for a long time, but this is how you'll learn and you'll make yourself irreplaceable in the end. All right, thank you. I really appreciate the time and attention. And go get them.