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

We are going to talk about all things GTM AI, and I'm going to lay out 5 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 AI, I 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 3 hours messing around with deck generation tools and, uh, other platforms to see if I could one-shot the creation. And then I ended up spending an inordinate amount of time editing stuff. And, uh, 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, uh, fallible and I'm still learning myself. With that, I'm going to hop into a little bit about Owner first, and then we'll dive into the topic. So we're a vertical AI company that, and we serve independent mom and pop restaurants. So you can think of us as HubSpot plus Shopify for little tiny takeout places. And so we'll do everything from their website, email 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 4 years. We, I started around $2 million ARR and we serve this mission passionately. Our mission is to arm the Davids of the world to fight their Goliaths, the big, huge corporate restaurant companies who are squeezing out independents. 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. A $150K 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 SaaS 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, uh, 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, our outbound BDRs as of last month, per BDR, close over $100,000 in ARR per month. So they are generating $100K 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. So before I lay out these 5 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. Uh, 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 email, make it better. Uh, we'll call that level 0. Then many companies are here at level 1. They, you have people, maybe individual reps, maybe your RevOps or those teams building custom skills, some custom GPTs, 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 1 to 2, 3. No one's really at level 4. That 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 AI 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, uh, 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 organization. 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 spending time with so many of these companies is that this gap is widening fast. 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 of output 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. All right. So I'm going to lay out the 5 decisions that I think people should be thinking through today. So decision 1 is whether or not to have a centralized versus a decentralized model for AI and go-to-market. Like, who owns the mandate for AI innovations? Number 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 lay out 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 5 decisions which we're going to unpack. All right. Decision 1 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 Claude skills and apps and vibe coding. And this tends to be like a let a thousand 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 rep at Claude, 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, that's the important caveat I'll say, because I'm gonna make the argument for a centralized approach if you haven't already figured that out. 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 Adrian Rosenkranz, who is the CEO at Webflow. I have a podcast called the Revenue Leadership Podcast. And so if you like this stuff, this is all I talk about. And what he said a couple of weeks ago was a director had brought him a really cool app that he had built. And it was interesting, but the question that Adrian 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 Stuart 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 3 hours to build a Claude skill that writes you mediocre emails is not a part of that core role and is 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 oftentimes 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 20, 40, 50% better than what a rep might build. It's 5, 10x better. Like I'm pretty savvy. I build a bunch of my own stuff for personal workflows. And when I see an output that YG, who's 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 to restaurants, so we say a common thing we say at 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 gonna 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 this 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 workflows and those agents in the surfaces that they're already using. In Salesforce, in Salesloft, 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 email, 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 sprawl. All right, decision number 2, build versus 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. Okay, that might be a candidate that you're buying that piece of tooling. How customized do you need it? Is what you could get off the shelf, like 90%, 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've just spent 2 super expensive engineers. Working on something for a matter of weeks. Again, that's like a good direc— a good framework for which direction you should go, build versus buy. Number 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 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, I'm 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 two examples that I think highlight this pretty well. So. We've thought about building lots of stuff, but it's just like an assume, 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? 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. Okay. That leans 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 OneMind, 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 endeavor 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. Okay, 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'd 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 our AI PCR, AI Precall 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 build 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 2 weeks of 1 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 1 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 our customers, that our 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 Salesforce. I think if you take that framework and you apply it to Salesforce, this is why I don't think that they are at a disruption risk. You've got a bunch of AI tools in there like Momentum. Which again is like a hard technical problem. It's something that I, it cannot go down for us cuz so many workflows flow off of it. Datalink, hyper-specific, difficult technical problem. Avara 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 a, these are a few examples and I wanted to just share some of our stack. Okay, 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 1. I'm trying to figure it all out. It's like a cliché at this point, but 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 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 inbound SDRing 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 Salesforce fields as we want. Anything my brain wants to know about our sales and customer experience, I can write a prompt for, build a Salesforce 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 because 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. Okay, 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 with 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 support? Mapping these payoffs 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 Bets and How to Decide. And so now I've, I get the expected value of these projects and now 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 change is it? Am I asking people to fundamentally invert their behavior 180? Okay, that's a lot of perspiration. Human change is difficult. And if you take your payoff 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 out, 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 management is the number one challenge that you're gonna go, that you're gonna 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 this applied AI team is doing. When I tell my team, hey, YG's going to come, he's in New York Okay, 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's going to get easier. And so when I ask 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 gotten 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. Uh, 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 to 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 wishlist 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, I'm open-minded to it. I've seen it work a bunch of different ways. A lot of people have it in their RevOps team. Our applied 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 have 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 role 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 it's got to live with somebody who really cares. That's the key takeaway. This is, so 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, uh, 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 could be technical from a CS and engineering background. I've seen RevOps people convert themselves into this applied AI 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 RevOps team uses AI. All over, like all the time, but this person who's building technical foundations, I think should have a more technical, uh, 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 learn a lot of this stuff from, he had this great framework. He was like, job's just a big bundle of tasks. And in this AI world, we need to unbundle all those tasks and think thoughtfully about, okay, 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 could 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 BDRs 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 onboarding teams or things or roles collapsing onboarding 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. 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 toolkit 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 gonna talk about lossiness in a second, there's this in-between where we have a deterministic framework where decisions get made, sometimes 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 email based on all of this stuff, you have 5 different generative steps. If you slap them all on top of one another, the email 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, inspect an output. And you can do this in that workflow where things are delivered to reps. Okay. Say you're an enterprise rep, you, who wants to be more selective about their book. An 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 gonna build something, you're gonna try it, and the output's gonna be like, okay, most of the time. And then you have to go back to the prompt that, that was used to generate it, 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 dataset that you can compare your outputs to and give the model what the answer should have been. 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 GTM, I 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 and 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 try it a couple of times, ah, it'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 break through to like real, to real value. I know that is for me with all of my personal AI productivity stuff is just you're grinding through it. And it was funny because last night I was at an event and somebody was like, oh, didn't you try Claude Design with it? No, I didn't try Claude Design. And then it one-shotted the deck earlier today, which I didn't use that version, but like you learn as you go and you 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 and 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 gotta 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 one. 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 underdiscussed 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 Tan has awesome stuff on it. Go follow him on Twitter and just go through all of his articles. I've taken a lot of inspiration and I 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-brain, but your personal productivity and personal compounding AI stack. But you gotta 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 4 places that I would suggest people start. So one, you gotta 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 the two Andrej Karpathy videos. They're like 3 hours each and they give you the best baseline I think exists. And then I would direct people to the Gary's Hands stuff and Peter Steinberger, who was the OpenClaw 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 OpenClaw, it could be Hermes, it could be just using the Claude stack or Codex, 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 context, 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 gonna spend hours, like 2, 3, 6, 8 hours just grinding through. That didn't really work. I'm gonna change this. I'm gonna do some research. I'm gonna ask Claude, hey, The output's this, why is that? And just go over and over and give me that again, give me that again, do it again, run it again. And then you're manually, 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 email. So it's like a pre-written email. It doesn't need to be generative every time. It sends this one structured email. and then it's got a Tally web form, and I picked Tally because it's got webhooks. And so the guest fills out what are some of the topics they have interesting non-consensus beliefs about. What do they want to, what do they want to spend time discussing? And then this gets pulled into my OpenClaw 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 toolkit 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 1 or 2 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 a Gary Tan thing based on the LLM Wiki work that Karpathy 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 call to arms from our great host, Jason M. Lemkin. He said this on the last, one of the last 20VCs is you gotta lead from the front. You have to lead 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 gotta 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 would just say, if you haven't already, now is your call to action. Go out 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.