No SDRs, No CS, 7 People: Inside Swan's AI-Native GTM | Amos Bar Joseph

Hello, morning or evening. Hello, hello, Jerry.

How can you— can you hear me well?

Uh, yeah, go again. Yeah, it's, um, a little bit far. I don't know why.

No, yeah, just a sec. See. How about now?

It's, it's okay. It's about the same, but it's okay.

All right.

So as you guys are joining, love for you to drop in the chat sort of what industry you're working in, and then, um, like how many people work at your company, because we're going to talk about that a lot today, how to do a lot with a little. I want to see, do we have people here that are 1 or 2 person shops, or, uh, Or big enterprises, or mix workforce auto orchestration. Forty people. Okay. Huh. Business strategy, it's helping 20 people. Hey, Mo, so what's the sweet spot for Swan's customers in terms of like employee size?

Yeah, we have 2 types of builders. We have teams that let's say Series A to Series C, where they kind of like started their AI GTM transformation, but they don't feel like they finished it. And then the other type is more like these AI-native small companies that are trying to scale with intelligence, not headcount, and they're like fully agentic and they, you know, always try to push the boundaries of what humans can do. So we have like these 2 types of builders are coming to us.

Hey, Blake, that's fine with the, the notes recording. I'm— I should be recording this and I'll be posting it. to the YouTube channel later. Hey, everyone, if you're just joining, welcome. Excited to have you today. Asking people to drop in the chat sort of what, what industry they're working in and how many people at their, at their company. So far we're in the 2 to 50 range. How many, how many podcasts you think you've been on at this point?

Um, well, I'll, uh, I'll answer it differently. I have 2 today.

Oh my gosh. Wow. Yeah.

So, um, I would say it's in the hundreds, uh, in the last, um, year and a half. In the low hundreds. I want to exaggerate, in the low hundreds.

Yeah. Did you get— were you good at it 2 years ago, or was this trial by fire?

I think I had always like the potential. My starting point was relatively high, but now I'm much more, you know, I'm a sharper pencil. Today, I can say.

Yeah.

How about you, Jared? How many podcasts did you host? Let's see, webinars included.

Of the Go-To-Market Engineer School podcast, and I'd say probably about 10 episodes per season. So, you know, relatively immature. But it's been a lot of fun getting to interview all kinds of folks, learn from the best, share that learning out.

If I pull a gun to your head and ask you, tell me about the episode you remember the most, which one is it? Go fast.

Well, I mean, Guillaume Carbone is— I mean, he's every time I— he's light years ahead of everybody else. So his I think the session we did with him and the session we did with Yash from Clay last season also, both of these guys just have a perspective on the industry and technology that very few people have. I could just listen to them endlessly. But then we've had practitioners like Josh Whitfield and so many others that are just in the weeds of this every day with so many customers. And so they know, they know all the pitfalls, you know, they know all the projects that failed. And, you know, it's so where, where to start, where to start from so that, so the company sees value quickly. So yeah, I've enjoyed a lot of them. Good. Still got people streaming in, but got a pretty good crew right now. Guillaume Cabani and Yash, I think. Davide? Oh, I'm not sure if I'm answering your question there. Just looking in the chat. Yeah, if you just joined a minute ago, I'm just asking people to drop in the chat like what industry you're in and how many people are working at your company. Well, and help pretty much any other question that you have that you want to get out of the session because we're going to Uh, we're gonna keep it pretty relaxed and, um, and, and, and try to provide some value to everybody here. Uh, B2B SaaS, 8 people. Fintech, below 10 people. So, blue cyber, okay, 300 people. Health tech, 10. So yeah, um, but definitely seems like a lot of folks, uh, joining are in this segment of like We want to grow fast. We don't have too many folks, you know, 10, 20, 30 folks. How do we do it? Now, Martin, you're at a company with 25,000 people, so I think you might have some sharper questions in different directions.

Cool.

All right. Well, listen, I think this is a good time to get going. So look, the title of this is, you know, kind of run your whole go-to-market function as one person. Maybe, you know, maybe a little bombastic, but we'll see how close we can get to that. Amos is the CEO and co-founder of Swan, and in 2025, I think you guys went from, I think I read, 0 to over 200 customers with just 3 founders and 0 and no employees at that point. Is that right?

That's true.

And then this last, this last, during this year, I think I read that you grew to over 300 customers doing 7 figures ARR and, you know, you're up to 7 people, something like that, right?

Yeah, we're huge today.

Huge, huge. Gotta go to Vegas for your all-hands to rent out a big Big hotel. But, you know, no SDRs, no ad spend. You raised maybe $6 million or so in February. And the whole company is built around this one number, this one goal of getting to $10 million in ARR per employee. And I think you're not there yet, but you're closing in on it. I mean, almost nobody's there. Have I got the goal correct there?

Yeah, that's true. We were very much against the old unicorn growth at all costs playbook where, you know, I did that twice. It's my third company. So where you raise a ton of money before you know who you're selling to, then you grow to 30, 40 people before you got to your first million dollars in revenue. And from there on, you try to navigate the ship while it's like super bloated. You can't really implement your learnings because there's so many people to teach basically what you just learned until you get to like a Series B or something when there's like a serious VC that comes and starts trimming the fat and turning you into a real company. But I just, I didn't want to go through that again. And I wanted to build a company that is built differently, designed for this AI-native era. basically, um, with kind of like this notion of scaling with intelligence, not with headcount, at its core. Um, and I, and I thought to myself, how can I align everything around a metric that actually leverages both types of intelligence, human intelligence and artificial intelligence, together? And I realized that ARR per employee does that naturally. kind of puts the focus on the human at the center, but the goal to scale that productivity of that human is by leveraging AI around it. And we're gonna talk a lot about that today, Jay.

Yeah, I think that, that, that, that's exactly right. And, you know, I work in VC and VC— VCs value companies differently now. So like how, how fast your team is growing, It's not a flex anymore. I mean, ARR has got to be growing much, much faster, right? Swan, you know, you're chasing down high growth while climbing towards this rarefied air of $10 million ARR per employee. And so the question I think for the room today is like, how do I get high growth without an expensive hiring plan. And, you know, what is the role of AI agents in all that? And there are some pitfalls. So, so we— I want to get into all that. A quick word on kind of why we're hosting this. I'll get that out of the way. And then what else is coming up this week and next week? So I, so I run Go-To-Market Engineer School, and we, we teach go-to-market engineering, AI and go-to-market. Building the systems that Amos is about to walk through. We do that over 8 weeks. It's a live cohort program. And the reason it's Amos today and not someone else, he isn't up here describing a thing that he's just selling you. He is personally the go-to-market function at a company doing 7 figures with just a handful of people. And so that's the job that we are teaching for. And he's just doing it at the, like, far end of it. Tomorrow we have a webinar with Anthony Goldbloom of Sumbull, and that's going to be about— very interesting— about prioritizing and scoring in a way that you've probably not seen or maybe, you know, aspired to implement. Thursday we're going to be wrapping with Zach and Sam, Zach from Octave, about context engineering. And I know, hey, context, the context layer, super, super huge to, you know, your success and your learnings recently. I'm sure we're getting into some of that, but we're gonna go deeper on that on Thursday. I will drop the calendar invites for those in the chat in a few minutes. Hope to see you then. And then Monday, we're closing registration for the cohort, Cohort 5 for Go-To-Market Engineer School. That's gonna start Monday, the 28th of September. And that's 8 weeks. It's 2 hours live per week. It's— we're gonna have a whole stack that we're gonna be teaching. It's gonna be built on top of Claude, but then you'll get access to Clay, Octave, Swan, Sumble, and then build a capstone project with support from practitioners out there in the field. So hope to see some of you there. Okay, right. Now back to this. Amos, I gotta ask you. Who is a Swan customer that really looks nothing like Swan? Like, how does the value in these AI agents show up differently for them?

Yeah, I think there's a lot of similarity. I'll start with that and then I'll actually explain the difference. But basically, we work with As I've said earlier, with like these AI-native small startups that wanna be on the frontier of building their GTM motion. But we also work with, you know, Series A to Series C startups that are, you know, more further along in the maturity of the company. They didn't necessarily build the company on these AI-native foundations. So they're trying kind of like to steer the ship to be more, aligned with this technology. And there's a lot of complexity there, basically. And the complexity that is actually the most difficult is not, you know, system complexity. It's not really data complexity. It's actually, you know, human process complexity. So we work with, you know, 200-person company. It's not like operating it with 7 people. They have more stakeholders, processes, go across different departments and different systems which have different governance processes around them, etc. And I think the difference with them is to take that journey from, from, to basically from a process that was designed for, you know, humans doing most of the work to a process where humans do the strategic work we want them to do, basically. And that requires a lot of friction, uh, in that process, basically. But it's fascinating to work with them. And, and the, the successful companies understand that they— it's not like just bolting in, um, an LLM call here to do some research. You need to just rethink how should the process look like. And if we start from, from that step with them, um, then we get to Better results much faster, basically.

So how do you do that? Do you drop in and workshop with them? Do you send them a worksheet to fill out, or what? How do you get there?

So we have 2 approaches basically for that. We have the self-serve one, and then we have an FDE motion. But basically, the self-serve motion is for folks that have GTM engineering capacity inside. the team. So it doesn't need to be like a GTM engineer. Maybe they have an SDR that is like an AI-native builder, or, you know, we have one of the founders took it on its own to actually, you know, build the agentic processes of the company. But they have both the mental capacity and some kind of like builder proficiency orientation. They don't need to write code or anything, but they just need to have that orientation. If you have both of that, then you can self-serve. And then if you self-serve to Swan, then Swan is your helper in that sense. We have a lot of— I always love telling our customers that Swan is an AI with good fucking taste in GTM. Okay? And that taste is our taste, basically. We've built a lot of, you know, the skills and, you know, Swan has a lot of opinions and a lot of stuff because that's what we believe that matters the most in an AI-native world is like the teams that is building it, like their opinions. Not really how fast can it write code, because that could just end up with a lot of slop. So for the self-serve motion, you talk to Swan, you try to break it down, and that builder tries to kind of like with that brainstorming and ping pong motion, try to redesign the processes basically. For folks that need more help driving that transformation, We have basically an FDE motion where we work with like top-tier implementation partners that are the best in the market. They bring— they are super users of Swan. They bring both the connection between being AI native and knowing how to run GTM transformation for more mature companies. And together we try to both educate, enable, and actually help build these new agentic processes for those bigger companies that are more complex.

Okay, so, so, so you are, you know, to get to your $10 million ARR per employee, you got to be very careful about not overhiring, right? So, so the self-serve motion, number one, and number two, you've got the forward-deployed engineers, but, but they're through partners.

Exactly. We— you can't really have an FDE motion if you want to get to $10 million ARR per employee. And actually, we, we do believe that For folks of you who don't know what an FDE is, a forward deployed engineer, it's basically kind of like the sexy name for implementations professional services, basically. Folks actually, you know, go to the client, actually help them implement the product. And we believe at Swan that we're in this, you know, gold rush, overhyped period where everybody could just throw a lot of money again on every problem. The product sucks. We'll just throw a lot of like implementation services on top of it. But basically, we think that that bubble will burst, the FDE bubble will burst, and eventually the models that actually present good unit economics will survive, basically. And the ones that just throw a lot of money to just, you know, a company for the fact that they don't really have a good product on top of the LLM, basically, then they won't really survive, and that will blow up in their face. Yeah.

So some customers coming in, however you do it, you identify at this moment in time an FDE would be useful here. And so you apply that, you introduce them to somebody.

Yeah, we, we, we try to build like a system to enable that basically. But yeah.

Okay. But, but, but long term, it's really the self, self-serve motion. Now, now, Let me bring that back to, you know, you mentioned, you know, some of the problems are not really technical or building problems, tools problems, they're more sort of organizational design, decision-making, you know, reworking processes and so on.

Yeah.

That, you know, I don't know, it feels like that requires— maybe I'm thinking old school, but it feels like that requires getting a bunch of people from different departments kind of into a room and, you know, whiteboarding and blah, blah, blah.

Yeah.

And then when I think of like an individual, like a, like a, you know, a PLG motion or an individual trying something out, hey, I put my credit card in, or maybe it's a free trial and I just, you know, there's some wizard or there's some chat and I just start talking to it. It's like, that may, that may solve that person's problem, but, but how do you, you know, how do you design like a, like an onboarding, self-service onboarding motion When, you know, this is basically a blank canvas because agents could do anything, right? So you have this blank canvas, you got one person in the company, and then— but the underlying problem is overall company processes and sort of interactions between teams.

Yeah. So for those of you who are, you know, building AI products or even like interacting with AI products as users, I think that this approach should resonate with you guys. And I feel like that's what everybody should be building towards, and that's what you should be expecting. as a user, for like both sides, basically, as a builder and as a user. So, um, a good AI product, I believe, should act like an AI FD, basically. It— suppose if you are in the layer that tries to mitigate the usage of the model for the user, then that's the, that's the purpose of that layer, the application layer, basically. If you're not building an LLM, then you're enabling humans to work with that LLM. And so if your product is not helping humans to harness that capability to solve their problems, then it's not doing their job. So we see Swan, we call it, you know, an AI GTM engineer. You can call it an AI FDE. But basically, it's supposed to guide you and help you in that process of understanding your goals, understanding your processes, mapping them, where the systems and the data lives, and how do we kind of like redesign that process. It's true that it's not a physical being, so there are some limitations to how it can pull up stakeholders into a call and, and tell them what to do. But it's supposed to also act as a thinking partner in a way. It's also, you know, the, the layer that you build on top of it, your agentic workflows. But it's not enough just to build that infrastructure. You need to have opinions on how to build on top of that infrastructure. And Swan really helps with that.

Yeah, and you know, the sort of onboarding activation processes are where a lot of the good marketing, you know, word of mouth, sort of all that goes to die because, you know, in a typical company, you put all this motion out there in the universe, people come to your site, they sign up, And then they don't know what to do, right? And I, a few years back, I was fortunate enough to go through the Reforge program for onboarding and activation or retention activation, I think it was called. And there's a lot of science and a lot of work that goes into that. And now with AI, with agents, we're sort of rebuilding, we're relearning how to onboard people. How much more successful is onboarding now that you can leverage these AIs that like kind of act— should act like a human versus back in the day where maybe it was just a series of, you know, uh, you know, steps that you would check off? Here's the 10 things you can go do. And then, but it didn't really— it didn't, it didn't take it from there. It wasn't smart.

Yeah, I think maybe instead of Because agents got a lot smarter, models got a lot smarter, and we started building harnesses on top of it that enabled a lot of things that weren't possible before. But instead of focusing on technical side, I actually want to talk about like the evolution of the GTM users basically, which is also interesting because it's not like a one-sided game because, you know, talking to an audience here, folks that are building in the space, they got a lot more sophisticated in the last couple of years as well. And what I think Like, how do you immediately spot like an AI-native builder rather than someone who is more further, less further down the rabbit hole? Is that, and I think that AI-native builders, they focus on the process. Okay? That's what they do. They understand that the process is everything, basically. And if you're not really an AI-native builder, then you're focused on the work. What does that mean? You wanna send a message, you wanna personalize an email, you want to research an account, right? But if you're an AI-native builder, you wanna understand how do I build a process here that can take an account with a signal, research it, score it, draft an email. I wanna approve it. Do you wanna send it automated? Like, how does that process look like? You start with that process and then all the work is just iterating on that process, iterating and iterating and iterating. And I think what we are starting to realize that this AI revolution is less about replacing work, and it's more about moving humans to think about the process. That's what it is, basically. And you see it in coding and software development. It came first, basically, where people stopped writing the code. So they thought that developers will run out of work. But wow, surprise, developers are working twice as harder than before. And our developers, they don't have, you know, a minute to go to the bathroom. We need like more. It's not like we need less, basically. But what happens is they start to move to think about the process of how do you develop software rather than developing the software. So same thing goes with GTM engineering. And we see that the most savvy, you know, builders, you know, they immediately start thinking about the process. And so to your question, Jared, what we try to enable our users from the agent perspective, from the onboarding perspective, and then as a company from a philosophical standpoint is define the process and then start iterating on it like a motherfucker, basically. Apologies for the language, guys.

Okay. All right. I like that. I like that. And I think, you know, maybe in a little bit we can get— we can double-click on that, get into it a little bit more, and actually maybe even see some of this, how it works. I wanna drop back into kind of the roles that you didn't hire for and then, you know, actually what's behind the hiring decisions that you do make. Like, I understand that like you're not gonna build a CS department and you hired a researcher rather than a marketer to run growth recently. So like, what's the next role that you would I don't know, let's say refuse to create? And then, you know, on the flip side, like what's the one you'd hire for tomorrow if you found the right person? How do you, you know, how do you think about hiring now in this world?

Yeah, so a quick background for the folks that don't follow me on LinkedIn. Jared does, and that's where I get all his intel from. Basically, you know, we don't really have standard titles and roles in the company. I actually do that intentionally. I think that, just inventing new names for roles. What it does basically, it just puts the operator in uncharted territory. It's like, I can't really— I'm not an AE, so I can't do what an AE does. I need to— I just need to look at the problems and see how do I solve them, basically. So it just puts them in this uncertainty that, well, they need to really build the playbook on their own. And that's what I think that an AI-native company should do today is like they should think first principles. basically. Um, and, and that's, that's the main goal behind it. That's first and foremost. So we have a VP of Autonomous GTM, um, which you would— might call a VP Sales, kind of like traditionally. Um, and then instead of, uh, VP Marketing, we have a founding growth engineer. Um, we, we don't have, uh, CS. Um, why? Because— and we don't have support. I just think that AI breaks the paradigm around CS and support. I think that you can, like, most of the revenue, if you're doing things well and you're building a good AI product, most of the revenue should come after the sales, like post-sale revenue, basically. So would you give, like, is that really CS? Like, are they making sure that the customer is successful? Yes, but they also want to generate a shit ton of money because that's where the gold is. They're already yours. There's so many expansion opportunities. So it's like very, you know, it's an attack-oriented CS. That's what that— that's like the new position. Then support, if you look at support, traditionally support is just, you know, answering questions basically and routing, right? That's what like support does at the most fundamental layer is just answering questions. And if they can't answer the question, they route it to R&D basically. Right? So AI is really good at looking at your documentation and answering questions. And if there's an issue, it can route to R&D. At Swan, we're a little bit more sophisticated than that. So basically, our, our AI, which is Swan that does that, can look at a question of a user, can understand if it has the capacity to answer that question. If not, then it actually escalates it to our engineering agents that evaluates it. If it's a low priority, low risk issue, they already solve it and push it to production. If it's high risk potential, they generate the, the pull request already for review for the R&D. So you really kind of like redesign the processes of what support is in an AI-native company. And I think that Thinking first principles really allow you, again, to iterate on the process.

Wow. So I, if as a user, I find something that's buggy and I report it into the agent, it might actually get fixed before a human ever sees it.

A lot of the times you'll get like a message, 30. By the way, we won't tell you that a human didn't fix it. So this is a secret here, guys. You will actually get a message that, yeah, you're, We fix your problem. We humans and we support you. But yeah.

Secret amongst friends. Okay, so you're a 3-time founder. All right. At your last company, at the same sort of revenue level, what hires would you have made without thinking? And is the difference now that you've learned more about how to run a successful startup, or is it the tooling It's just genuinely, genuinely gotten good enough that you don't— that, that, that's why you're making different decisions now.

Yeah, I think that, you know, traditionally, yeah, we would have support, CS, SDRs. We would have more power on the marketing team. R&D would have been bigger, more QA, more managerial layers in between, basically. we would've been like 4 or 5x the size at least, basically, maybe even more than that. I think that there's a couple of things. So one, yes, you know, tooling got better. AI, yeah, that's big. And the ability to actually use agents in a work environment is getting, you know, improved in a accelerated pace. But also, I think that building 2 companies before gave me just the courage to say, I'm not gonna build based on the old playbook. I'm going to explore and understand for myself how should my company be designed. And what I've quickly realized is that one, building an organization differently in a more AI-native manner creates a moat. around your business. You can have the same value proposition building a very similar product to your competitor, but because you've built your organization in an AI-native culture, then you're just accelerating the more AI becomes more powerful, basically. And just a thing on its own, the culture, the organizational design acts as a moat and as an accelerator, basically. And the second, which is almost the same thing, but it creates this AI-native culture that really proliferates into product design, into GTM thinking, into brand, into, um, in position, everything basically. So it really creates this vicious cycle in a way.

Yeah, because you can see this is where it's going, things are going, you're building it for your own company and then, um, you know, like, and assuming that If you're building out the product for other companies that are going to get there eventually, then everything's going to work out. Now, forgetting how each thing is packaged, let's say how many agents or what the names of the agents are, this or that, and that's changed over time. Walk me through the go-to-market function as sort of a list of jobs. And then for each one, let's stop on them and tell me whether the machine does it or you do it. Or you both do it? You know, whether it's demand gen, content, list building, you know, outreach, etc., these types of things. What are the jobs that you think of in terms of go-to-market right now?

Yeah, so I think you can look at it, there's like pipeline generation, and then there's like deals, and then there's like expansion, maybe like 3 different territories that it's like easier to you know, make that division. I would say that in each one, we have this philosophy where we always ask ourselves, like, this is a resource allocation game, okay? Humans are the most valuable resources, okay? And we want to ensure that they get, like, the most strategic important tasks. And then we kind of, like, waterfall below that, basically. If you look at, you know, PipeGen, then it's really easy because, because you have scoring, right? If you— it's maybe it's easy to, to perfect your— it's not easy to perfect your scoring and actually understand what your scoring is. But if you are running agentic operations, if you're running on top of Swan, for example, it's like very simple to build your scoring. So a scoring mechanism is just a resource allocation mechanism. It says this is Strategic, this is not strategic. And so basically our philosophy on Pipedrive, like AI could run an end-to-end process if you'd like from, you know, a research, like monitoring for signals, researching the account, checking the CRM, scoring them, drafting an outreach, and then engaging or escalating for approval, basically. So that The human here is actually a decision where if this is a strategic account and this is like high-value account, we want a human to review. Why? Because we think that there is added value to a human reviewing that process. Basically, it might think of an interesting approach and might be able to synthesize all the context that the AI is presenting in a better way because it has a lot of intuition that it built up. upon years in the trade, basically. So for strategic accounts, humans actually, you know, make the, the final decision, right, on how to engage in pipe gen. And for less strategic accounts, you have a fully automated motion end to end, basically, right? Same thing could go with deals, basically. I think with deals, the difference is more about instead of like you don't really have scoring. It's like it's less about that. You really care about all your deals as an AE. It's not like you have— like deals that you care less. Yes, ACV potential might help here in terms of resource allocation, but you still want to get to a lot of stuff. And I think what helps AEs better, or like in the deals, is that like the cost of an error, basically. I think that's an easier mechanism to decide on whether a human should actually do it or an AI. And I think in deals, the cost— there's some things that the error could be Like, could have like a very high cost to it. And in those situations, basically, you want a human to review. So for example, at Swan, we have our VP of Autonomous GTM that does, you know, a lot of the sales. So Jeremy has a call. After the call, it's like maybe a demo or a scoping call. So Swan takes the transcript, you know, evaluates it based on band. Then presents to Jeremy all the potential actions that it's going to take. I'm going to update the CRM, put a note like that. I'm going to move the deal to this stage. I'm going to write a follow-up that includes this. I'm going to open a deal room with these assets, basically. And there's like a plan of this is what I'm going to do. And then Jeremy can make a decision and say, do it, or no, we don't need to move this. They're not ready to move to the next Deal stage, there's like, I need to follow up on a question here and they need to answer me that before we move it. Or maybe let's bring that asset to the deal room or maybe pushes back on demand qualification or something, whatever, right? But there is a strategic point there that we can identify that reduces the cost of error to almost zero, basically. So we found it, we've put the human there, and then you can scale that operations more and more and more, basically. Yeah.

I like that framework. That makes a lot of sense. And so humans still have some jobs to do.

The most important ones, I would argue, the most important ones. That's how we look at it, basically.

What is the— when you get in the office in the morning, what's the first screen that you open when you sit down? Can you share it? Can you show us what it is you're looking at? What is the agent having you review?

Yeah, I would love to. Let me just open it. This is Swan. Basically, with Swan, you can build apps basically on top of all of your backend. It's a new capability. Just go to my pipeline review app. Which basically that's like my ability to just look at the pipeline in the way that it's very easy for me, like looking at all the companies in consideration. I can actually look at them. I can get like a summary of where things at. Basically, that's how I build it for myself. I can get like the account breakdown here, what's happening. I can ask Swan about this stuff basically. And if I want, I can just talk to it from here as well and chat about like our pipeline. So I love looking at my pipeline. And then if it's more like for the top of the funnel, actually I go to Slack and we have, I have like the, we have like potential MQLs. So this is like just exactly what I've shared with the top of the funnel motion where we have like strategic MQLs that goes here basically. So just looking at this one, Flinks, their CEO liked my post and it's a closed loss reactivation. We didn't have SOC 2 initially, we were like younger. So now we have SOC 2. So there's like a good move here, like who they are, why they're like tier gold is good. It's not amazing, it's not diamond, but it's good. It's worth Jeremy's attention. And then, like, the, you know, the journey here, liked my post of my Anthropic Bills one. They visited our website a couple of times, had a demo. There was a legal review, and we lost it because of the SOC 2. Definitely, yes, definitely interested being notified when SOC 2 is ready. So this is actually great. So Very simple. Jeremy can just say, you know, build outreach to Paulo from Edo. Edo is our— it's our product and the one that actually had the demo with them. So it tells Juan to build it from Edo to Julian and from me based on the closed loss re-engagement subpage of the reach out skill. Now that SOC 2 is unblocked, I can talk about that. I think it's important to understand, like, the context layer that we have, Jared, behind it because A simple prompt like that initiate a very powerful workflow because of all the process iteration before that that happens in the context layer. So it's not like Swan is almighty. We can just tell it to build outreach and it just, you know, knows exactly what to do. You need to define the processes in Swan before that so it knows what to do. And then, you know, both sequences here, I can just take like a Take a look. There's an email. Uh, Paulo, uh, closing the loop from last year. The SOC 2 blocker that paused your legal review is now cleared. Uh, worth revisiting. Now that's resolved. There's a connection request. Um, yada, yada, yada. Basically, they just told it to build the outreach, right? Um, and then, you know, there's from my end also, I'm reaching out to the CEO because we love doing like CEO to CEO. So, uh, Julian, your team evaluated Swan last year. But legal paused over data processing since we didn't have SOC 2. That's now done. Secure is worth a revisit. So just from a simple prompt, you get that. Of course, there's a sequence here of messages that, you know, based on how we run our sequencing, everything is like lowercase. That's Jeremy's style, basically. Like there's a power dynamic. Like I don't, I'm not like beneath you. I'm writing like with lowercase because I don't care. And, you know, yeah, we have tons of folks like you. So So yeah, that's like, that's our style basically. There's like assets that we're actually sharing in that sequence. So Swan already knows, like you can click approve and send it. That's it. So that's like the 2 main points where I, you know, I start my like GTM day. There's like top of the funnel, then it's like bottom of the funnel.

So one of the questions in the chat from Aaron, I had the same question, is does this sort of end up replacing your CRM? Do you actually pop into a CRM or is this it?

Yeah. So there's the technical answer and then there's the philosophical answer. Okay. So from a technical perspective, yes, it could replace your CRM. From a philosophical standpoint, you know, there's depending on, it depends basically. So sometimes you have a system of record for all of your like TAM and all of your, you know, top of the funnel motion. And Swan for a lot of companies captures that type of system of record. And they still have a CRM that is the system of record for the pipeline itself. So there it creates this notion of hygiene and reliability of the data that's important for bottom of the funnel. But then you have like this TAM mapping. You want to understand all of your orbit. How do I engage with awareness, MQLs, with, you know, closed loss re-engagement, stuff like that. And Swan has like this basically system of record for that. But I think it could be both, basically.

Got you. In terms of that, Swan is only as good as the context that it has access to. What does your context stack look like from your CRM to just everything else, everything else in a GitHub repo or GBrain? What are you doing on the backend there? What do you recommend some 10-person company on the call?

Yeah.

Do to build up their stack, their, their context layer.

So I love that. And I think, I think, guys, if you're listening, like, this is the, the most important question in this session. And I would argue the most important question in GTM today. If, if you, if you build, so like the, the, the process looks like that from like the AI GTM transformation perspective. Like day 0 is like we have Claude or ChatGPT subscription and we're talking to it. We're cool. Then, you know, step 2 after that is we connected my ChatGPT in Claude to my CRM or, like, to a lot of tools, and I can talk to it and ask it questions about my data. Okay? Step 3 is I started building agents that can really do async work. Okay? And then I'm kinda like, these are, like, specialized small agents that are doing very little work, basically. And I'm kinda like repeating myself over and over again, okay? Trying to build something for research and then maybe something for personalization. And it's like, I'm doing a lot of the work again and again and again. That's like step 3. Step 4 is you have things on your local storage. You used Claude Code or something. So you have these files on your computer where every time you want to do some agentic work, it can read that file, that ICP file, okay? That's step 4. After that, what you do is you try to go to the cloud. You say, I can't really work from my computer on a file, so I'll use GitHub. What happens when you use GitHub, only a few people can really use it. It's not really something that a company could actually use. Okay? And I think that's where it's interesting because here the story actually kind of like unfolds differently. If you're just one builder, you're building it for yourself, then having a lot of the context, and I'm going to explain what does it mean context in a GTM environment, but just having a lot of the context in GitHub might be enough. If you want to collaborate as a team, then that's a shit show, basically. And then what you see, the step after that for more mature companies, which is interesting, they go back to Notion. They actually have Notion as their repository for all their documentation about how you run your GTM because that's like more accessible to a lot of the folks in the GTM. You want the VP marketing to contribute to the messaging. You want the CRO to explain how do we do band with things like that. So you need something more accessible. So you kind of go back to like this Notion thing or like Google Drive or stuff like that. The last step in that transformation is that where we at is that we use Swan for that. And Swan is a file system, a context But it's a file system like Notion in a way that is designed natively for agents and humans to work on it together, basically. And I'm happy to share more about how does it look like in Swan and what do we have there inside. But that's the end goal that you wanna get as this unified shared layer that everybody can contribute to, agents, builders, and non-technical folks as well, because they have usually the most important context that you want.

Okay, a lot in there. I love this. So why does GitHub turn into a shit show? And then when companies sort of, in a sense, step down to something more consumer like Notion, what do they gain? What do they lose? And then, yeah, I would love to see what this looks like because I've worked through both of those. Solutions. I have my own point of view on both of those solutions for context. But I'd love to see then what does this look like in Swan? Because what I'm hearing from you is it's not just, oh, the chat is the only interface. There's actually a file system behind it I can access and that becomes the replacement for my GitHub repo.

Yeah.

I'd love to see that.

Yeah, yeah. So it's very simple. GitHub is good for agents, bad for humans. Notion is good for humans, bad for agents. Okay. A good context layer allows humans and agents to understand what are they reading, to understand what are they changing, and to be able to understand how to access a specific folder and what does it entail, etc. So humans like Notion or Google Drive type interface. It's intuitive for them, but agents are interacting with Notion's API. There's a lot of limitations for it and they hate it, right? GitHub, if you're not a developer, you're just like, why should I, like, why should I learn this, you know, versioning tool from the '90s if I just want to explain the GTM engineer my messaging? Like, how do we change our ICP? Like, why should I? Why should I understand that? Right? So basically, that's the philosophy here, which is important. And I think that's huge. Everybody should get that. Good context is digestible by both humans and agents. Okay, guys, if it's not readable and understandable by both parties, it sucks. Okay? So at Swan, basically, It's very simple. It's not like there is something complex here. So you have, we made it a little bit simpler. There's like skills and then you have the workspace itself, but skills is like, you know, much more easier, you know, to look at basically. So let's look for something that is, we have like hundreds of skills already. So it's like, it's big. So I can, let's take for example, your handle demo request. How do we handle a demo request? So this is like very friendly, basically. There's like the version history, same thing. I can read it like, yeah, what do I need to do? The step 1, step 2, step 3, it guides me. This is like, okay, I need to update the CRM when someone submits a demo. So I need to use this. How do we update the CRM skill? Right? So it's like, yeah, it's friendly. I can jump into that skill and take a look at it. I can chat with Swan about these skills. It already has the context that I'm looking at it basically. So I can chat about it, ask it questions. I can make changes, et cetera. It's very accessible. Then of course, on top of it, you have like your workspace basically. You have your personal file system, your organizational file system. It's not something that is radically different. It's just, it's easy for humans. To read and collaborate and to understand and chat with an agent to work on it. And it's ready for agents to interact with it because it was designed for agents to consume and operate in it, basically. I can explain about more deeper functionality that we have here in the brain. But even before a lot of cool stuff that we add on top of it, just the ability to have something that— a good interface for humans and a good interface for agents. in a cloud environment just simplifies a lot of stuff.

If I've got something I'm working on, I want to start taking some notes, I got some ideas, I might just go into Swan, start talking to it, and it will create a file in my Swan file system that I can access later?

You can even do it. You can chat with Claude and tell Claude. We have an MCP. You can just tell Claude to push that. Yeah, I'm working on this ICP doc. Instead of you finished it, you tell Claude push it to our context.

Okay, so Claude's pushing it there instead of my GitHub repo.

Exactly, so that someone could actually take a look at it on the other side and be able to interact with it better. That's basically the difference. Then on top of it, what I will add is the biggest difference here is that this is a file system with opinions, okay? Um, basically it has a lot of opinions. So, um, Swan knows how to write a good scoring scale. No, Swan knows how to handle a demo request. So basically when you start defining your process of how to handle demo requests, Swan can push back on stuff, can tell you, did you think about that? Did you think about that? How do we do that? Etc. You should— Swan knows that, yeah, it's better to actually break it down, the logic. Don't put The CRM update logic in this skill. You want to divide that because it creates a lot of complexities after on. You just want to make— how do we update the CRM in one place? How do we handle demo requests in one place? So there's a lot of this taste component of how to build a good context layer that is weaved into the— into Swan, basically. And that's really the most competitive edge that you get when you work with basically A GTM-specific tool. That's it.

Okay. I'm, I'm, I'm, I'm realizing there's a bunch of questions in the, in the chat, some of which we did get to, some of which we didn't. Let me rapid-fire throw, throw some of these at you. What CRM is Swan actually running on? Ivan wanted to know.

Yeah. So we're using HubSpot as a CRM. I would say that the more we grow, we, um, we, we needed less and less. And we're— I didn't, I didn't go to HubSpot to the interface in like, uh, 6 months.

I think this may be not a rapid-fire one, but I don't know, see, see which we can do in 20 seconds with it. But like, uh, from Sedan, uh, would you be able to walk us through some real-world examples of how a go-to-market engineer can run an entire go-to-market function end to end?

We've been talking around that, but Yeah, uh, so I think that again it starts with, you know, the, the process itself. You just— there's no, uh, ways around it. If you want to, you know, run outbound, then you need to have an idea of what does it mean to create a process for your type of outbound. If your buyers are on LinkedIn, then you need a LinkedIn automation. Then you need maybe a tool that will run LinkedIn automation for you. Swan does that. By the way, but you still need that. If it's on email, maybe you need like a good deliverability infrastructure, et cetera. So it really depends. You need to— and I will say maybe a good tip here, guys. There are like 3 layers you need to always think in. 1, map the process. 2, map the systems. 3, what are the best practices, like the dos and don'ts, basically? If you always approach from these 3 layers and you optimize for iteration, not for perfection, you should get to good results.

Basically. I like it. Mehdi asks, this is a good one, since your product and underlying GTM process choices are opinionated, what kind of business is Swan a good fit for? I guess he's asking like, well, you know, your opinions are best suited for what kinds of companies? And he lists out enterprise, medium, ABM, small, big team.

Yeah, I think that we like the large complex enterprises. We We don't really understand that environment enough. And I think that our opinions are not maybe throwing Swan in like an Uber or something, or like a Deloitte or something, then that will be maybe like out of touch, maybe like, how are you expecting to do that? Things are so complex. I think that the opinions are designed for if you're an AI-native small company, or if you are running like a Series A to Series C company, basically.

And then Aaron asks, he says, today's building something with Claude plus Apollo plus HubSpot and curious something like Swan would be more effective and efficient. You kind of touched on that a little bit, but you're still gonna use Claude, right? And you're still gonna use HubSpot and you're still gonna use something like Apollo or maybe you're not. Maybe Swan's, you know, got that piece.

Yeah. Yeah. So Swan replaces like, you know, the Clay, the Apollos, the Zoom Infos, the, you know, sales engagement tools. all of that, basically. Claude is good for, you know, as a thought partner, you eventually use it for a lot of stuff. There's like the habit of going to Claude. So it's not like you just want to replace Claude in your organization. I'm sure you're using it maybe to do a lot of other stuff outside of your GTM, basically. So it's not really about replacing your CRM or replacing the LLM, basically. It's more about having the GTM infrastructure that you can build on top of it, agentic processes. Context, orchestration, and then like apps, basically, you get all of that. Nice.

Okay. And then Joaquín asks, where is the Swan data coming from?

Yeah. So we, similar to Clay and, you know, other folks in the GTM infrastructure category, there's like a lot of data enrichment providers that we work with. So like dozens of dozens, basically. So there's like a marketplace. We buy the data first from them, and then we have a credit system that you can use it, like pay as you go. I would say the difference between us and Kalei is that we're not a data company, we're an AI company. So we try to get the margins to almost zero on the data because we, that's not our business. We're just, we know that this is like our wedge. So we try to, you know, lower the cost and we're rolling out a new pricing change that will come up in the next month that will make data extremely cheap.

Okay.

All right.

And then you are giving— you're going to be giving students who go to Market Engineering School access to Swan for a few months. And people who have used it, who have built systems on it, what do you think that— what's going to be really important that people can— what do you want people to be able to do after they've gone through that, after they've accessed the system? What do you expect that is going to be different about their go-to-market motion?

Yeah, I think that the goal is to build like a compounding agentic engine. What does that mean? If you're building pipeline generation workflows, that's where you orient towards, then there's a system that unifies all of your pipeline generation workflows and it compounds. There's a touch, someone visited your website, but then they did another thing. You can see both of them. You can start building processes for what happens when both of these stuff happens. You start operating at like a different level where you can do much more things, you can be much more nuanced, and everything is connected basically. So I think that's the difference. It's about the compounding impact of having a shared layer that orchestrates everything. And you can build a pipeline engine, an inbound engine, an ABM engine, a deal acceleration engine, an expansion engine. But the bottom line is that these engines are cohesive and they are Scalable and they compound.

I got it. Yeah, because I asked in the chat here, like, what are people using for that context layer? And like me, other people are using, you know, Claude and plus, you know, GitHub and stringing together a bunch of things. But the expectation is that they would have everything GTM-related all connected, all-knowing, all-powerful, scary as it is. But then That is the unlock to be able to give the AI more, more of these processes that can be done through computers and don't require a human to make sure that no big bad mistakes happen.

Exactly. I gotta also bounce, Jared. I have another session a couple of minutes from now.

All right, awesome. Thank you. This is great. Thanks, Amos. Thanks everybody for joining, and we'll post this recording. Take care, everybody.

Thank you so much, guys.

Bye-bye.