A Practitioner's Field Guide to Marketing Engineering

My name is Kristina Vislianska. I'm a growth marketer with 10+ years in B2B and B2C SaaS, AI, and Web3, and for the last couple of years, most of what I ship isn't campaigns. It's systems that run campaigns. At some point, recruiters and founders started calling this "marketing engineering." I had to Google it. Turns out I'd been doing it for a while; I just called it "building stuff so I don't lose my mind doing the same thing every Monday." This guide is for marketers who want to build, founders who want to hire someone who builds, and engineers who wonder what marketers are doing with their Claude or Codex Pro Max. Everything here comes from systems I built and ran, including the ones that broke. Key points, if you only have a minute: Marketing engineering turns repeatable go-to-market work into software, so one person can run what used to take a team. The work follows a five-layer loop: Listen, Understand, Make, Ship, Learn. Decide what to automate with two questions: how often does the task repeat, and how bad is a public mistake? The biggest wins are in listening and learning, not in generating more content. You don't need a CS degree. You need to read code well enough to know why it broke. What is marketing engineering? Marketing engineering turns repeatable go-to-market work into software, combining marketing judgment with engineering skills. Its systems listen to the market, turn what they hear into content, distribute it, and learn from the results. A marketing engineer's output is not a campaign. It's the machine that produces campaigns. The deliverable is a monitor, a pipeline, an agent or a feedback loop. Something that keeps working when you close your laptop. And no, it's not "marketing that uses AI tools." Asking ChatGPT for ten hooks is using a tool. Marketing engineering starts when the work keeps running without you typing. The title keeps changing. A few years ago it was "growth hacker," then "marketing technologist," now "GTM engineer" and "marketing engineer." Honestly, I don't think the title will survive. The skill will. How is a marketing engineer different from a GTM engineer or marketing ops? Marketing ops runs the machine. A GTM engineer builds the machine for sales. A marketing engineer builds the machine for attention. The three roles overlap, and the job titles are still a mess, so here's how I draw the lines. Marketing ops keeps the existing stack working: clean CRM data, campaign setup, attribution reports. Success looks like data you can trust. GTM engineers build the revenue engine for sales: enrichment, outbound sequences, lead routing. Success looks like meetings booked and pipeline. Marketing engineers build the systems that create and distribute marketing: listening tools, content pipelines, community monitors, AI search presence, agents. Success looks like reach, citations in AI answers, and how much one person can run. Think of a restaurant. Marketing ops keeps the kitchen clean and the orders flowing. The GTM engineer builds the delivery system that gets food to customers who already ordered. The marketing engineer builds the thing that makes people walk past and want to come in. Usually a marketing engineer combines the roles of a whole team of specialists. I like to call them the king of agents and systems. What does a marketing engineer actually build? Everything I've built fits into one of five layers: Listen, Understand, Make, Ship and Learn. I call it the marketing engineering loop, because what you learn at the end changes what you listen for at the start. Listen. Where is the conversation happening right now? Keyword monitors, social radars, forum and review scrapers. Understand. What does it mean for us? LLM-summarized research, pain-point maps, competitor tracking. Make. What do we say, and in what form? Content, video and voice pipelines. Ship. Where does it need to live to be found? Multi-agent systems that ship content across channels, owned communities, presence in AI search. Learn. What worked, and why? Performance logs, experiment tracking, and feedback back into Listen. Here's the thing most teams get wrong. They start with Make, because "AI writes posts" is the obvious use case. But content volume was never the bottleneck. In my experience the biggest gains sit in Listen and Learn. Listening finds the moments worth acting on. Learning tells you which of your actions actually mattered. What should marketers automate first? Automate tasks that repeat often and are safe to get wrong. For tasks that repeat often but happen in public, let the machine draft and keep a human on the send button. I call this the frequency × risk matrix. The most common mistake I see is automating whatever is easiest to automate. That's how you end up with a bot that confidently replies to a grieving customer with a discount code. Two questions work much better: how often does this task repeat, and how bad is it if the machine gets it wrong in front of people? The answer is a split: the machine finds and drafts, a person approves and sends. Five marketing engineering systems I built, one per layer Theory is nice, but you came here for the real stuff. Here's one system for each layer of the loop, with what it taught me. Listen: a client-finding radar on Threads Situation. I wanted to find advisory clients without cold pitching. I hate cold pitching, and so does everyone receiving it. The best moment to talk to a founder is when they post "we just raised" or complain that growth has stalled. Those posts disappear from the feed in hours. What I built. A radar that searches Threads for pain-point phrases in English and trigger phrases in Ukrainian, like "we raised" or "we got our first revenue." For every match it drafts a reply and pings me in Telegram or email. I read it, rewrite it if needed, and post it myself. The system never posts on its own, and nobody gets a pitch in the first message. What it taught me. Listening is the cheapest layer to automate and the most valuable. Timing beats copy. Understand: market research that turns into product Situation. At an AI workflow automation platform, we were selling agents to small service businesses in seven verticals. To sell to them, we needed to know which tools they already use and what actually makes them swear at their phones. What I built. A research system that produces three things per vertical: an integration map of the software they already use, a pain-point file built from scraped Reddit threads and classified by an LLM, and ready-made agent templates that solve the top pain with the tools they already have. The research didn't just shape the message. It turned into the product itself: the templates. What changed. Cost per lead dropped by 80%. Instead of guessing, we shipped 7 agent templates, one per vertical, each built around a pain owners described in their own words. Our one-size-fits-all pitch was gone. What it taught me. Research is the cheapest way to lower acquisition cost. Before you spend another dollar on ads, find out how your buyers describe their pain. And the same research that shapes your message tells the product team what to build next. Make: a video factory with no video team Situation. We needed explainer videos for all seven verticals. We had no video team and no budget to hire one. What I built. A pipeline where a script goes in and a finished video comes out. The script is split into lines. A voice API generates the voiceover for each line as a separate audio file. Remotion, a React framework for video, renders each scene, and the length of each audio file sets the length of its scene. The on-screen graphics come from a custom skill that holds our whole design system, so every frame follows our brand style guide. What changed. Seven verticals covered without hiring a single editor. One agent turns a script into a finished, on-brand video in 15 minutes. The pipeline produced 5 videos a day at under $1 each, a fraction of what an agency charges. What it taught me. When a video costs less than a dollar and 15 minutes, it stops being a project and becomes an experiment. You can test messages in video the way you test headlines. The bottleneck moves from production to knowing what to say, which is exactly why the Listen and Understand layers come first. Learn: an outreach extension for X Situation. Outreach on X works best when you show up in the right conversation at the right moment. Doing that by hand means scrolling for hours, hoping to catch the one post where someone describes exactly the problem you solve. And by the time you've written a good reply, the moment is gone. What I built. A browser extension for X that finds outreach opportunities by keywords and trigger phrases, like someone announcing a launch, asking for a tool recommendation or complaining about a problem. When it finds a match, a ready-made prompt system drafts the reply for me in my voice. I read it, tweak it if needed, and send it myself. Every reply gets logged, so the system learns which triggers and formats actually start conversations. What changed. 20 targeted replies a day, without losing my whole morning. Instead of scrolling for an hour to find two good posts, I review a list of drafts, each tied to a real trigger, and spend my time only on the human part. The logs show which triggers start conversations and which just collect polite likes, so the keyword list gets sharper every week. What it taught me. Automating Learn isn't about saving time. It's about running enough experiments to see what a platform rewards and punishes. A handful of manual replies will never show you that. The six laws of marketing engineering Tools change every few months. These six principles haven't changed across anything I've built, and most of them I learned by breaking something. Fix the process before you automate it. A system amplifies whatever you feed it. Unclear messaging run through a content pipeline is just unclear messaging at scale. Faster and cheaper, sure. Still bad. Keep a human on the send button. Machines can find, research and draft. Anything that speaks to people in your name needs a person who approves it. People can feel when nobody is behind a message. Automation scales output, not demand. A system can answer every question in a niche. It can't create new questions. Every channel has a ceiling, so plan the next one before you hit it. Don't build on ground you can't replace. Platforms change the rules without asking you. When Reddit tightened its API access, the keyword monitor I'd built for my project, broke overnight. Design every system so any single part can be swapped. Every system you build is a system you own. Scrapers break, APIs change, prompts drift. Count the maintenance cost before you start, and kill systems that stopped earning their keep. Measure experiments, not hours saved. The real return on automation is how many tests you can run and learn from. Saved hours are a nice side effect. How do you become a marketing engineer? You don't need a computer science degree. You climb four rungs: Operator, Assembler, Builder and Architect. Each one needs a different skill, and most marketers get stuck between the second and the third. Full honesty: I don't write Python from memory. I build with Claude Code and Cursor. What I can do is read the code, understand why it broke, and explain to the AI what to fix. That's the real skill. Operator. You use AI tools by hand, one task at a time. To move up, notice which tasks you repeat every single week. Assembler. You connect tools with no-code automations. To move up, learn how APIs, triggers and data formats work. Builder. You ship scripts and pipelines with AI coding tools. To move up, learn to read code, debug errors, and handle authentication and rate limits. Pro - optimise the model costs. Architect. You design whole loops and decide what not to build. This is where systems thinking, metrics and maintenance budgets come in. The jump from Assembler to Builder isn't about learning to write code. It's about learning to read it well enough to tell why it stopped working at 3 a.m. Your best first project? Your most boring weekly task. Build the system, put yourself on the send button, and measure what you learn, not the time you save. That's the whole discipline in miniature. FAQs about marketing engineering Is marketing engineering the same as growth hacking? No. Growth hacking was about finding clever tactics. Marketing engineering is about building durable systems that run those tactics repeatedly and learn from the results. Do marketing engineers need to know how to code? They need to read code, not necessarily write it from scratch. With AI coding tools like Claude Code or Cursor, the bottleneck is understanding what broke and why. What tools do marketing engineers use? Usually LLM APIs, Python or JavaScript, scrapers, no-code automation tools, voice and video AI, etc. The specific tools matter less than the loop they form. What is the difference between a marketing engineer and a GTM engineer? A GTM engineer builds systems that turn buying signals into sales pipeline. A marketing engineer builds systems that turn market signals into reach, content and visibility. What should a company automate first in marketing? Tasks that repeat weekly and are safe to get wrong, like monitoring, research and reporting. Public-facing tagive me sks like replies and outreach should be drafted by machines and sent by humans. Will AI replace marketers? AI replaces repetitive marketing tasks, not marketing judgment. Deciding what to automate, what to say and when a process is broken is still a human job. The short version Marketing engineering is not about making more content faster. AI already solved that, and honestly, the internet didn't need more of it. It's about building systems that know where to listen, what to say, where to ship it and what to learn from it, while you keep the judgment. The tools will keep changing. The judgment about what's worth automating is the part that stays yours. Which layer of the loop have you automated already, and which one do you think is overrated? Tell me in the comments. I read all of them, without a bot. K