E8: "The Bridge Between Data, Tools, and Strategies" | Nico Druelle

Nico Druelle explains GTM engineering as orchestrating data, tools, and strategies to generate pipeline faster. A GTM engineer consolidates work split across RevOps, marketing ops, and analytics. He walks through a real workflow: Cargo pulls signups from the warehouse, AI scores them, Octave generates personalized copy, and Instantly sends sequences, producing measurable demo bookings.
Chapters
Foreign.
What's up GTM Builders? It's Jared and Mateo and welcome to the GTM Engineer School Podcast. We're in just 30 minutes. We interview top GTM engineers to uncover principles, workflows and tools in this emerging discipline. So today we're having a lot of fun hanging out with Nico Drewell, founder of the Revenue Architects, one of the top voices, one of the earliest voices. Nico has been one of the earliest voices pushing the GTM engineer role. So Nico showed up in every who to follow list from Hypergrowth Partners and beyond. But Hypergrowth Partners named him in the rise of the GTM Engineer roundup. He built GTME motions for the likes of Attention and Descript, Preply and lots of other companies. Nico is really one of the folks that I've been looking forward to catching up with on this. In Cargo's community, Nico has defined GTM engineers as the bridge between data tools and strategies. So we're keen to double click on this definition and hear more from Nico. Before launching the Revenue Architects, he led gtmops at Melio scaling pipeline with workflow tools most teams still dream about. And Nico's doing and that's amazing. And we're going to unpack his buy versus build stack signal driven outbound and why he thinks RevOps is shifting towards full stack engineering. So, Nico, welcome to the pod.
Thank you. Jared and Matteo, super excited to be on the podcast.
So Nico, we always like to start asking people how they actually define GTM engineering in their own words. So tell us more, how do you explain this to people?
When people ask, yeah, there's been a lot of buzz and a lot of noise around that, that new job title. So. And obviously what I'm going to say is not absolute truth. It is my definition and my experience of that new role through my current lens and practice with the companies that I'm advising. So first of all, Go to Market Engineer is not a, is not an ae. I think this is a very important clarification. It is not a sailor. It's someone who assists seller to sell more and be productive, more productive in their selling process. So at a high level, the way I think about go to market engineering is a discipline of orchestrating first party data and third party data into a system of action, system of engagement to execute a given vision, a given go to market strategy. That is what go to market Engineering is at a very high level. What does that mean on a day to day is that, you know, it's someone who basically owns and pilot a roadmap of growth Experiments he's working cross functional, cross functionally across data rev ops or system and sales and marketing meter. So he's that glue that comes in, just runs experiments, you know, test things out, get some result, feedback from the market and keep on iterating. And ultimately the uniqueness of that position is that he generates pipeline. All of this is to forward, you know, geared towards one thing only, generating pipeline.
Nico, for a company that hasn't yet dipped their toe into GTM engineering, hasn't hired anybody, help them understand what, what does the before picture look like? What does the after picture look like? What are some things that AES or SDRs are doing that the GTME is going to take over for them? What are they not going to take over? And then what are things that nobody's doing today that the GTM engineer is going to start doing?
Yeah, that's a great question. So I think that there's very common actions from SDR BDR that are already being disrupted and clearly AI is doing a really good job at replacing namely you know, anything when it comes to you know, bliss building email design, you know, this very, very, very compelling, very competing case for use of AI for those different use cases. Now what I think is interesting to look at from a, you know, before after standpoint is you know, if revops was the before and go to market is the now or after. I think there is a, a bit of a consolidation of function of skills and it's happening at different level. If you look at software engineering it's the same thing. You know there's people are becoming software engineering, data analysts, product manager at the same time. And I think we're seeing the same trends where tools are more powerful. So there's a convergence of skills and you know, abilities. So I think where five years ago in traditional organization you had chorus engineering, you had rev ops, you had marketing ops. I think now a go to market engineer is kind of owning those functions and those skill sets at the same time. And if I was to give an analogy, I kind of like this analogy and I use this a lot with my client is before you had the RevOps I called myself when I started working, know being in revops, a plumber, plumber of tools. You put tools together. We can call a data guy an electrician. He brings like fuels to the, the, the go to market organization with you know, electricity and I think and you had obviously architects, system architects and I think the go to market engineer is, is, is, it's kind of all those functions together. He's at the same time, the architect, meaning he design, he, he, he works with the revenue. Think about the strategy, you know, where, what is the vision behind this, what we're trying to achieve. He designs the systems end to end so he knows which tool, which data to use. He's fetching or you know, building his own data sets or working with data teams to give him access to. And then he's you know, executing the workflows and then delivering the outcome to the sales rep. And before you had an entire function dedicated at well, let's build dedicated signal table, let's scrape some data online. That was an entire department with multiple 5, 10 people in certain organization. And now because the tools and technologies have evolved in such way that you don't even need to know how to code to execute on those things with to clear the cargo of this world, then you just significantly increase the scope and magnitude of what those people can achieve. So the scarce resource in that landscape is no longer the data, it's no longer the systems automation. The scarce resource is basically the ability to set up that system altogether as a holistic solution and iterate on it to build a defensible system to design growth. That is the real value in this.
Okay, that's really insightful. And then resulting from that, it is no surprise that companies are very quickly and with a lot of energy trying to find their GTM engineers.
It also comes at the, at the expense of. It's a harder, it's a harder position to find. And that's why it's really good that you folks out there are helping people, getting trained and understanding what's the scope because we're talking about a lot of different skill backed into a very small position. And it's like a bit of a rare burg or very rare bur to, to actually execute properly on those things.
And I love what you talked about. That has been the result of, it's being the result of a consolidation of multiple roles into one. And I would love for you to give us a bit more context as to why do you think that's happening. I have some opinions actually. In our last GTM engineer school program, Yash, the head of education at Clave, for those who don't know, he mentioned that according to him this consolidation is come from the fact of roles of different roles into the GTM engineer is coming from the fact that one person doing the job of three people or like three specialists can obviously is obviously in and on itself a massive competitive advantage because you know, one person that can do More things can go faster, is more independent, can cover more ground. What's your take on this?
Yeah, absolutely. I mean I think there's, there's two phase to it. There's obviously speed to experiment. You can go faster and get faster result. And I think Clay popularized this like, you know, velocity experimentation framework where if you have less friction, if you can self serve, if the time from ID to execution gets smaller, then you can do a lot more and then validate a lot faster what's working or not. That's one. Then you have way less friction in the user experience itself because there's less potential breaking point in the entire journey of how data is being built, who is using it. Everyone has the go to market engineer has the full entire context of what he asks for in the data, what he's doing with it and who is being exposed to it. That brings the clarity and that's also true for, you know, internal and external, meaning less friction in a buyer experience, but also less friction in the internal user experience. Meaning I'm building a solution end to end. So as a stakeholder within my company, I'm going to make sure that the solution and design I'm building is consistent because I'm designing the entire thing on my own where otherwise you have to have a PM that project manages different pieces and that brings, you know, a lot of time and potential, you know, blockages and things that project that end up never really getting to market. So that is a huge advantage in that sense. And obviously needless to say, like the, the cost efficiency component, less headcount, more sal, like you know, more sales outcome. It's easier to prove ROI on things so you can get more budget. I think it's a great thing for like it's a great time to be a marketer and a gross engineer for all those reasons.
So to recap, roi, speed, efficiency. I mean the name of the game in today's industry, right?
Yep.
All right then like let's switch now to our fun lightning round. So I'm just going to ask you short questions so you can just like walk us through your quick answer and just maybe like add a bit of color as to why you picked that. Sounds good.
Yep.
All right, your favorite CRM, HubSpot, Salesforce or Atio.
I, I am a Salesforce guy. Like very big fan. I've been on Salesforce for many years. End of the day, there's a lot of things to say about Salesforce and things can might change a lot in the next five, eight years. But you Just like you know, you know, helped over 30 companies over the last year and a half and in different capacity, 95% of them pass Series A or on Salesforce, 99% of them pass series B or on Salesforce and a hundred percent of them at least that I've advised post series C or are in Salesforce. So there's an argument to be made that yes, Attio and HubSpot have you know, unlocking or unlocking capabilities early stage and enable for speed and price. But if you're building, you know, if you're building with a vision of becoming a scale up and you want to hire a sales team that has, you know, more than 10 people, I think you're going to have to go with Salesforce. Unless you did a use case or your data model. Use case is super simple and if the costs, you know, if you include, if you layer in the cost of transitioning to a tool post series B it is like, you know, it is going to be like a six digits, you know, mid six digit cost over the next over a couple of years because it's just there's so much inertia in the business processes and you know, implementation costs. So yes, you, you going to have to go through some pain early stage to you know, navigate Salesforce and there's a sweet spot at which you need to bring it. Usually I recommend series A, series A, three, four reps and a sales manager. It's usually my sweet spot. There's an argument to be made that you know, HubSpot is also good for lower volume like CRM instances. But personally I'm a big fan of Salesforce.
I love that and I think like you're probably the first out of 10ish, you know like folks that we interviewed in the pod that had this contrarian opinion but we love contrarian opinions so bring them on. What about your first, your top lln, Claude, GPT or someone else something else?
Yeah, I mean I've experimented with a lot. I think ultimately OpenAI and ChatGPT is my go to and at the today I think they're doing a fantastic job at rolling out models. For every use cases there's still some small use cases for which I still use Claude. Everything that is content heavy, that requires a bit more fine tuning in the verbiage and so on. Copy for example is one example where I would use Claude. But I believe in context and I think OpenAI ChatGPT is doing a really good job at being a platform these days and at being very integrated with the entire stack. They rolled out mcp, you know, a few weeks ago. So I think there's everything you need in one player. And my recommendation, I think as we go is to choose one single LM platform because the underlying quality of the models are going to get very similar and it is going to be a platform play, integration, UI more than the model themselves as we, as we go.
So yeah, again like the moat is data, context and memory right when it comes to these things. So like there's going to be, we're going to quickly see a winner emerging in the next not a year but probably like three to six months even. How about top enrichment tools? What's your go to?
I work with a lot of PLG companies that have very high volume of data. Companies like you know, Linear Descript and those companies, you know, need to make enrichment on top of their warehouse. So my, my go to choice for those companies is going to be Cargo because it's warehouse native, it's built for scale and very composable and it's a bit more programmable than clay for anything experimentation fast, you know, speed to experiment. I'll go with Clay. So those are kind of two different use cases and so those are the two only tools that I use. I mean those are the main platforms you guys are partnered with both, I believe they are today the best in class enrichment tools.
Love it. And what's your overall top GTM engineer tool that you have in your stack?
I mean I kind of like, I think of a stack of like there's three layers. There's this. The first layer is a data layer. So you're going to have your data data warehouse database. Pretty agnostic in that sense. SQL Server. So that's one. Then you have your orchestration in the year we mentioned CLI Cargo. Those are my go to. Like I systematically when I work with a client need to achieve what I do with my client either Clio Cargo, this is, you know, otherwise it's like hiring, getting a pilot, a formula, Formula one pilot. Without a ferry you can't do anything. So those are the, those are the two main tools and then engagement layer. Unifi is doing some excellent job from an engagement platform. They are from a product standpoint, very impressive. They simplified deliverability setup considerably. It scales pretty well and I don't think so far there's too much overlap with Clay and Cargo. So I use Unifi for engagement and it serves both Programmatic Outbound and Sales outbound use cases which is really nice from an operator standpoint because otherwise you kind of need to go with outreach sales love plus an instantly in a smart lead which comes with complexity from an integration standpoint. So having kind of like the best of both worlds in one tool is interesting. So unifi is definitely there and then obviously CRM Salesforce, I mentioned this before. So those are the core, the core building blocks of what we're doing. I also love what Octave is doing on the programmatic outbound front N88 as well. Any workflow tool I think is very interesting as well. Love that.
Yeah, thanks so much for sharing. This was super, super insightful. And yeah, there's also like a few mentions that again no other guests have mentioned to date, which is like I think very, very interesting to hear some different perspective other than the usual suspects. What's your the most underrated of this that that you mentioned that you think like more people should. More about.
I think we haven't mentioned Conversation Intelligence just yet and I think this is the, you know, the new gold mine and I'm thinking about attention. Attention is a conversation intelligence similar to Gong, but again in the same line of this agentic workflow tools that we'd mentioned, they enable workflows and micro agent to basically take away some of those redundant tasks that your BDR or even sales team have to do within the CRM or within, you know, their, their system of engagement. So I believe having building a muscle to create that layer between Conversation intelligence, which is the gold mine of your go to market engine and your stack and building the right AIs and micro agent to execute and streamline go to market action is very, very valuable. I see it as a parallel. I see, you know, back in the days I was a sales ops and you know, being able to build some Salesforce automation or workflow automation in HubSpot was. You were a wizard. I think right now the comp. The parallel in today's time is being able to you know, maintain systems based on real time data collected from sales compensation and do this really well at scale.
Love that. Yeah, super, super important and we're a big fan of attention and what the guys are doing there. All right, let's chat a bit about system design. I mean I think you already touched upon the core layers of your stack and if I had to like play back at you, I can remember like you have start with a data layer from your SQL Server and or db then you have your orchestration layer where you can layer on top enrichment and a bunch of other custom research. Then you have your CRM where you unify all your enriched data and then you send that to the engagement layer with for both programmatic and more one to one sales outbound. Right. And then of course you have other modules that you just mentioned, one with conversation intelligence and one for more messaging with Octave. Right. Anything else that you want to touch upon or that you normally have in terms of like core modules?
Yeah, I think there's in the orchestration piece, I think for PLG companies that have a very strong inbound motion default is a tool that I've implemented many, many times and, and I can only recommend it. It's basically, you know, a way to orchestrate and route, enrich and route, you know, the entirety of your, you know, demo request on your website to your sales engine. So especially when you have a lot of volume, extremely valuable to have this buffer between your website and your sales team to make sure you can have space to lead. Meaning when there's a good opportunity you can jump on it right away. But also assigning the right amount of opportunity based on capacity to your team so that you don't drown them in leads. So super important foundation block.
Love it. And what are the main trade offs that you come across and you have to make in terms of like decision making when designing these stacks.
So I mentioned, you know, I think modularity and composability are two core principle for everything we do. But that comes sometimes at the expense of speed. So it really depends on the stage. But I think for earliest, earlier stage companies, you know, series A, series B made C to series B. I think I try to think of a split brain. So you have your warehouse which is like your analytical brain. You have like, you know, modeling, analytics, potentially scoring and enrichment happening there. And then the CRM is like your engagement brain. This is where you have your rules of engagement, your business logic, your book of businesses you're reporting and like sometimes mirroring those data perfectly across both, both systems. CRM and, and, and warehouse is, is complex, expensive, it requires some data engineering resource or more technical robots, people. And it doesn't necessarily bring a ton of additional values because you have to have ETL loops where data is being pushed back from the CRM to the warehouse and pushed down. So that comes at a pretty significant cost of maintenance. So what I'm recommending for less mature organization is obviously to pick their battle and to push in this CRM what's really needed and, and only pushing it back to the warehouse when there's actual outcomes. And then you can just run like audits like you know, backfills every quarter, every semester to make sure your TAMS and your like you know, core tables or align so that you know if there's additional stakeholder in your organization, namely a marketing team or a product team that they you know, actually know what's going on in the CRM and they can know refer to the schema of the CRM in the warehouse in a pretty accurate fashion. So yeah, that's kind of like you know, sort of a trade off and I think as you grow, as you grow as a larger organization you're, you're getting those, that, that connective tissue a bit tighter. You have like daily, sometimes bi daily refresh rates where things, everything gets connected because you're going to have like BI reporting on top of it. And it, there's a lot of like it's a multi layer cake with a lot more dependency across departments. So the connective tissue gets tighter and tighter as the organization grows.
Love it.
Okay, Nico, question for you. We're going to switch from tools over to talking about workflows and I'd love if you could walk us through one of your favorite plays, one of the most useful plays you think that you build for clients. If you could elaborate on what is the data, what is the signal that you're using as an input, what are the steps, what is the process that gets followed from that signal and then what is the output and the more you can, you know, hone in on one specific company even if you don't use their name would be helpful to illustrate.
Yeah, absolutely. I think the use case that encapsulate the more I mean the most value from a system standpoint and it actually generated a lot of feedback. Very positive business outcome is probably the PQL so product qualified leads, nurturing flow. We roll that with with descript. So descript has a lot of volume of signup basically prosumer emotion where there's a lot of signup and we need to filter out the noise from you know, score enrich all those signups to put them into different, you know, nurturing slash white glove and boarding from a product and sales standpoint to show that there's someone assisting and helping out, you know to make sure the activation happens effectively. So what we set up is a flow where we have cargo sitting on top of the warehouse. The signs up, the signup are going in the warehouse directly into a bigquery instance. Cargo is captured in real time. Those sign up and reaching them, scoring them with some AI scoring blend in and Then where the lead is score greater than 30 or 40 points out of 100, we push it to this CRM and then we have an activation engagement layer that kicks in where we are going to decide depending on tiering. We have tier one, tier three, which kind of engagement cadence and which kind of touches are we going to be sending those people. So TR1 is like going like full manual to the reps and TR2, tier three is a bit of a mix but what we implemented, which work really nicely is a combination of three tools. So Cargo to overarch the overarching workflow, kind of like builder, we have Octave and then we have instantly. So the way it works we have Cargo making an API call to Octave to generate a hyper personalized copy. And what's important to understand here is that within the API call, because we're sitting on top of the warehouse, we have access to the entirety of first party data from the user as well as enriched data. So third party data within the prompt in Cargo we can inject 20 very specific custom data points that are going to give a lot of flavor and context to who is the user, what is his stage in the funnel, what feature he has used if he's stuck on certain things and which is exactly what a sales rep would be doing if he was to look at their dashboard of usage. So we're giving all that context to the agent and then we have a very customized agent in Octave that has specific instruction on the tones we need to use what we're trying to achieve and, and then we customize this into this agent and then we generate an email and that email is then then being sent into a sequencing instantly and the results are on this are extremely, you know, impressive. Like we've made it reviewed by many salespeople. A lot of people ask if it was actually being written by a salesperson or not. And we have, you know, couple of demos a day booked by this only in completely self serve fashion. And it's going to be 5%, you know, 5% that are completely hallucinating. And I think that's important to take this into account to the models and using this for the right, that's why we don't run it on tier one because the cost of mistake would be too high. I think that's also like, you know, a skill in that whole landscape like evals, like being able to actually understand how your model performs and, and being critical on where you can use them and where you cannot is another important skill of the code team.
Marketing engineer can we double click on this real quick, Nico, just to give more context to our audience as to what evaluations are and how does the very high level overview works? Because do you write normally evals prompting your own, do you use specific tools? Because I think this is something that hasn't been talked about a lot in the space. But it's something that as these models become more mature and as people know more about prompt engineering, then they just over rely on the prompt. But then they don't have that feedback loop that actually close the iteration part. Right. So why don't you tell us more?
Exactly. I think there's a lot of buzz around prompt and you see a lot of prompts on LinkedIn. It's very easy to write a prompt. You could just ask an AI to write a prompt for you and the prompt is the easy part. The evals is actually evaluating the results of your prompt and your model for a given business use case. So it is, you know, data science concepts such as accuracy, recall and precision, those are obviously a bit more advanced. But in very simple terms it's like did the model extract the right company from this email, yes or no. And then verifying this with additional prompts that are going to basically use the output from your, from your data and then re evaluating it. So naval is in very simple terms it's an input, an expected output, like what a human will say and then the actual model input and then comparing what you would expect against what the model generated and whether we are happy with it or not, that's in very simple terms what an eval is. So I think in everything we do we don't use tools. I'll actually be very curious if you know, like tools that enable to do evals for those use cases. But it's like you know, for example for lead scoring model we're going to say, you know, fit score reasoning. So explain asking the AI to explain why a lead is good or not on what criteria did he use to generate that score and then ask him to be critical. So what things does the, the model has probably forgotten or not used to as much as he should have used. So those are very important things to implement when you roll out those prompts. And I think there's, there's, you know, some consideration around the prompt. The, the result of the models being evaluated into a different framework. So kind of like zooming out of, of the original prompt and giving him additional context and additional, you know, criterias to run the answer against and seeing how the combination of that new prompt and the previous output is performing. And I think, you know, this is kind of like for me this is kind of good. Like there's a term that I think is I'll just give it to you guys in exclusivity. But go to market observability, which is the ability to constantly observe how your workflows are performing against what is the baseline of expectation is part of the scope of a go to market engineer. And that's what's going to differentiate the noise and the mass of people currently marketing themselves as go to market engineer because they use AI and they write prompts from people that can actually roll out a solution at scale in business context.
I love that and I think like what you just said basically in terms of like the observability part that yes reconnects to the or links back to the evals and the iteration. I think it's just like differentiating probably the top 1% from the top 0.001% of the market at the moment. But great to know for everyone in the audience. I think like this is definitely like something to yeah keep track of as the market evolves, switching to skill set and trends. You know, like we touched upon a bunch of things that were, you know, an absolute goldmine of, of knowledge so far. Nico, what do you think are the new really skill sets that new GTM engineers must learn today to then stay competitive? You know, like as the really we get through this, swap through this like script or market changes.
So I, I think data literacy as a, as a whole is super important. You know, understanding, you know, being able to write basic SQL, understanding data structures, understanding databases. Ultimately, you know, we talked about context and memory before. Context and memories, you know, is just feeding models, you know, databases and data structures. So if you're going to use databases, if you're going to use models that have good context, you're going to have to feed them the good data. And to feed them good data you're going to have to be data knowledgeable. That's probably the number one. I think the second thing is fluency with the new tools, just playing with it, building workflows with concrete business use case, Clay, cargo, all the LLM out there annotate, just understanding how to actually put them into practice. That's obviously you know, table stick. And then I think, you know, there's the less talked about like piece is also like you know, this like business acumen being able to be a partner to marketing and sales leader, understanding what they're doing, what's Working shadowing sales team and you know, really being taking the pulse of their current sales team. Kind of what was like the enablement traditional function. The enablement function is kind of like owning that feedback loop between system and sales. And I think that go to market engineer should be tasked with being able to interact with those people and really get very tight feedback with what he's rolling out. Because if you add something in between he's going to lose context and various important snippets of feedback that he should be the one hearing directly firsthand from reps to then tweak his system in his design accordingly.
Beautiful. And how do you normally advise like aspiring GTM engineers like to acquire these new skills?
I mean I think, I think part of it is hard skills and I think those can be acquired online now the entire web is full of information and you can really just upgrade your skills in a few months. And you don't need because AI is so powerful, you don't need to be an expert expert to actually be dangerous. But having a basic general foundation of all those concepts, taking you know, data science 101, taking probability 101, taking you know, data structure 101 and just having this like and maybe one or you know, maybe the next level as well. But getting this basic level in all those core discipline to actually be able to understand when you talk to people that are actually expert what you want and in a soft skills and honesty it's practice. It's like you know, running projects failure and then just running rinsing and repeating that's like it just takes years, you know And I don't think the good news is I don't think this is going to go anywhere because you know, AI is never going to be perfect. Real world is messy, business world is messy and being able to learn muscle is going to be powerful.
That's comforting given the times. Very optimistic way of seeing this. But yeah, if I have to play back at you, it's basically again just making sure that if we go back to that T shape of the cross functional operator, you want to make sure that the base layer keeps getting thicker and thicker.
Yeah, exactly. And creative, creative skills, you know, connecting creativity comes from like ability to have interest and curiosity in very different fields. And that's going to be a core. I haven't mentioned in a core field to run experiment experiments have to be creative by nature. An idea is the first piece and then being able to put in action. There's something in data sense, it's called feature engineering. It's basically creating a net new data, data points from a lot of different columns because you think there's value in aggregating things together. That that is a skill that's very valuable this day. If I use this and this and this, can this become a data point that I use as a standalone data point for other things? And can it actually work? And verifying if it works.
Awesome. Thanks so much for sharing, Nico.
Let's say earlier in their career joins a company, let's say it's a PLG company, they're just getting going, not much has been done. What's something real practical they can implement early on? What's one of the first, first places they can add value?
Yeah, I think one thing that is kind of like underlooked at the early beginning and that brings a lot of clarity is building a very solid TAM that is not in a spreadsheet, meaning whether it's the CRM, if it makes sense, order warehouse, if it's more, if you have more volume. But having running through this exercise of talking with the marketing leader, talking to the sales leader, talking with the revenue leader and being like, let's actually put in one place everything we believe is within our TAM and let's make sure we've mapped it out intentionally and make sure we have as a company the same understanding of who are our icp, how do we classify them? And that's a really good forcing function to bring everyone on the same page. And then once you have this building block of your time, it's very easy to just start experimenting because you have a common reference framework.
And what does that look like for you? Is it, is it ICP and target Persona definitions or is it all the way to. These are specific. This is a very long list of all the companies that we're going to reach out to in the next year and the people within them.
Yeah, so, so, so step one is defining ICP Personas. ICP account level, Persona person level. That's one. And then once you lay that out, then, okay, well, let's fetch all the existing companies we have in our database in our salesforce and then find all the other ones we haven't even started talking to. And let's like put them together into one central place. And then once we have that, once we have this list, let's say 5,000 companies that are matching exactly our ACP. Let's fetch within each of those unique domain the Personas that we've identified, 5 to 10. That is basically all your sales team needs to start you know their work and then obviously there's going to be some maintenance. There's a layer of signals you're going to want to have around this because the static time with enrichment is not enough. You're going to want to capture dynamic signals and and so on at the account level. At the person level there's a lot more complexity to it but you can start very small and I'm going to repeat myself. But the forcing function is to get different stakeholder to align on who are the people we actually outreach because you'll be surprised how disconnected the strategy is. So not only you know it's the systems are going to get disconnected, but if you don't have the strategy even laid out properly and aligned and people being aligned on this, then it's not going to work at all from a system center. So I think that's a really good place to start. If I was to start at any company, that's where I would start for sure.
Fantastic. Yeah, really helpful. All right Nico, so this has been really awesome today. Tell our listeners where they can connect with you and keep up with the latest insights from Nico.
Yeah, I mean best way to connect with me is on LinkedIn probably Nicolas Tro. There's also my email on my LinkedIn so they can feel free to reach out on my email as well. And yeah, that's pretty much the best way to get in touch.
All right Everybody check out LinkedIn so that'll be a wrap for today. Nico, huge thanks for joining us. Your depth of expertise in PLG go to market is second to none. From warehouse native workflows to AI powered PQL scoring. Nurturing, definitely your love for cargo clay, unifi attention, other great tools. Today Nico gave us a real masterclass in modern GTM engineering. So if you're out there and you're building for scale or navigating high volume inbound, you'll definitely want to replay this one. Thanks again for tuning in and we'll catch you next time. Take care Nico.
Thank you guys so much for joining Nico.
This is great.
More from Matteo

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









