GTME School Webinar - Laurens Nys on n8n

Well, maybe we'll kick things off and this is being recorded and we'll post a recording to our YouTube channel after. So welcome everybody. Uh, if you can see everybody on mute. Yeah, hopefully. Let's see. Let's make sure everybody's on mute first. Okay. Today we're going to introduce Go-To-Market Engineer School briefly and then Laurence Niss is going to take over. He's going to lay down some foundational knowledge here, some, some, some theory about building systems and a little preview of the module that he's going to be leading in Go-To-Market Engineer School. We are registering people through till next Monday, February 9th, and then we'll stop taking registrations and the class starts a week later. I'm Jared Waxman. I live in Silicon Valley. I've helped quite a number of startups, including Auth0. Recently, I've been working in the VC space a little bit. Lifelong learner. Built this course with Matteo, and we're kind of basing it on things like Reforge and Pavilion courses and Winning by Design and other, you know, excellent programs you guys have probably participated in. Matteo, you want to say a few words?

Sure.

Thanks, Jared. Hi everyone, Matteo here. Been in SaaS for about 10, 11 years now, which is crazy to think about it. And yeah, mostly in pre-seed to Series B. The last few years I've been running my own consulting practice, work with the likes of Common Room, Toast, Ahrefs, Strapi, and a bunch of others. It's been super fun to build GTM Engineer School with Jared. It's amazing that we got to Cohort 3. And so massive shout out to all the students and our partners like Laurence, who also like helped us making this a reality. And yeah, super pumped for Cohort 3 and keen to get your questions at the end of this. I'll be moderating some Q&A. So I'll, you can ask all your questions later on.

So, you know, Go-To-Market Engineer School is kind of an answer to the question of like, hey, this tech is moving so rapidly, uh, how can I keep up and not just know kind of what's going on but how to actually, um, produce the outcomes that, um, that's promised? How do I actually be hands-on? And so that's kind of why we built this. Um, you're going to be doing a couple of dozen sort of mini lessons, one module a week. And I'm going to go through here within these slides just a little bit about the course schedule as we have it today. Things might change a little bit, but we're going to start out on February 16th with a short primer on go-to-market engineering and kind of an overview of the course schedule and things like that. And then And then on February 18th, Yash, the sort of OG go-to-market engineer from, from Clay, is going to spend a couple hours on our Zoom talking about research enrichment and scoring and showing everybody what the latest tools and techniques are, and then kind of going through a little bit of the asynchronous homework exercises that all the students are going to do. And then Throughout the week, we'll have live help sessions with, with TAs. You can hop in there and get unstuck. And then that sort of format continues each week. The next week, it's going to be around messaging and kind of setting up your, your PMM brain, basically, with, with Zach from Octave. And then, and then Lorenz here is going to, is going to lay down some knowledge around how to think about building automation systems, show us how he's doing it, and then give us some exercises to do throughout the week again with, with some live help sessions. And that's going to be probably concentrated on N8N, which is something that, you know, a lot of us are, are eager to learn or trying to learn. And then Philip from Zapier, is actually gonna switch gears for us a little bit, and we're gonna go through some inbound automation flows. And then finally, we're gonna wrap up with content AEO and LMA optimization with Owen from AirOps. And then the final few weeks is gonna be optional, but for students, if they would like to do a capstone project, you're gonna get support throughout that and then some feedback at the end. If you make it through all this, you get a certificate and a good community. This is again the weekly schedule. We've got a 2-hour lecture on Wednesdays from 8:00 to 10:00 Pacific. The recording will be available within a day if you have to miss it, and then we've got these live debugging sessions. Like I said, this is obviously cross-tool expertise is what you're going to be learning. You're going to be very hands-on. It's led by experts in the industry. You're going to get about 4,000 $1,000 worth of free platform credits and bonus features from some of the partners that we have here. And as I mentioned, the capstone project and the Slack community that you're going to be able to participate in. So that's, so that's the course. Again, we got a week left to sign up. You can get your tickets at go-to-market-engineers-school.com. This is sort of the schedule. We've got one more webinar with Owen next week, and that's it. That's my intro. And so now I'm going to stop my screen share. Share, uh, and hand it over to Lawrence. But before I let him, uh, take the reins, I just want to say he's the, uh, the founder and GTM engineer at GTM Sigma, where he's— where he builds and ships go-to-market systems for SaaS companies. Focus on automation, on AI signals, on data flows, and live reporting, helping to move pipeline and unlock revenue. He's worked with plenty of Series B companies who's replaced a lot of manual work with this production tooling that he's going to go through. With that, Laurence, take it away.

Awesome. Let me share my screen. Perfect. There we go. Yeah, I mean, you already gave an intro, but yeah, I'm Laurens, founder of GTM Sigma, if you couldn't already tell. Yeah, so I've been doing GTM engineering for, I guess, 3 years now, about 3 years. I started off as mainly in Clay, as a lot of these journeys kind of started off as they also kind of coined the term GTM engineer. And then over the past few years, just kept evolving. And I'm going to talk both about n8n as a tool and then also a little bit about like my opinion on what I think GTM engineering is because there's a, maybe not conflicting, but there's a lot of people out there giving different opinions on what they think GTM engineering is, as well as sort of how to think about automating, how to think about GTM engineering and how to think about, you know, what problems to solve and how to solve them. And then layering in n8n as a as a way to solve them. So yeah, I mean, that's the agenda. What is a GTM engineer? How to think kind of the, not mindset, we're not gonna talk about like growth mindset and all that stuff, but how to think like a GTM engineer and then, and then apply to it. So first of all, like I like to kind of dissect words into parts and kind of figure out where they came from to figure out what a word actually means. To me, go-to-market engineer is, you know, obviously separated in go-to-market and engineer, Go-to-market is obviously like most of you will know what go-to-market is, but it's everything you do to like get customers, keep them and make them worth more, which I feel like in the go-to-market engineering space, it gets taken to just outbound a lot of times. To me, go-to-market engineering really means doing everything from, you know, getting customers, helping sales to get customers, It can be anything from selecting accounts to doing outbound to doing prep to doing account mapping, buyer persona mapping, etc., but also to keep customers. Like, for example, you have the, the flow where you start tracking champions. If a champion leaves, you re-engage, etc., to make them worth more as well. Expansion, upsell opportunities, cross-sell opportunities, etc. And then engineering to me just really means you're building systems. You're not ideally not doing anything manual, but you're building out the systems, the workflows, the data layer that enables marketing, sales, and support to— in essence, I kind of view it as adding leverage to those people and to those roles. And one of those we use to do that is, is an 8n, but it's by no means the only tool to get the job done, let's say. So it's kind of like how I think about what a GTM engineer is. Now, how to operate like one. There's kind of, there's a few core ideas I think about when I think about go-to-market engineering. For me, the first core idea is that go-to-market is a system and it's something to engineer. And like every system, you have your inputs, which is a volume. And it can be in the case of inbound, it's just leads coming in through forms. In the case of outbound, that's the accounts you select, the accounts you can go go after or your total addressable market, your list you're building, Clay, for example. There's a certain process you go through and each process then, you know, goes through, there's a time delay between each process and there's a conversion or a drop-off. And at the end of the day, you have an output in go-to-market that's usually in revenue numbers. And ideally you have a feedback loop. Very often a feedback loop just means there's a dashboard In AI, that usually means the AI learns and gets better. Let me see to make sure I didn't forget anything. Yeah, I think that covers it. And then you can kind of get the, the system view kind of works both on a high level, as in your go-to-market inputs leads or inputs a list and then outputs revenue, but it also works on each step in between there. I don't know, for example, the cold calls, the cold emails, etc. Every campaign you run has steps in there and each step starts with volume, goes through a time delay, goes through conversion and has a certain output, which ties in really well to the theory of constraints. As a go-to-market engineer, there's so many tools, which means you can literally go out and kind of try to solve anything. And if you work with companies or you work inside a company and you start starts talking about go-to-market engineering, start talking about AI, you get a lot of people that are like, oh, can we do this thing or can we do this thing? Or, you know, I saw this thing on YouTube or TikTok or whatever. Can we implement it here? The way I kind of think about it is, well, first of all, yeah, you can't do everything all at once. So you have to prioritize. And that's why I kind of view go-to-market as the system with steps, with conversion, etc. And the first kind of goal is to figure out where a constraint is. The easiest or like the most straightforward example of this is let's say you have your SDRs doing outbound in the first step and you have an account executive taking meetings in a later stage. If your account executive can take, I don't know, 10 meetings a day and your SDR is currently providing 20, then you might get your SDR to perform like 40 meetings or even like 50 meetings, but your revenue, your outputs will never exceed the constraint of the 10 meetings a day your account executive can currently take on. Hope that makes sense. So initially, usually when we also work with clients, the first thing we try to do is kind of figure out in this system, let's go to market, do we currently see any constraints? Because if you do, we're going to solve that current constraint before we even look at anything else or before we even start looking at YouTube for advice on what to build, etc. So that's usually like the first step to me in terms of go-to-market is figuring out is there a constraint? And if there's no constraint in the system, the constraint usually is can we just do more? Like how can we figure out to just get more input through the system until we do have a constraint somewhere down the line? And then obviously in that case, solve at point of constraints. And then the next part that kind of ties in is once you find the constraints, you have like, in my opinion, 3 main levers you can pull, let's say. The first lever is more, which I tend to default to as much as possible because it's usually way easier to just figure out how to do more versus how to do it better or how to do something new. And more can take on multiple like goals. It's usually also a proxy for speed, if that makes sense. So for example, we have outbounds. One question you can ask is like, how can we just get more companies we can do outreach to? Another one is looking at, I don't know, the SDR is doing, I don't know, he's doing research on companies before he does outbounds, is to figure out how can we just skip the research and just get whatever research he's doing let a workflow, let AI do the research and then get the outputs through to the AI. So to the SDR, so he doesn't have to do research, which then gets him to do— if he with research can do research, can cold call 10 accounts and without research can go to 20, then we basically just added more volume to the top of the funnel. And then from there it's like Once more is maxed out, then you go to, okay, how can we do this better? Better just basically means like, how can we increase the conversion at this step? Or how can we make this step faster? And it usually comes down to, I mean, depending on the motion and what your go-to-market looks like, comes down to like, how can we make this targeting better? How can we make the copywriting of these emails better? How can we make these ads better? How can we make the targeting of these ads better? But it's, you can kind of hear me say it, it's just about how can we do X better so that the conversion goes up. And then from there, like once you maxed out more, as in you can't possibly get more in, it's just not possible, you can't possibly do it better, which, you know, I would highly doubt it. Like your copy can probably always be a little bit better. Then you start looking at, okay, how can we do something that's like completely new, like a paradigm shift. This is the one I stay away from the most because it means you'll have to retrain people on processes and they'll have to adapt to a new way of working, which, you know, good GTM engineers, you know, I kind of became this because I like systems. I like code. It's very— AI is less predictable, but code workflows, they tend to be very predictable. Switching out a complete workflow and, you know, adding a motion, for example, it's training people and, you know, it tends to be a little less predictable and there's usually a drop-off in performance before you see it increase again. So that's kind of how I think about operating as a GTM engineer. The recap is decently simple. It's like, one, it's a system, so start viewing it as a system. And then from there, kind of figure out what's the constraint in this system. Like, if I can, if I were to double this system, like, what would break and where would it break and how would it break and how can I fix it? And then just figure out how can I do more, how can I do it better, or how can I just throw away the playbook, do something completely new that will ideally increase either like the speed of the con— or the conversion of this. And then from there we kind of move through to N8N. I don't see the chat, by the way, so I'm not sure. I'm assuming there's no questions. I'm not sure.

No questions yet.

Awesome, perfect. If there are, by the way, just drop it and I'll guess Jared or Matteo will just shout it. Okay, so next is What is NaDan? NaDan, the easiest way to think about it is if you've ever drawn a flowchart, NaDan is just basically that, but instead of just a flowchart on paper, you can build it out as code. So like once you open it up, you'll basically just see a canvas and you can drop notes on there and each note is just a process that does something, which is very similar to Clay. Clay's In essence, it's a workflow, as in you have your table and each row is a process it goes through, and then it just outputs the whatever data comes out in the cell itself. And it then is a little different in that the output is a little harder to see, as in it goes through the workflow and you know, on the one side, it allows you to kind of build out more complex streams of data, if that makes sense. So you can add if nodes, you can start looping data, you can use AI agents that talk to each other, etc. And then I do see a chat now, by the way, so sorry if I get a little distracted sometimes. I'll share a link after, by the way. So I mean, that's the core of what N8n is. And then why I use N8n, so, because there's a bunch of tools you can use, right? You can use Cray, which we sometimes still use as well. Sapient and N8n might be closer to each other, but I think N8n is at a decent level of abstraction if you look at it. And what I mean by that is, in essence, all you're doing is writing code, right? That's every automation tool is just code in the backend and then just simplified so you can use it either like faster or just better. Even code is simplified zeros and ones. I think N8N sits at a nice level which allows you to build a lot of more complicated things, like for example the loops, etc., but isn't too high to where it's like just so complicated that you're like what the hell is this? Like, a trigger of death. If, like, I see, see that tool pop up on LinkedIn as well. If you've never seen code, that's very hard to get into. I mean, you can typecode it, but then if something breaks, it's going to be very, very hard to fix it. And it is very hard, very easy to debug. It's very visual. If there's an error, it shows up. You can check the error, and it's, it's literally just like a flowchart. And I'll show some flows after as well, but it The second thing is AI capability-wise. I think one of the reasons N8N really, really blew up is they jumped really early and really well on getting AI into their platform and into their workflows, which means like AI— let's draw the parallel to ChatGPT, for example. If you're talking to ChatGPT, there's like a lot happening on the back end. For example, it's, I don't know, you ask it about a company, so it goes out, looks at the website, reads the website, comes back to you with information about the company, and it then allows you to add in those tools into your workflow. And it can be either simple tools like visiting a website, but maybe you're using something to enrich companies. You can give AI access to it via an API call so it can go out and reach companies. Anything really that you can think of, any MCP server or API, you can give access to the AI model. One thing as well is like the model flexibility. Prompting is one of the things you can do to, you know, increase the accuracy of the outputs, but it's not the only thing. One is obviously context engineering, which is Kind of the thesis of it is AI's model is very, very good, but if it doesn't have the information to answer a question or to perform a task, it will start to hallucinate. So one thing N8N, for example, allows is to connect it to a RAG database or a vector database and to do RAG, which is basically you take context, you put it inside of a vector database, which basically just means you kind of transform it into numbers the AI can read easily and it can search easily as well. Then multiple steps, loops is also very, very useful. So there's multiple ways you can set up an AI. For example, if you have an AI that uses a lot of context and hallucinates often or very often, one of the things you can do in N8N is you can kind of connect two AI systems to each other. So for example, You have a research agent that does research on a company, and then the output of the research agent goes to a second agent. And the second agent's job is just to check whether or not everything is factual, and they can loop it back to the first agent with feedback, for example. And as long as the second agent doesn't agree or thinks there's something missing, et cetera, you can just keep looping it back to the first one until it scores a 9 out of 10 or something like that. And only then it passes forward. Which is really nice to do because especially, you know, with AI, which tends to be a little less deterministic, it's really nice that you can sort of add these systems. You can also do things like run multiple agents in parallel, then compare the results between them and kind of pick the best one. Like, for example, if you're writing outbound, that's very useful to basically, you know, let it write 3 emails, each agent embodies a different angle, a different copywriter you like. And then there's a final one that judges based on the context about the company, the contact, etc. And the third one is very cheap. It's— I know they updated their pricing, but it's like $20 for the cheapest subscription, and you can even host it, in which case it's— you only pay for infrastructure. And you have some very easy options now to host it online as well. I think, I think Railway added it as well, to just a one-click host, and it's like $5 a month maybe to run it. So it's a big plus for me. This is kind of an overview of the architecture itself. So NNN usually NaDen is a workflow orchestrator. It reasons through things. It's basically like building an algorithm with steps, loops, etc., but it doesn't inherently have any data. Like when you're working in Clay, you have your table and your table has data in there. You can see it and you can send it off. When you're working in NaDen, NaDen kind of works on data you have saved somewhere. They recently launched a feature to where you can now just save it you know, in a data table, which is basically a Postgres or a database. But this is kind of to give you an idea of sort of the end state of what a system would look like. On one side you have data sources, right? Like this is your total addressable market, you interestingly and put inside the database, your intent data, your tracking, your website visits, your LinkedIn engagements, your ad accounts, etc. You push all the data to your database, to your Postgres, and from there you then build anything on top. And then there's obviously like the interactive layer, which to me is just a layer the sales reps, the SDRs, the account executives, support, marketing, etc. interact with themselves. To me, the ideal GTM engineering end state is to where there's a system that kind of lives below the surface. Nobody really touches it. Outside of the GTM engineer and everything else just gets easier. They can, you know, access it via Slack with a chatbot when they look up a company in their CRM, it's up to date and rich, there's research, there's contacts are being added based on their buyer persona, etc. The idea really is to have everything automated behind the scenes and make the job of the SDR everybody just way, way, way better. And that's in part because it's, I mean, the main reason is we kind of have an internal policy of we don't want to change out any tools. Our only requirement is there needs to be an API because the systems need to be able to talk to each other. But if they're able to talk to each other and as the artful of using a tool, I don't want to change out the tool because it's more important that the SDR or the AE loves the tool than we do, because as long as it's an API, it's workable. So this is an example of a workflow, and I'll kind of show you two examples. So this is an example in case you would run n8n as like your main go-to-market system, and you'll build out full flows inside of n8n. I'll just walk through what this does and then show you some of the, like, subnodes. So mainly what this one does is it does research on a company. It's, it's a deep research agent. So it gets triggered, it looks up the company inside of our database. If it's, if it's found, it obviously just goes to the next step. If not, it goes back to HubSpot, gets all the data from the company creates it. And again, this is, this is basically just a loop to where if we don't have the company, check all the data, add it, and now we can go because now we, you know, we, we have it in our database. We select it. If we have LinkedIn, we go on. If we don't, we first enrich with LinkedIn data and then we go on. And then all of these are basically sub-workflows. So that's something that's like very handy in any event. You can kind of build in layers. So usually we kind of build an orchestrated layer which gives us a high-level view, and then each of these is a sub-workflow you then can go into and then switch out, you know, whatever it's doing. And then some sub-workflows have other sub-workflows, etc. And this is done the final one, let's say. But it makes it very easy to simplify the view of your workflow. Open on LinkedIn, you'll often see these like crazy massive workflows, but every time I see them, I'm like, that's like no way that's easy to view and easy to debug when something goes wrong. It just has to be a pain in the ass, basically. So I tend to work in, I call them flows and tasks, as in this is the flow and then these ones are tasks within that flow, each doing something, basically. So I mean, this basically just, you know, enriches everything, gets a high-level description, gets an overview of all the products, the customers they have from case studies, any recent news, any job openings, and then financial data. Combines it all, formats it as a note. This is also triggered, by the way, by a button inside of HubSpot. So this is just update the button to be in progress, so TCR or the AE or whoever is using it has a feedback loop of, okay, it's running. And then here it's ideally never happens, but if something goes wrong, it throws an error so they can, they can see instead of waiting on the note to be created. It then adds the note, spins it logs it into our database so we know the node has been created, and then it just updates obviously the status to done. So that's an overview of when you use any of the main system. One thing you'll notice is this is the data layer, so the elephant is a Postgres. And in case you like follow a few GTM engineers, Supabase, Neon, those are examples of what a Postgres is. It's basically just, um, it's basically just a database where data lives. If you open it, it very much looks very similar to Clay, but it's just an Excel sheet, and you can just use a programming language, or you can ask Claude to, uh, to use SQL to query it. Then the second one, this is how we're many, and this one was working on like half an hour before, you know, coming on here. So this is how we're using it mainly right now. So we kind of moved to using N8n mainly to prototype because one, it's, as you can see, right, these are all green. So, you know, I did a good job basically because everything is working. But this is so easy to debug and so fast to build. The issue with, with Cloud Code is, and, and it's a, it's a minor issue by the way, we just usually tend to build first in N8n so we can very easily debug. We can very easy like go in and check like why isn't this working, why isn't this giving what we wanted to give, etc. And then once it's working, we usually let it run on N8n for a while, and then once we are convinced like this, this is it, this is providing value, this is working, um, we let Cloud Code write something, use Prefect, but you can use Triggered App, et cetera, as well. But the flows we built right now are very, very basic in a sense, as in they're very small, very contained. This, you know, gets in a signal and in this case promotes it. Like we separate out signals from being raw to signals from being, this is in an ICP and this is actually a relevant signal. So it takes in the raw one, checks is this company actually ICP or not? If so, save the ICP classification to our database. Get details on— this is a signal that checks on job postings. Update the row. This is updating the job posting itself because now we have details. Is this job post relevant for our company? If it's relevant, promote it to our other table, which is in the core signals, so the NextAI agent then just query Score Signals every day to check what signals came in yesterday that are relevant. If not, we just output not relevant. And if there's an error, we just throw an error so we know something is wrong in here or here. That's basically it. I don't think I have another slide. No, so those are all the slides. Happy to answer any questions you have. I'm a pretty open guy, so there's usually not much off limits. But yeah, that's how I think about GTM engineering, and that's how we currently use n8n and how I would use it, slash how we have used it a lot as the main system GTM engineering-wise.

Thanks so much for sharing this, Laurence. This looked Amazing. And I mean, it's, you said it like it's very easy to build this on, on Na10 and easier than to even to debug. But yeah, maybe like for folks that have been, as you said, in the grinder for like the last year. But there was an interesting question actually that I couldn't even answer. I mean, like it's really a for you. And I think it relates to also like the database piece that you referenced that's a part of the workflow. Like when clients come to you, what are the typical data intake? What is the typical data intake as in like the data that they ask you to, for you to then go away and build these motions and Iveta, if I didn't capture your question, feel free to re-ask or come off mute and also like articulate.

Yeah, so I mean, like, what do you mean exactly? Do you mean what data do we want them to have, or?

Exactly. Which data do they want, do you want them to give you? No, like, you know, like not just, I guess, you know, like the database with the lead list or account list, but what other data points, if any?

We don't have crazy requirements, to be honest. We tend to be selective on, because we work with like very similar to you, C to Series B CRMs in the closer you get to seed, aren't always as clean. But we just tend to want to have a system where, you know, leads are being processed, deals are being processed, emails are being synced to. Ideally, there's some sort of an AI note-taker that's very high up there as well. But outside of that, like, we don't have real requirements on like, hey, Because if we need it enriched, we can enrich it ourselves. We usually build out the total addressable market ourselves because, you know, I'd rather have like one too many than one too little. So a lot of the data we kind of get ourselves. What we want most from the companies we work with is like, one, we need to know like which companies are currently in process so we don't do outreach to them, we don't do anything with them. And second of all, we need to be able to capture intelligence from current data. And ideally that comes from call notes and emails or even cold call transcripts. But right now we currently, we kind of build out two main systems as in one system is sort of the context operating system or context OS to where we build out a workflow. Every call gets processed. We build out docs on what are the segments we're going after? What's the ICP? What are the personas? And base that like in Any.Then, we just paste that into workflows. So the ICP check has the, has the doc on ICPs. The is relevant has a small doc on like the, the company we're working with. But once it goes to Prefect, to Cloud Code, the agent kind of loads in dynamically the context it needs. So we just need to be able to capture that intelligence. That's like one of the main things. I don't know if that like answers your question, by the way. I think it did, at least for me.

Another question, how do you create an AI agent to do certain tasks? Do you prompt it?

I'm not 100% sure how to answer the question, but I mean, yes, we prompt it. I opened a canvas here as well too, just for like— Do you use Next.js or you build like node by node? So what was the question?

How do you create an AI agent to do a certain task? Like, I think like if I get the— if I can reframe the question is like, do you actually create it node by node? Or do you use also like natural language to, or specific prompts to, you know, create the whole, to stand up the whole workflow?

Yeah, I usually start off like behind me on the whiteboard depending on how complex it is. If it's an easier one, like you don't need a whole drawing, but that's usually where it starts. It's just kind of drawing it out of like, okay, this goes here and this goes here and then like, okay, but like do we have everything, etc. And then I just build it inside of n8n. We have an MCP internally that builds it out from cross-code to n8n, but I tend to still just go in manually because the speed advantage isn't crazy. But yeah, I mean, to answer it specifically on AI, The way we set it up in NNN, so you have AI as like multiple layers to it on how you can prompt it. It's like the first layer is if you talk to ChatGPT, you send it a message like, I don't know, hello, for example. ChatGPT itself or OpenAI has a second message basically. It's not really a message, but it's a system message. And then OpenAI is like system developer whatever, but it's kind of underlying your message and it basically gives the agent instructions and the system message always prompts the user message. So this can, for example, be, you are a pirate and answer as if you are one, something like that. And then once you execute it, I'm not sure what it's going to say, but hi, maybe, whatever. So usually for go-to-market purposes, the user prompt we usually use for variable data, as in the company we're doing research on, context on the company, etc., as in these are the fields that change over time. And then the system messages the sort of process it should take every time. We can go into prompting, but the I think the highest leverage things on prompting is there's this idea of meta-prompting, is to just write out the prompt and then just ask AI to tell you if this is clear or not, and then it will just answer you whether or not something is unclear, etc. The same one is to use probably XML tags. I think Anthropic was the first one to kind of share it in their in that cookbook. And then basically just looks like tasks, or in this case, role, you are a pirate, and then you just end it with a, which role again. This just somehow tends to increase accuracy. The hypothesis behind it is that the AI models are trained more on code than on natural language, so they tend to be a little more accurate when you prompt it as if it's code, because obviously this is just text. But that's, yeah, that's, that's usually how we do it, as in variable data in the user message and then the, you know, SOP or whatever it needs to do in there. And then from there, to maybe give a, give another example, this for example is Exa, which is a tool I like a lot. It's, in a sense, it's, it's its own AI. But it, just by connecting those, those two, by the way, I just gave AI a tool and now it can use Exa. And then Exa allows you to web search, company research, get code context. Not sure what it does exactly. Oh, I think that's made to, yeah, to read docs on websites, etc. But yeah, from there you can prompt it and now it can use Hexa. Hello, tell me about Clay, use Hexa. And then if you zoom out, we should be able to see it use Hexa. And there you go, like now it's using Hexa. But sure, we're also using a very cheap model now. I think it's cheap. GPT-4. So I'm not sure how good the output will be, but now we used Exa to, you know, to go on the website and figure stuff out. So that's what I like about editing as well, like adding a tool is just connecting the dots basically.

It's alive, great to see.

Yeah, reading the chat by the way. Make and n8n are very, very similar. I like n8n. I tried make before making the move to n8n. To me, n8n is way more intuitive. Like, I never got the whole bubbles in make. A workflow is arrows. I don't understand why make has bubbles, but it's maybe just me. I'm not sure how they're comparing right now. It used to be that you could do way more with this node, with the AI one, in n8n versus Make. So not sure if they've caught up in the meantime, but we kind of stuck with n8n, and since then I haven't really had any need to switch to Make or another automation platform.

And then n8n has an open source version too, right, which I don't think Make does, so that's another little distinction there. And they kind of out in front with the AI agent capability, which I think helped propel them. That's my perspective.

Yeah, yeah, the open source also make it like updates-wise, it's crazy fast because there's this whole community of just pushing updates basically. To the N8N haters, I see them too. I don't know why people are hating on N8N, I haven't heard like a great argument on why you shouldn't use anythen. The main way I tend to hear is just I like Clay and I can use Clay and therefore you shouldn't use anythen because it's over-engineering, which, you know, I don't think is very much of an argument. I don't even compare anythen to Clay. I think Clay is amazing if you need lists. But if you want to build a system and then kind of forget about it and it just runs forever, I don't think that's possible in Clay. One example of a workflow that we— is part of the reason we were kind of looking at, you know, augmenting Clay with something else is when you're selling to enterprises, you want to, you know, you don't want to do filtering on just the title of a person. You kind of want an AI to be able to kind of go through a lot of context and kind of figure out which one is the best based on the context we have about what we do, etc. And it's something that's very, very hard to do in Clay because of the, like, limits. Like, the closest thing we got to it was just export them all to a different table and then score each, but the AI isn't able to see all the context at once. Here you can just would then just be a tool where, um, you give it access to your database, and then now it can just query your database. And you can put all your contacts in here, you can give it access to a specific table, you can also restrict it so it can only read, not write, etc. But then it can go through all the contacts and just keep going until, um, until it finds the right one. And you can even make it more complex in a sense by adding a sub-agent, which is also really simple to do. Because in working with AI agents, one of the main things to solve for is to make sure the context window doesn't get overloaded, because the more tokens you have in your context window, the worse the output kind of gets. But then you can just add another AI agent, and then those two can now keep talking to each other until they have an answer or until they reach a certain score or whatever, which you weren't able to do this in Make, by the way. And this just allows you to do a lot of things that are a little more complex compared to what Clay can. And usually by the sort of first iteration, is Clay allows to do API calls and it then allows you to put in webhooks. So you just have your webhook and then Clay just sends data here. You put it inside your AI agents and then you just push in, push the data back to Clay. It's usually like kind of the first step I see people take whenever they run into something like, for example, the figuring out the right persona from a big company, just do everything in Clay, but then just that step, put it to here and push it back. Programming languages is JavaScript and Python. They're a bit more into JavaScript, as in Python is— was still in beta but might be out of beta right now. But Python doesn't have any libraries in there, which is, you know, not ideal. But JavaScript is pretty good. Although I do know some Python and I rarely use it inside of N8N because there's rarely any— like, if I can get a Node, I'm using a Node because it's just, to me, that's easier to debug versus code because you can see exactly where it breaks down. So yeah, AI tends to write any of them for some reason with a bunch of code nodes, but you never really need them. Yeah, the class will— right now I'm kind of showing off by showing the complex things, but we'll definitely go basic first.

Laurence, do you want to talk a little bit about some of the exercises, some of the little mini projects you're going to have students do in the module?

Yeah, yeah. I'm not sure if I still have them open, so I'm gonna have to look for them. But yeah, I mean, we'll start off basic, right? Like, still reviewing if we might do something else. But what the last time we did, like, we was— we built a basic email assistance you can reach through Clay at through Gmail or Outlook, get AI to do stuff, start adding tools to it, etc. And it'll reply to your email. But the idea very much is to start simple and kind of scale up from there. I think the main issue maybe with NaDan is you start here, which is empty, there's nothing. And if you've never opened it, you're like, okay, like What the hell do I do now? But I think if you start using it, like, you'll very soon get used to it and the empty canvas will, like, be filled quite easy. Like, usually you start with this one. It's every workflow, basically you have a trigger, like something that starts it. Then you have a process, something happens, and you have an output, as in usually that's some sort of either data or some sort of an action, as in email gets sent, node gets added to HubSpot, etc. But from there, you like very quickly, you're very, in my opinion, it's very intuitive. As in, okay, we start, usually we need some data and data is in our Postgres. So let's get our data and let's, you know, select something we have in our database. And then I don't know, maybe from our database we need to loop because we want to go to everything in there, like every row. And then for every row, we need to enrich it, so we do an API request to, I don't know, maybe to Clay, maybe to Explorium or Prospero or whatever. And then once that's done, we save it to Postgres, so we insert or update, and we keep doing that. And now you basically have a have a flow that gets data from a database and reaches it, and then obviously you need to select the right tables, etc. But it's, it's very easy to like start building. It's, it probably looks more complicated than it is. Yeah. Everything can be learned exactly.

Yeah, I mean, like, from my personal experience, I personally didn't know what Cloud Code was like 3 weeks ago. And now I do 99% of my work inside of it. I think it's, you know, like the meta skill here that everyone is trying to learn in this market moving at breakneck speed is how do you reskill or upskill continuously? And we were chatting with Jared, with another one of our instructors, Yash, yesterday at our podcast, and this topic came up. And I think like this is really something that everyone should be investing in because it's not packed to any tool, it's not packed to any trend, and it'll just serve you not just in business at work, but also in other phases of life. But, you know, again, that also can be learned. And I think like just by throwing yourself into new UIs, like any attempts, no matter how complex they are, you can prove it to yourself.

Yeah, yeah. I think any of them is like, if you take GTM engineering as a space, I think it started off, I mean, GTM engineering, right? There was a whole history, let's say, before it. But GTM engineering really started off with Clay and took off with Clay. And I think from there it seems to be moving to like more and more complexity in a sense. But it's weird because it's more complex, but then also you're using Cloud Code or something like an AI, etc. So the ability to make stuff is getting easier and easier and easier. I think the nice thing about learning something like N8n is it's very visual and it gives you a visual representation of what a system looks like, like with different steps, etc. Because I mean, Clay does it as well. Like you have your columns and you're moving through each column. I think then the next sort of layer is N8n where, okay, now you can also loop and you can split stuff out and you can have like sub-workflows, etc. So this is a little bit complexity to it, but then like when Cloud Code goes mainstream, you have this mental model of, okay, I know this is a flow, I know it needs to go there, and we probably need to loop in here because like we need to do this for every row, and from there we need to do this, etc. So I think it is like a lot of it is how do you think about One, go-to-market. From there, kind of go-to-market processes, like what does a process in go-to-market look like? Um, and then from there it's okay, like how does this data move? Like what happens to data going from A to B? Um, I think N8N is great because it's visual again. Um, but yeah, I think tools look more complicated than they are. 'Cause at the end of the day, all you're really doing with most of these tools is just you have data and you do API calls. And an API call is just basically you asking another software, hey, I have this company, what do you know about this company? Return that data to me. And then, okay, now I have this data. So it looks more complicated, but like once you start like seeing all this is doing is go to database, get it, and then put it in here. And then for every one of those, get more data and return me the data you have. Like, hey, other database, get me data. Next, okay, hey, I want to put this inside of the database again, and then it just continues. So it's way simpler than it looks.

All right, it looks like we're nearing the end of our time. Thank you everyone for sticking with this, asking questions. Lawrence, this is amazing, and I'm getting even more excited about jumping into the exercises in the module that you'll be teaching in a few weeks. So thank you, and if you guys have any questions, reach out to any one of us.

Thanks so much, everyone. Thanks so much, Laurence.

Great. Thanks. Look forward to it.

Take care, everyone.

Bye-bye.