Jorge Macías

Jorge MacíasSep 14, 2026

GTM Engineering is an extraction of what product marketing was supposed to be. Product marketing has always had the mandate to sit between the product and the market, understanding both well enough to translate one into the other. Most companies never built defined processes to govern it effectively, so the PM’s role drifted into writing launch decks and maintaining battlecards while the actual translation work went undone. That left a gap wide enough for a new title to walk into, and GTM engineering is what walked in. Thanks to AI, people filling that gap today can ship these systems the job always needed in the first place. Product marketing could describe the ICP. A GTM engineer builds the workflow that finds it, enriches it, scores it, and routes it into the CRM in no time. I'm dropping this sermon today because it seems like a lot of marketers have decided this role is closed to them, and a lot of engineers have decided the same about the marketing side. There’s this unverified claim flying around that you need veteran-level foundational skills (in either one) to have a chance of making it in this industry. False. The only real requirement is whether you are building more than you are talking.

Jorge MacíasSep 15, 2026

If I’m not careful with my client’s budget, I’m not doing my job as a GTM Engineer. My Clay SOP before any engagement shows how obsessed I am with cost discipline. Here’s a rough picture of how I set things up at the beginning: Step one is always getting the client’s AI API keys into Clay. That’s the starting point. I use OpenAI for anything that’s about sorting or formatting. Like putting job titles into categories, breaking addresses into city, country, and postal code, or sorting data into buckets. For research and reasoning, I lean on Anthropic. Visiting a prospect's site, following a link to a second page, reading both, and arriving at a conclusion. As you can see, I push the sorting and formatting work through the cheaper model, and the reading and reasoning work through the expensive one. The difference is simple: if the answer is already in the data, like a job title that just needs to be categorized, I use the cheaper model. Paying extra for that would be like hiring a researcher just to alphabetize a list. But if I need the model to visit a prospect’s homepage, click through to their careers page, and figure out if they’re building an outbound team, that answer isn’t in the data yet. The model has to go find it. That’s where the higher cost makes sense. I’m not looking to pocket every dollar I save, either. Every dollar I don't burn on postal codes goes back into the build, into the column that actually finds signal, into the enrichment that tells my client which accounts are worth a call this week. That’s the difference between GTM Engineers who spend the budget to drive results and those who just want to show off their technical skills.

Jorge MacíasSep 17, 2026

As GTM engineers, we often lose the champions who vouched for us in the first place. So, I built a sweep that checks whether each contact still works where you think they do, refreshes the ones who stayed, and routes the ones who moved. It runs in Claude Code, Codex, Swan, or your terminal, and ships with three reference files covering setup, company matching, and tiering. Grab the workflow playbook here (https://lnkd.in/ehgJkJPS) or watch the video to step inside the inner workings of my brain + the logic supporting every build. Youtube link here: https://lnkd.in/eYmJzixB Special thanks to Sandy and the fantastic Pitstop team for helping me put this together! GTM Skill here: https://lnkd.in/edqBYVdr