E10: "Systems to Get, Keep, or Make Customers Worth More" | Laurens Nys

Laurens Nys, founder of GTM Sigma, explains GTM engineering as building systems to get, keep, or make customers worth more. The typical stack uses a database, an automation layer like N8N, data enrichment tools, and a CRM. He walks through a real case where a company used planning algorithms and scoring to map their maturity.
Chapters
Foreign. Hey, GTM builders Jared and Mateo here and you're tuning in to the GTM Engineer School podcast. And in just 30 minutes we break down the mindsets, the workflows, and the tools behind today's top GTM engineers. Today we're hanging out with Lawrence Ness, founder of GTM Sigma and certified N8N junkie known for building AI led GTM systems. Lorenz was the guy who called out BS definitions of GTM engineering and laid out a real job description. The community still quotes his post on dynamic signal based TAM lists are practically required reading for anyone still blasting static spreadsheets. He just rebranded from solo consultant to GTM Sigma Studio and is already hiring the next GTM engineer. Expect hot takes on why Cold Calling is poised for a comeback and live demos of N8N automations that glue the whole stack together. So Laurens, great to have you on the pod today.
Yeah man, glad to be here. Thanks for a nice intro.
Yeah, we'd love to hear. What is GTM engineering? In your own words? How do you define it?
I like to think first principles. So to me a GTM engineer is just someone that builds systems to get, keep or make customers worth more. It's like first principle wise. That's it for me. And it's like obviously a combination of just what go to market is right, like getting, keeping and making customers worth more and like everything seen through the lens of building systems like engineering, basically.
Do you remember life before GTM Engineering?
Yeah. Very dark past. Yeah. I mean, definitely. It's like, what been, I don't know, one to two years since? It's like, I mean it, it. I'm sure it existed before, but the name GTM Engineering, I'm, I'm pretty sure Clay started maybe two years ago. I'm not sure.
And what in your world, what, what were the differences then? What couldn't you do then that you could do now? Or what did teams look like then? How do teams look like now?
Yeah, I think it's a few like different points that like came together and then kind of created GTM engineering. I think on the one hand you kind of had like Jacko calls it the, the growth at all cost era, where money was basically abundant and funding was like more focused on growth than anything. Not really looking at profit margin or profitability. Nobody cares. It's just grow. Right. So I think like coronavirus, et cetera, like causing growth at all costs to like kind of slow down to where like investors kind of looked at. Okay, but like, are you profitable? Is this sustainable, I think that caused companies to think about efficiency, which I think GTM engineering is a huge play on go to market efficiency and then same with AI entering the scene. I mean AI is an interesting one. I don't think you need AI necessarily and a lot of workflows that use AI don't necessarily have to use AI, but I do think it definitely costs a lot of this because you can just build way cooler stuff.
Absolutely. So we're going to shift into the lightning round now, so Matteo is going to throw a few quick questions at you and just what's the top of mind? Answer that.
You've got great shoots.
All right, let's kick it off. So let's talk about CRM first. What's your top choice? HubSpot, Salesforce or Atio or something else?
Personally, like using Edio, Clients usually use HubSpot, but I always like my sales piece as well. I'm always like, I focus on like the system that's underneath. I don't really care about CRM as long as I can interact with it. Meaning it like it has an API that's not complete yet, I'm fine. And then it's just the question of do the sales reps actually like using it? If yes, I'm not touching it.
Love it. What about your top LLM, Claude or ChatGPT?
I like ChatGPT more like OpenAI. I like it more especially like the memory and stuff. But then the models I like Claude like especially the four like Opus, but then it's way too expensive. So tend to use OpenAI. If OpenAI isn't doing the job or finishing the job, I go to cloth anthropics models.
And what's your top enrichment tool?
I would say Bright Data.
Tell us more. Why?
Why Bright Data? I would either say Rapid API or Bright Data. Repi love it. Just a little bit more expensive than Bright Data. But Bright data basically has. It's basically a scraper with a bunch of API points for different sources and they have an API for most sources like LinkedIn, Reddit, G2, I don't know, top of my head, but like a bunch of them. And you can create like they have their own proxies and web and broker they call it if you need to create anything because it's 3D fucking cheap as well. I tend to go to Bright data first when I need to. I mean first it's just a basic scraper. If basic scraper doesn't work, I'm going to write data. If write data doesn't have it, I'm going to rep API. And if REPI also doesn't have it, then I'm looking for, like, some sort of an API I need to pay way more money for.
Love it. And what's your overall top GTM engineering tool?
Nn, But I don't think that's a surprise.
That's an easy one. And what's on the other hand, the most underrated GTM engineering tool that more people should know more about?
Ooh, underrated. This is an interesting one. I might say N8N again, but like, and two weeks or four weeks ago, that might have been pretty accurate, but today I'm not sure if it's still underrated. I don't know, but bright data might fit in there as well because I don't think a lot of people use it.
Yeah, I actually, like, I hadn't known of it. So, like, that's definitely one. One more person that knows about it now. And I love the fact that you just talked about, you just said that four weeks ago, any 10 was not that popular, but now, you know, it might be. You know, it just tells how fast again, like the, the space we're living in goes. Fasten your seatbelt, folks. All right, now let's switch to system design. And so when you approach your clients or like new scopes and have to build these GTM engineering motions, what are the building blocks of your stack and how do you kind of like, design it, Design these motions from scratch?
I mean, I tend to think about it as like, you have like a few different buckets, like the main system that's like always there is one, you have a database where obviously all the data lives. And then two, you have kind of the intelligence layer or kind of the brain of the operation. And for me, that's N8N coupled to either workflows or some sort of an AI system. And then depending on what needs building, that's there, right? And then it's on the one side, it's all the data. All the API calls, like kind of the raw data you want to get. It's like the, the web data, the web API, the bright data API, et cetera. I mean, it depends on the kind of the problem you're trying to solve. Like, in a broader sense, the way I tend to look at it is you have your go to market, and every stage in the customer journey just says you have a conversion, you have volume, and there's a time delay in between every step. And just kind of figuring out, okay, what's the point of constraint. And then based on where you are in the kind of go to market or customer journey, your system kind of looks different. What's always going to stay the same is you have your database, there's data coming in. Usually it's from some sort of a scraper, some sort of a tool or even like internal data, right? Like meeting notes, transcripts, whatever emails you sent, etc. They all go there. You have the intelligence layer and then you have some sort of an interaction layer meaning an email that gets sent out, a CRM note that gets added, a list of companies in your CRM. The sort of like the architecture or at least the way I put it, love it.
And you talked about constraint. Can you double click on that and tell us what are the key tension points or trade offs that sometimes you encounter when designing these steps and why you know like are these important for people to know?
I don't want to like it's funny initially when I started GTM engineering I didn't want to be confused with lead gen agencies. Basically like did everything I could not to be a lead gen agency. But the, the funny truth is like outbound often is like it's like the saying that the top of the bottle usually is the bottleneck. So outbound is, is a very common one. Usually downstream from outbound. I mean and I usually is. Is pretty like freely used here because like might not be but usually closing rates etc. Should be fine or usually just you can usually increase outbounds more than you can increase anything downstream and have the same effect downstream with like a revenue increase. But it definitely depends. Like for inbounds for example, it's like totally different scenario. Then you really have to go look at okay like what's the drop off point. And it's a bit art and a bit science because on the one end you try to just you know, calculate mathematically if we increase this with 1 percentage point or whatever, or whatever increase we think you know, we have confidence in being able to do so. And the kind of confidence metric is, is a little bit of an art of kind of looking at the go to market conversions and then being oh this, this seems to be extremely low to all the other data points I've seen. And that's a combination of. Because comparing companies one to one is very hard. Um, so there's a combination of looking at okay like has there been a time in the past where we we did way better than we are doing right now. That's like a big sign that Might be the constraint, like something happens, why did it go down? And then the second part is just like kind of estimating how confident are we we can increase this and what would that mean down the line? And then that's the point where you want to try to solve or where you want to start building the system was a little bit of a ramble.
Not at all. Not at all. No, I totally get it and I think like was super, super insightful. So thanks so much for sharing.
So we're going to shift a little bit and talk about workflows. Love to hear if you wouldn't mind telling us about a GTM play that you're really proud of, something you actually built and ran. I'd love to hear the full arc, what sparked it, what you're aiming to solve, how you approach the step by step and kind of results you saw.
I think the one I like the most is just I tend to work with companies that are like decently vertical as like the solution they solve because and like decently vertical and they have an ACV to where it makes sense to like, you know, automate and really go in depth versus just trying to aim for scale obviously cycle balance. But I tend to like to go deeper more than I tend to like to go for scale. One workflow, like it was a company, they basically are planning API. So they, you know, gave companies that had a product that was customer facing with some sort of a planning algorithm in it. They built like the sort of brains behind the planning algorithm. And basically what we did for them is we, we mapped out all the companies selling a planning algorithm or using a planning algorithm. And then ideally it's, it's like core of their business. We mapped out all the features and I was on like an AI agent that went into documentation, went to do the change log and went to the future pages. I mean actually if you break it down, it's like the first thing it did is just went on the website, looked at, okay, how many products do they have? What's the flagship products here? Is the core of this product based on a planning algorithm, yes or no? Because if no, it's not very interesting. Then it went into, okay, this product was the exact feature set. And then specifically like look at the documentation and change log because a lot of features are marketing mumbo jumbo, which isn't interesting. We need to know what's, you know, the actual capabilities here. I mean if we just did that, we basically had a full overview of okay, so these are all companies, these are all the features and we run it through some sort of a maturity model. So at a full overview of full market of how mature are these planning algorithms for those solutions? And then the next thing we are doing is that is we're looking at okay, this is how mature they are. How does it compare to the same sort of companies targeting the same consumers? So for example like the board target board, big airlines, then we can immediately compare. And if they are maturity level two and they are maturity level three, so there is a probability they are losing deals because they're a maturity level lower than other companies starting the same one. And then we went from that to okay, when we see like pressure basically as like a gauge of pressure of them needing to start building those features. Went to look at their team and be like, okay, do they currently have the skillset to develop the features, you know, equalize the maturity model? If not, then also obviously look at are they doing anything to get those people in? And then from there we was more of a manual, wasn't an automated outbinds, but we basically gave that to the sales reps and they had like full overview of hey, this is a company, this is like how they compare to the market area and this is the features they have and then also like more targeted to. And these are the features we think they're trying to build and how our company can help get them there. So a bit of a long one, but so far that's been the one I like the most and some of.
Our listeners don't have that much experience with N8N. How complicated is this to build in a tool like that? How extensive are those workflows? How do you manage that complexity?
I mean that's a hard question to answer because I'm not sure how to put a metric on complexity. It's decently complex. I have a few ways I set it up so this is the full overview and maybe to just quickly zoom back out. So far the way I have found best organizers is kind of if you prefect it's framework within Python. I organize between flows and tasks. So task is everything and I kind of try to name it. I'm also a bit techie so I just like naming it like it's a Python function. But it also helps me because immediately I know analyze company news, company id, I know what it does and company ID is the input for it. So it's immediately I can, I immediately know basically. And then flows is, I mean literally it's the flow itself and then it's based off of like all these are kind of subflows and this is the main one I was talking about just now. So obviously, like, the first thing it does is just somebody run like the. Maybe just context, somebody in HubSpot says, hey, I want to know this company, what it does, et cetera. And it's not there yet. Run this. And then it adds a note, it pins the note, et cetera. But obviously first thing it does is it checks whether or not we already enrich the products or not. If it didn't already enrich the product, this is like the, the product enrichment one. So the first one is just an AI and just goes on a website, looks at all the pages they have, basically gets the sitemap, etc. Looks at, okay, what are the products they have and what do I think is like the flagship products? Which is decently easy to do because all you really need to ask is like, look at the Hero section, like, which product is like, mainly, like, you know, mainly presented? Then look at like, is this even a relevant product? And it's also like an NNN 101. Make sure you, like have error stuff because, like, flows tend to break from time to time and if you don't do error handling, you'll. I don't know, I've been there many times. And then you're like, why the fuck isn't this working? And you have like no clue because you don't see where it broke down. But yeah, anyway, it looks at is this relevant, yes or no. And then this one are the main ones. Whereas obviously scoring the maturity and getting all the features out of it as well. And then the gap analysis is basically, this one has a lot of context on the company and their planning API as well. And it compares both and looks at, hey, what are, what are the gaps both between them and other companies and with the products we built or we have. And it just, you know, that that fits here. So I'm not sure how to answer the. How complex is this? I like showing anything because it looks complex, but I think most of it is. I personally, I think like the main thing to get good at, I kind of see as like the technical skill as kind of your ticket of entry, as like once you know how to set everything up and you kind of know how the web works and all that stuff, now you have the ability to be creative, but the creative parts being like Clay says, the alpha. I'm going to say Sigma because I need branding, but I think that's where the gain lives. Let's say.
What is the marcation when somebody goes from kind of a beginner at N8N they can do just simple workflows to sort of an intermediate level. What does it take to get there?
I had someone ask me today, they were like, hey, I want to get good at any, then what do I do? Well, my honest answer, but it's probably not a very fun one, is just look at your go to market and then just go to NADN and start building. And if you're stuck with their documentation, I never really watched any YouTube videos on it. Their documentation is pretty good as well. I'm a strong believer in project based learning. Just dive in, start building stuff, break and then figure out why it broke.
We are too.
Awesome.
All right, fair enough. Yeah. Matteo, do you want to maybe probe a little bit deeper into these skill sets? We just sort of started to touch on them?
Yeah, absolutely. By the way, super impressive stuff on the workflow. Thanks so much for sharing that. We love when guests impromptu, just like go screen sharing mode. That tells a lot also about you know, like the hands on, you know, like operational experience. Okay, switching to skill set. Yeah. What are the things, the skills that you think are emerging with these new GTM engineering role that you know, aspiring operators must learn to stay in market.
It's a funny one as well because I'm trying to hire as well. So like for myself also trying to define what does this profile look like and who do I want to hire. But it's hard because in essence you're kind of looking for a combo that's not very common. Like on the one hand you want someone that has some sort of a go to market background or go to market knowledge. They tend to be salespeople. I'm sure there are tons of marketing people as well, but they're probably more salespeople and then the other ones you kind of want the technical aspect of not a full on coder, but they definitely need to have some sort of understanding of kind of. You know, I built databases. I. It's, it's an interesting discussion though because I feel personally like you should know the foundation of everything you're using. Like you should know SQL. You don't have to like. And there's a difference in the same way as you like learning a language, there's difference in being able to speak and then being able to read. I feel like you should be able to read everything and know all the principles about it. That's a very hard because it's like you have NN and then you have kind of system thinking I think is huge as well. Like using mental models. I have like tons of books on just mental models because I feel like it very much helps to just break down stuff in models you can reuse in later stages. I'm almost losing the thread here, but the question was what skills are emerging, right? I would say learn all the fundamentals of all the different technologies you're using. So whether that's you're building a base base and it's using SQL. SQL, you know you'll scrape data. So at least learn something about web, right? Like know how kine is made up so you can troubleshoot when you don't see the data or where you're building a workflow and scrape reasons returning what you wanted to return. And then all the other stuff is learn go to market because you already in go to market, you know what you're in. I think Winning by Design is a great one for it. Like revenue Architecture. Their book like is one that unlocked a lot for me when I like few years ago. I think that's, that's another discussion. But like with AI, I think learning how to think is such a meta skill that's going to be more and more important, especially building agents and stuff.
I'm totally with you and I think like you know like as like the SaaS market is as matured over the years and we're you know like just keeping on verticalizing or productizing modules of capabilities. Right. You know, like with email automation with data enrichment with intelligence on its own with, with LLMs. I think like humans are urged to go higher in abstraction in terms of like skill set and you know like the meta skills are becoming more and more important and I think like you touch, you make a very good point, you know, like it's not just about how to think, how to learn, you know, like, or how to observe and understand what good looks like. Because that ultimately sets the tone for the context that you give to these LLMs or for the outputs that these LLMs or workflows should, should put out. So I think like there's definitely like a gold nuggets there. And how would you advise, you know, like aspiring GTM engineers, you know, like to acquire these skills you touched upon project based learning. But I don't know if you want to add more to that or if there's anything else other than that.
Yeah, one, I think it depends like where do you start if you're already somewhat like gtmish meaning like maybe you were in sales. You, I don't know, sales manager, whatever. I, I don't know what all the CTM engineering, like, if I feel like they're getting more and more of them like almost every week. So I'm not sure right now what the like average profile looks like. Used to be sales, but I'm not sure even because like now I'm seeing data engineers as well entering the field. So no clue. But yeah, so just figure out your kind of skill sets and then you just know. Okay, so if I want to be a GTM engineer, I need to have GTM and engineer. If I'm good at gtm, figure out engineer. And figuring out GTM engineer just means, you know, get good at like, I want to say Nadan, but, but I mean I grew from clay to Nadan as well, so Nadan. I don't know, like, maybe they'll stay, maybe they won't. But get good at kind of understanding what you're building. You are building systems, you're getting data from point A to point B and then you're doing something with that data to kind of, you know, abstraction one, understand system you're building abstraction two or a level deeper. Learn the tools that allow you to do stuff. Because I've been playing around with like cloud code as well and I know some Python and Prefect and in terms of like speed of getting it done, it's like getting very, very close together where I'm almost as fast just plain old code with using some agents as I am in an 8N. So I don't know if it'll change or keep the same. But like it's getting close and then go to market. Just read the revenue architecture. I was fortunate to. I had a recruitment agency before this for go to market roles for tech companies. So I had a lot of like, you know, conversations with tech companies and I helped them with hiring for their go to market. So I was fortunate to like learn a lot that way. But if you can just, you know, try to do maybe, maybe even build free stuff and just get on calls and then just ask stupid questions. Another rant. But like asking stupid questions is also something I think is so important. I even like I had an onboarding with a client today and I did digital resets. I want to have a call because I feel like one of the things you really need to understand when working someone is like the problem they solve because the flow I just explained, like I couldn't have built that flow without understanding the problem, like wouldn't even be close. I had to really understand the problem and I don't have like a planning API background, like not at all. So basically I always have like one call with the clients where it's just me asking dumb questions about the problem they solve.
I love it.
You mentioned you started with clay. How much do you still use clay or has N8N taken over a lot of those jobs?
Yeah, I don't anymore.
So we came at it from the angle of what skills should people be acquiring. But as I was looking at your screen share of the NN workflows, which when you first brought it up didn't seem that complicated. But then somebody then you got to realize that five or six of those boxes drill down into their own sub workflows. So yeah, I would say overall high complexity. How would you think about this as a team leader, as a manager, when there are so many tools out there you can come in and build some workflow, but you may not be still working with them in a year. So how do you think about it from a, you know, if you're leading a team, how do you think about it from a maintainability perspective?
Yeah, good question. I think part of the question is asking the question of what do I think will stay the same and what do I think will change? I'm pretty bullish on Nadan staying the same for at least a year and probably more. As in the features they are releasing seem to be like both in frequency and in what they are releasing seems to be going like the right direction. They also recently got funding as well, so they seem to be doing the right thing. But Cray was doing the right thing as well a few months ago. And then I switched to any then anyway, so we never know. I think a database will always stay the same. You will always need a place to save your data. And I think it doesn't really matter then what you build on top of it. As in anything my N8N flows do gets saved to the database. Like all the AI pushes data to the database. It like takes some raw scrape or whatever, analyzes it and then all the results go into a database we can reference later, we can use later and whatever. I would think about it as what isn't going to change. And my answer would be you will need the data. I mean AI agents, like the main thing to solve for is giving it the right context and data is that context. I wouldn't really care about NADN going to change or not because to me it's just like if you still have the output, you'll still have the data. And it then also isn't that expensive with clay. It might be a different discussion because it's a little more expensive. Yeah.
I don't know if it's so much the cost of the tools I'm curious about or the sort of business logic independencies that we're now building into these tools, but there's such a wide breadth of these tools and they are right every. Every couple of months it's like, oh, now this thing is on top. Oh, so like for many years it was okay, well, you had Salesforce and you had a lot of your logic in Salesforce and you had Salesforce consultancies who would come in and they could basically work on top of something that is a known quantity and didn't change much for many years. But now, yeah, it is the wild west right now. It's changing. It's evolving so quickly. The things that you build today, are we going to be rebuilding them every six months or year as the tools evolve?
I think part of it as well is kind of because I'm hiring right now. And one of the things I've decided to do as well is I think this space is evolving at light speed. Right. So one of the things I personally do is like I'm learning about Python, et cetera, and I'm constantly learning new things and I want my employees to do the same as well. Like constantly looking out, like going out, testing new stuff, et cetera. If you have like a watch list on my bookmark blog, which is like, I don't know how many, but a bunch of tools. And every so often I just trial test and then it stays or it doesn't. Usually it doesn't, but whatever. I kind of know what's out there. If I'm hiring, I probably want someone that's like, got a very, very good understanding of the fundamentals, a very good understanding of go to market and like system thinking, et cetera. And I would kind of assume the tool is going to change, assume there's going to be a different tool and, and just want to be able to give them that space to decide, especially with the way AI is evolving. Like GPT5 has been like teased for months right now. Maybe that changes everything. Right. And I would just want my employee or my team to be able to like adapt at like, at the speed of light as well.
So the business knowledge is really paramount for you and you figure a smart person can learn the tools and can adapt as the tools change.
Yeah, it's knowing the business model, knowing the first principles and then also just understand the underlying tech. Like a web page is going to stay. I mean, I don't know, but probably. It's probably going to stay the same. It's going to be HTML and HTML as some sort of. And then there's going to be aavascript, et cetera, database or vsql, et cetera. Just kind of know those first principles and I think you'll be fine. And I think you'll be pretty fast and good at learning new tools as they come along.
Awesome. Interesting discussion. Where can our listeners connect with you? Where can they read the latest thoughts that come out of your head?
Yeah, well, I'm active on LinkedIn. Laura Snass, you can add me on there. My DM is also free. I mean, my DM is open, but I get a bunch of them. So I try to respond, but I'm not always as fast. And sometimes I have this bad habit of reading something and then like, oh, interesting. I'm going to think about this and answer later and then just completely forget answering. So feel free to DM me and then just keep bugging me until I answer.
Awesome. That's, that's, that's great. Well, I think Matteo and Lawrence. I think that is a wrap for today's deep dive with Lawrence Nass, founder of GTM Sigma and one of the most technically creative minds in the GTM engineering space. Yes, I said technically creative. From dynamic signal based TAM scoring to, let's say, AI powered workflow design in N8N, Lawrence showed us what real GTM execution looks like. And there are a lot of boxes and lines. It is pretty complicated. If you're still stuck blasting static spreadsheets or trading outbound like a guessing game, you want to rewind this episode. And if you're trying to level up your your own GTM stack, follow Lawrence. He's building the blueprint, he's sharing as he's going along, and as you've heard, nothing static. So tune in every day. So thank you, Lawrence, for sharing some of your wisdom with us. We really appreciate it.
Yeah, thanks for having me.
Thanks so much, Lawrence. That was amazing.
Awesome. Thanks.
Take care.
More from Matteo

Roll Claude out from one laptop to the whole GTM org | Sam Gong & Zach Vidibor









