Humans of Martech

What's up everyone, today we have the pleasure of sitting down with Jason Dobbs, Head of Marketing and GTM Engineering at Kumo AI.

  • (00:00) - Intro
  • (01:24) - In This Episode
  • (01:57) - Sponsor: MoEngage
  • (02:54) - Sponsor: Knak
  • (04:35) - How Undefined Data Definitions Make AI Confidently Wrong
  • (08:18) - Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck
  • (12:59) - The Five Non-Negotiables for AI Readiness in Marketing Ops
  • (15:42) - Why Marketing Ops Is the Context Architect in an AI-First GTM Stack
  • (24:50) - Which Data Problems Block AI Deployment and Which You Can Ignore
  • (28:29) - Sponsor: GrowthLoop
  • (29:32) - Sponsor: AttributionApp
  • (34:24) - What Goes Wrong When Agentic AI Optimizes Directly on Warehouse Correlations
  • (42:02) - When to Ship AI Before Your Data Is Ready and When to Fix the Foundation First
  • (48:23) - What GTM Engineering Actually Means When AI Automates the Middle
  • (50:55) - How Jason Dobbs Decides What Deserves His Energy
  • (53:08) - What Jason Is Reading: Intelligence History, Mind-Opening Nonfiction, and Dune

Summary: Jason Dobbs spent 7 years assembling intelligence briefings for the President, and he says most AI failures in martech are the same problem he was solving in 2003: teams acting on context they never actually agreed on. In this episode, he breaks down the 5 non-negotiables of minimum viable readiness before you deploy any AI agent, explains why the marketing ops function is becoming more critical as AI takes over execution, and argues that unbounded AI autonomy creates more risk than warehouse data ever will. He also defends GTM engineering as a real discipline rather than a rebrand, and closes with a Dune analogy that lands better than it has any right to. If you think AI readiness is primarily a data engineering problem, this episode will change how you think about your team's role in it.

About Jason Dobbs

Jason Dobbs is the Head of Marketing and GTM Engineering at Kumo AI, where he leads go-to-market for KumoRFM, the world's first relational foundation model, which generates accurate, explainable predictions directly from warehouse data. Before Kumo, he served as Global Head of Revenue Marketing at Logitech, where ABM and advanced segmentation drove 40% of B2B sales revenue and 79% YoY ARR growth. He also co-founded Trypp, an autonomous UX research agent for continuous post-ship product monitoring, and has held marketing and analytics leadership roles at Seagate, HTC Vive, Apple, and Google.

Jason spent 7 years as a United States Air Force intelligence officer, including work on the President's Daily Intelligence Briefing, an experience that shapes how he thinks about assembling trustworthy context for high-stakes decisions under uncertainty.

How Undefined Data Definitions Make AI Confidently Wrong

Every marketing ops team has heard the warning: AI is only as good as the data you feed it. You've nodded along. You've probably said it yourself. But the warning leaves out the most important detail, which is what the failure actually looks like when the model is running.

Jason Dobbs knows what it looks like. He learned it from a crash. He rides high-speed F1 electric skateboards at 50 to 60 miles an hour, and he's fallen before. He can tell you he's never fallen the same way twice. When he greenlit agentic and predictive workflows at Kumo AI before the data architecture was ready, the failure followed the same logic: unexpected, and avoidable only in hindsight.

The model returned results that looked operational. Scores came back precise. Summaries sounded coherent. Recommendations felt grounded. The failure was invisible to anyone who didn't already know what correct should look like.

The weakness surfaced when someone pushed. Ask the follow-up question, why did you score this account, what data drove this decision, and the logic fell apart. The definitions feeding the model had never been agreed on across the business. Sales and marketing were not working from the same idea of what a qualified lead meant. The AI had scaled an unresolved internal argument into what looked like a confident answer.

Jason traces the failure to a structural problem that predates any model decision. When a system cannot explain its own outputs, and when nobody in the room has standing to say what the correct answer should look like, you have built a very polished way to be wrong. That is dangerous precisely because it passes a surface inspection. People who were not close to the data trusted the output. Nobody pushed back.

What he carried out of that experience was a reframe of what marketing ops actually produces. The shared definitions, the trusted data sources, the named owners, the workflow guardrails: that is the product. Every AI initiative sitting on top of unresolved questions about what the business means by its own terms will generate outputs that look credible right up until someone has to act on one. Speed to AI deployment and quality of AI output run in opposite directions for teams that skipped the definition work. The ceiling on any AI system is the clarity of what the business agreed it was optimizing for before anyone touched a model.

Key takeaway: Run this diagnostic before signing off on any AI or analytics initiative: can a human reproduce the logic behind the output and explain who owns the decision that follows? If nobody can answer that cleanly, the system is automating an unresolved argument. Start by documenting shared definitions for your 5 most-used business terms (pipeline, qualified lead, active customer, opportunity, churn) and get explicit sign-off from sales, marketing, and ops before any model sees them.

Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck

"Context engineering" is appearing in every AI strategy conversation right now. Scott Brinker devoted a report to it. Conferences are building entire tracks around it. The framing is right, but for most teams the phrase still points at a feeling rather than a concrete set of decisions.

Jason Dobbs's version is more precise. "Fix the data" is the directive most teams have been living under for years, and the structural problem with it is that it makes the work sound like a single epic project with a clear endpoint, a Holy Grail that teams have been questing toward since before the first CRM went live. The warehouse always has gaps. The CRM always has problems. The right question is narrower: what minimum context and control does this specific workflow actually need to produce a trustworthy output?

That reframe narrows the scope from an organization-wide data quality initiative to a workflow-specific requirements checklist. For any given AI decision, the context bundle has 6 components: the definitions the system is operating from, the data sources it has access to, the tools it can invoke, any memory it carries between sessions, the guardrails on what it can do autonomously, and the escalation path when confidence runs low. Those requirements are specific to each workflow. They're answered by asking exactly what this workflow needs, not by cleaning the warehouse in general.

The shift from prompt engineering to context engineering reflects how the bottleneck has moved as the models matured. A prompt is the last instruction a model receives. Context is everything it's working with before that: the definitions, the data access, the scope of authority, the path back to a human when a decision exceeds what the system should make on its own. Teams tuning prompts while leaving the underlying context undefined are optimizing the most visible variable in the system while the one that actually governs quality sits untouched. The model's ceiling is no longer the limiting factor. The architecture feeding it is.

Most AI programs in martech hit the context problem within months of deploying anything beyond a summarization or drafting tool. The teams that build the context bundle first move through that wall. The ones that don't spend months diagnosing why outputs looked fine in the demo and stopped working in production.

Key takeaway: Map the context bundle for 1 workflow you plan to give AI authority over. Write down 6 components: the definitions of all key business terms involved, the data sources the system will access, any tools it can invoke, what memory it carries between sessions, the guardrails on autonomous action, and the escalation path when confidence runs low. Share that map with every stakeholder who touches the workflow and get alignment before the system runs.

How Intelligence Analysis Shaped Jason's Framework for Trustworthy AI Context

Context engineering sounds like a new discipline. Jason Dobbs has been practicing the underlying method since 2002.

Before he ran marketing at Kumo AI, before GTM engineering was a job title, before enterprise AI was a boardroom priority, Jason spent 7 years as a United States Air Force intelligence officer, working at one of the highest-stakes context assembly jobs that exists: the President's Daily Intelligence Briefing. That job requires building decision-quality assessments from inputs that are incomplete, contradictory, and time-sensitive, under conditions where the cost of a confident wrong answer is not a missed pipeline target.

What that work required is a discipline that maps directly to the AI readiness problem. You are never working with complete information. You are always building a decision picture from inputs that are incomplete, often contradictory, and time-sensitive. The real skill is knowing what to trust, what to discount, what has gone stale, and when uncertainty is high enough that a human needs to stay in the decision loop rather than ceding it to the system.

Intelligence analysis has formal names for its collection streams: human intelligence, signals intelligence, imagery intelligence, measurement and signature intelligence, open source reporting. Each stream has known strengths, known weaknesses, and a reliability profile that changes with time. Analysts don't aggregate these streams blindly. They calibrate them against each other, weight them by recency and confidence, and flag the gaps where the picture is thin.

Jason maps this directly to enterprise AI. CRM data, product event history, engagement signals, support records: these are enterprise versions of intelligence collection streams. Each has its own reliability profile, freshness window, and appropriate scope of application. The context engineer's job is the same job the intelligence analyst has always held. Assemble enough trustworthy context to make a good decision without fooling yourself. The systems are different. The discipline is identical.

Intelligence culture builds in epistemic humility that most marketing analytics culture lacks. Intelligence reports carry explicit confidence levels: we assess with moderate confidence, sources are rated for reliability, conclusions are tied to specific evidence. Marketing dashboards typically state everything as fact, with no uncertainty indicators and no confidence score attached to any metric. The teams closing that gap are the ones producing AI output that people actually trust enough to act on.

Key takeaway: Rate the reliability of each data source your AI system depends on. For each source, document: how often it's updated, who maintains it, what decisions it can drive given its freshness, and what blind spots it's known for. A quarterly-updated CRM field and a real-time product event are different kinds of evidence, and treating them as equivalent is one of the fastest ways to build a system that produces confident wrong outputs.

The Five Non-Negotiables for AI Readiness in Marketing Ops

The pursuit of perfect data before AI deployment is a trap. Jason Dobbs names it directly: it sounds like the quest for the Holy Grail, a mythic initiative teams launch with conviction and never quite finish, regardless of how disciplined or well-resourced they are. Perfect data is not the prerequisite. Trustworthy context plus a clear approval path is.

The framework Jason calls minimum viable readiness has 5 components, and he is precise about what each one requires. Shared definitions come first. Sales, marketing, and rev ops have to be working from the same understanding of what a qualified lead is, what counts as pipeline, what "active customer" means in this organization. When those definitions don't exist or aren't agreed on, the model doesn't produce wrong answers because it's bad.

The second requirement is trusted access: not just that the data technically exists somewhere, but that the system can actually see the right records with the right joins and with enough freshness to make the decision the workflow requires. Third is named ownership: when something goes wrong, there has to be a specific human responsible, not "the data team" or "the model," but a person or a small set of named people with actual accountability. Fourth is authority boundaries: a clear definition of what the system is allowed to do autonomously versus what requires human review before any action follows. Fifth is an eval path: before any workflow gets real authority, there has to be a way to test whether the output is good enough and a rollback plan if it isn't.

What makes this framework useful is that it's workflow-specific, not enterprise-wide. You're not being asked to clean the entire data estate or resolve every cross-functional alignment issue in the company. You're being asked whether this one workflow has the 5 things it needs to operate with whatever level of authority you're planning to give it. Take one workflow, score it red, yellow, or green across those 5 criteria, and you have a faster and more honest readiness assessment than any strategy presentation can produce.

Minimum viable readiness is also not a static goal line. The 5 requirements change as the workflow's authority grows. A system allowed to draft and summarize has different requirements than one allowed to change records or contact customers. The framework is useful precisely because it scales with the stakes rather than setting a universal bar that either blocks every deployment or approves every one.

Key takeaway: Score 1 planned AI workflow across the 5 minimum viable readiness criteria: shared definitions, trusted access, named ownership, authority boundaries, and an eval path. Assign each a red, yellow, or green. Any workflow with 3 or more reds should stay in advisory mode until those gaps close, regardless of the business pressure to deploy faster.

Why Marketing Ops Is the Context Architect in an AI-First GTM Stack

Jason Dobbs started as a Salesforce administrator. He's watched the marketing ops function evolve through every platform cycle, and his read on what AI is doing to the role is more nuanced than most practitioners expect.

As AI systems handle more execution, the people closest to the business logic governing those systems become the most critical resource in the stack. That dynamic points in the same direction for ops teams everywhere: the role is expanding in scope, even as headcount pressure increases. As agentic workflows automate the tasks that previously required a human making every individual decision, the function that defines the rules governing how those machines behave becomes indispensable.

In practice, that means marketing ops owns the map that every AI workflow runs on: what source systems feed each decision, what signal or prediction gets produced, where that output lands, what action follows, and who has authority to stop it when confidence is low. No other function is closer to those answers. And no other function has more at stake when an AI system gets the routing logic or the definitions wrong, because those are the problems that ops teams are historically the first to hear about.

Jason's practical advice for ops teams starting this work is to resist the instinct to tackle the entire data estate at once. Starting with a giant backlog of every bad field, every sync issue, every messy table is how teams get overwhelmed and stall. Start with 1 decision loop. Map it end to end. Prove that the approach works on something bounded and concrete. Then use that workflow as the template for the next one.

The teams that understand this shift before it fully arrives will be positioned to lead it. The ones building toward AI capability by investing in the operational context layer are accumulating a structural advantage that compounds. Every workflow properly mapped and governed is infrastructure the next AI initiative can build on. Every workflow deployed without that foundation is technical debt that shows up as a credibility problem later.

Key takeaway: Pick 1 AI decision loop your marketing team is involved in and map it completely: what source systems feed it, what signal or prediction gets produced, where that output lands, what action follows, and who can stop it if confidence is low. That map is the minimum output needed from any ops team before an AI workflow touches a customer. Build it before any stakeholder conversation about deployment scope.

What Marketing Ops Can Fix This Week Without a Data Engineering Ticket

One of the most common failure modes in AI readiness work is the belief that most of the foundational problems require a data engineer. They don't. Phil laid out 3 categories of work that land squarely in marketing ops territory, and Jason confirmed and extended the list.

The 3 Phil named: deduplication, the single most visible data quality problem in any CRM and almost always fixable without warehouse access; basic ID resolution on the marketing side, where enrichment tools handle the pre-identification work; and CRM-to-MAP sync issues, wrong field mappings, sync filters, bidirectional conflicts, all configuration problems that don't need a data architecture change to fix. Jason's read: those 3 are right, and they don't cover everything ops can own.

Deduplication, enrichment rules, field governance, sync mappings, routing logic, suppression rules, lifecycle stage definitions, QA processes: these are the systems AI actually sees when it's making decisions. Maintaining them doesn't require touching the warehouse. It requires ops doing the work that tends to fall through the cracks because it's not tied to a campaign or a revenue target. But once the model is good, these are the variables that determine whether it produces value or scales noise.

The boundary question matters too. Core ID stitching, warehouse modeling, event schemas, semantic consistency across systems, real-time freshness pipelines: those typically require a data engineering engagement. The trap Jason flags is treating tool access as a readiness signal. Adding more system connections to an AI workflow doesn't make that workflow more trustworthy. Better definitions and cleaner handoffs do. The 2-column list forces the distinction. Put the deduplication and field governance work in column 1, work through it, and stop waiting on everything in column 2 to be resolved before you start.

Key takeaway: Make the 2-column list: one column for problems ops can fix this week, one for problems that need a data engineering ticket. Deduplications, field governance, sync mappings, routing logic, enrichment rules, and suppression lists belong in column 1 for most marketing teams. Work through column 1 before treating column 2 as a blocker for AI deployment.

Which Data Problems Block AI Deployment and Which You Can Ignore

Telling a marketing ops team to clean the data before deploying AI produces a list of problems long enough to postpone deployment indefinitely. Most of those problems are real. Most of them are also not relevant to the specific workflow you're trying to run. The diagnostic question Jason Dobbs uses to separate the 2 has nothing to do with data quality per se. The question is: what authority is the system actually being given?

If the AI workflow is summarizing content, ranking options, or drafting outputs for a human to review, the tolerance for messy data is reasonably high. Free-text fields with inconsistent formatting, missing non-critical attributes, duplicates on low-stakes records: these are ugly but workable. The system is producing a draft or a recommendation. A human is still in the loop before anything happens in the real world.

The threshold changes completely when the system crosses into action. Changing records, controlling marketing spend, sending communications to customers, making or influencing a revenue decision: these functions require a data architecture that can actually be held accountable. When the stakes rise, the list of tolerable gaps shrinks fast. Undefined business terms are disqualifying. Broken ID resolution is disqualifying. Unknown freshness on decision-critical data is disqualifying. No clear approval path or rollback mechanism is disqualifying.

Jason's diagnostic protocol is specific: what exact actions is the AI going to take? What fields drive those actions? Can a human reproduce the answer from the source data, not just accept that the output looks plausible, but actually trace it back? What threshold matters for a good outcome? What happens if the answer is wrong? Who can stop it? If the team can't answer all of those cleanly, the workflow is not ready to act autonomously.

The 20-example test is the practical version of that protocol. Take 20 historical cases where the AI would have run, run the outputs back through the system, and check whether a human can explain the logic, trust the source, and identify an owner for every case. The ones that fail that test point to exactly which gaps need to close before the workflow gets authority. The ones that pass are the evidence you bring to the stakeholder conversation about scaling.

Key takeaway: Answer 1 diagnostic question before scoping any AI initiative: what exact actions will the system take, and at what authority level? If the answer is summarize, rank, or draft, proceed with standard data hygiene. If the answer involves changing records, contacting customers, or influencing a revenue decision, run the full protocol: name the source of truth, assign the owner, document the approval boundary, and write the rollback plan before the workflow goes live.

The Most Common False Positives in AI Readiness Assessments

The combination that makes most ops teams feel AI-ready is also the combination that most reliably produces brittle deployments: a data warehouse, a CDP, a clean-looking dashboard, and a shiny new agent layered on top. Each of those is a real asset. Together, they are not AI readiness. They are ingredients.

What actually signals that a team can run AI workflows reliably is a substantially less exciting list. One clear system of record for the relevant motion. A documented process that the team actually follows. Named owners for each step. Defined exception handling for the edge cases outside normal parameters. Human validation at the points where the stakes are high. And narrow initial use cases with a blast radius small enough that a failure doesn't take the whole program down with it.

The hidden strengths test Jason applies to any team is a single uncomfortable question asked in a meeting with the relevant stakeholders. If nobody in the room can answer all 3 parts cleanly, that's the readiness gap, regardless of how sophisticated the tooling looks. The gap is organizational, not technical. A team that has been investing in the operational layer, the definitions, the routing logic, the exception handling, has more AI-ready infrastructure than most of them realize. A team with an impressive tech stack and no documented ownership is further behind than the stack implies.

As the cost of building on top of good models continues to drop, the operational layer becomes the primary differentiator in AI deployment quality. The teams that invested in boring, well-run systems before the AI tools arrived have a structural advantage that compounds. The ones that treated it as back-office maintenance rather than infrastructure are discovering that the gap is harder to close in production than it was to prevent.

Key takeaway: Run 3 questions in your next AI readiness meeting: if this workflow makes the wrong call tomorrow, who finds out first, who has authority to stop it, and how do you roll it back? Document the answers before the system goes live. If nobody can answer all 3, those are the readiness gaps to close first, not the items on the data quality report.

What Goes Wrong When Agentic AI Optimizes Directly on Warehouse Correlations

A GrowthLoop guest on an earlier episode had argued that letting AI agents loose on data warehouse data is a dangerous idea, because the warehouse reflects only what happened historically, with no information about what actually caused it. Jason Dobbs partly agrees. His version of the argument is narrower.

Unbounded agent autonomy is where the failure happens. The warehouse itself is a context layer, not the source of the risk. Teams that go from "here's our warehouse" to "here's an agent, act on any scenario" without defining the layer between those 2 things are setting up the same failure Jason described from Kumo's own deployment: a system making confident decisions that nobody actually authorized it to make, grounded in correlations the business never decided to treat as causal.

A product that correlates with high LTV in historical data is a different signal from the causes of high LTV. An agent optimizing on that correlation without authority limits or a human approval gate will confidently scale the wrong behavior. The same failure mode applies to any data source a model acts on without guardrails. The warehouse isn't special in this regard, and the argument for avoiding warehouse data misses the actual issue.

Jason's position, shaped by Kumo's own product thesis, is that structured warehouse data holds some of the richest relational context a business has. The patterns that live in a warehouse, who bought what, when, in combination with what else, at what point in the relationship, are signal that most AI tools can't access because they're designed for unstructured text rather than relational tables. The loss isn't in having warehouse data. It's in having it and not making it usable for decisions.

The policy boundary is where everything lands. A warehouse can produce a score, a prediction, a ranked list. That output feeds into a workflow where a human reviews the recommendation and decides what to do. That's prediction as context, and it's where Jason sees most of the value. Most teams don't have a data problem. They already have more signal than they think. What they often lack is a practical way to test whether the AI should advise, draft, or act — and a clear boundary defining which of those 3 the system is actually authorized for.

Key takeaway: Write down the authority boundary before giving any AI system permission to act on warehouse data. Define what the system can produce autonomously (a score, a ranked list, a recommendation) versus what requires human approval before any real-world action follows. That boundary is a business decision, not a technical setting, and it needs to be documented and revisited when the model's behavior changes.

How Relational Foundation Models Turn Warehouse Data into Explainable Predictions

The structural gap KumoRFM was built to close is the one Jason has been describing throughout the episode. Most enterprise AI tools are trained on unstructured text and can't natively process the relational tables that hold the richest business context in most organizations. KumoRFM connects directly to the warehouse — Snowflake, Databricks, Amazon, and others — and generates predictions from the relational structure itself.

The platform has been pre-trained on billions of relational patterns across thousands of datasets, which means teams don't need to train a model from scratch, build custom ML pipelines, or wait months for a data science team to stand up a predictive workflow. The use cases span fraud detection, churn prediction, ad placement, and demand forecasting: the kinds of mission-critical decision flows that typically require significant engineering investment and produce outputs with no explanation attached. KumoRFM generates predictions with the explainability Jason has been arguing for throughout the conversation, not just a score but an account of which data fields drove the outcome.

The broader thesis behind the platform is a claim about where the bottleneck in enterprise AI is going. The cost of training specialized models and the engineering effort required to build and maintain them are shrinking fast. The data engineering work of building a custom predictive model for a specific use case is already being automated in many contexts. What won't be automated is the operational context layer: the definitions, the routing logic, the authority boundaries, the exception handling. That's the work that determines whether a prediction turns into a reliable business outcome. It's also the work that marketing ops has always owned.

Key takeaway: Require explainability as a baseline when evaluating any predictive AI tool: which specific data fields drove each prediction, and how did they combine to produce the output? A platform that can't show source evidence for a score is producing a black box. Explainability is the minimum requirement for any predictive output that feeds a real business decision, because you cannot govern what you cannot audit.

When to Ship AI Before Your Data Is Ready and When to Fix the Foundation First

The ship-first argument is more serious than most ops practitioners want to acknowledge. The logic goes: data cleanup work has been deprioritized for years because it's not tied directly to revenue. The only thing that has ever changed that priority is a visible failure. Ship the AI, let the bad output become the business case, and use the failure to unlock the resourcing that the foundation work has never gotten on its own.

Jason doesn't dismiss this framing. He's lived on both sides of it. The ops team lives with the consequences of bad data and wants the foundation right before anything launches. The business side has a number to hit this quarter and cannot wait 6 months for a data architecture project to complete before the pipeline conversation can happen. Both of those positions are reasonable descriptions of real organizational pressures.

The resolution is not philosophical. It's a question of blast radius. The ship-first argument holds when the scope is small enough that the failure produces a lesson rather than a catastrophe. A single workflow, tested on historical examples, deployed with a human review gate, failing in a way that's recoverable and documentable: that's a defensible path to building the business case. An agentic system with broad authority acting on the full customer base with no approval path: that generates the kind of trust damage that takes years to rebuild.

The size of the organization matters too. A lean startup with a 2-person ops team and a queue of 200 backlogged projects faces a different calculation than a company with dedicated data engineering resources and months of runway to get the foundation right. The framework is the same in both cases: 1 workflow, bounded scope, historical validation, human oversight at the action boundary. The timeline for getting there varies considerably.

Key takeaway: Choose a blast radius that's survivable before deploying AI under business pressure. Pick 1 workflow with recoverable failure modes, run it with a human review gate at every action boundary, and use the first real-world runs to build the business case for the foundation work you haven't been able to get prioritized. That's the version of "ship first" that teaches rather than damages the program.

Why Selling the Bottleneck Gets More Internal Buy-In Than Selling the Strategy

Getting internal buy-in for AI readiness work runs into a specific and consistent problem: the full argument is large and abstract. You need shared definitions, trusted data access, named ownership, authority boundaries, evaluation paths, and rollback plans before any workflow can run with real authority. Ask for all of it at once and you are asking leadership to bet on a roadmap, not a result.

Jason's approach is to make the ask much smaller. Identify the specific bottleneck: the 1 process step causing the most friction, the 1 definition conflict producing the most unreliable outputs, the 1 ownership gap that keeps surfacing when something breaks. Quantify what it costs to leave that gap alone. Propose the smallest test that would confirm whether the fix works. Define the blast radius if the test fails.

At that scale, you're not asking anyone to believe in the whole program. You're asking them to agree that the specific problem is real and that the specific next step is reasonable. The difference in resistance is significant. And once the first test produces a result, trust compounds. The next ask lands easier because there's evidence from the last one. The multi-quarter foundation-building project becomes a series of small wins that reach the same destination without requiring a leap of faith at the start.

The reason this works consistently is structural. People don't resist AI readiness work because they disagree that clean data matters. They resist it because they've been in rooms where "we need to fix the data" has been said for years and nothing changed. Arriving with a specific bottleneck, a specific consequence, and a specific next step makes the request categorical. Leadership can evaluate a next step. They cannot evaluate a vision.

Key takeaway: Rewrite your next internal AI proposal around the bottleneck rather than the strategy. Identify the 1 specific process gap causing the most friction, quantify what it costs to leave it alone, propose the smallest test that would confirm whether your approach works, and define the blast radius if the test fails. At that scale, the request becomes a next step, not a vision, and next steps get approved.

What GTM Engineering Actually Means When AI Automates the Middle

GTM engineering is one of the most contested job titles in marketing ops right now. Some practitioners see it as a genuine evolution of the function. Others see it as a rebranding exercise for a role that hasn't changed much. Phil arrived with the skeptical read. Jason pushed back with specifics.

The way Jason runs the function at Kumo AI is precise. The team is extremely lean. Every problem starts with the same question: how do we solve this with AI? Agentic workflows have replaced tasks that would previously have required either a data engineer or a marketing ops person, often both. The output is the same: qualified pipeline, lead scoring, early-stage engagement. The mechanism is different. The machine now handles a large portion of the execution work that humans were doing before, and the humans supervise outcomes rather than producing them.

What that looks like in practice is a function that holds 2 skill sets that previously lived in separate teams. The first is the marketing automation and operations skill set: understanding lifecycle stages, routing logic, the commercial logic of when to act and how. The second is the data engineering skill set: understanding how to build and maintain the systems that produce the signals those decisions depend on. GTM engineers hold both. They can read a SQL query well enough to evaluate whether the data feeding a workflow is reliable. They understand the commercial context well enough to build guardrails that reflect actual business intent, not just technical constraints.

The strongest argument against the "RevOps rebrand" critique is what AI-first companies actually require from the function. When machines handle execution and humans supervise outcomes, the supervisor needs to understand both the technical architecture and the commercial logic governing the machine's behavior. That's a more demanding combination than either standalone role ever required. The job has changed. The title is trying to reflect that change, and the organizations that treat the 2 skill sets as permanently separate are going to be slower on every AI initiative that depends on both.

Key takeaway: Audit whether your ops and data functions share a working vocabulary. If your MOps team can't read a basic SQL query and your data team doesn't understand what a lifecycle stage is, you have the gap GTM engineering is designed to close. Identify 1 project that requires both functions, assign it a shared owner, and use it to build the cross-functional fluency you'll need to staff and oversee agentic workflows reliably.

How Jason Dobbs Decides What Deserves His Energy

Jason Dobbs rides electric skateboards at 50 to 60 miles an hour, e-foils in the ocean, snowboards, and free dives. He describes all of it without apparent anxiety, which probably tells you something about how he thinks about risk more generally.

His framework for deciding what to pursue, and when to stop, comes from the same mission-first orientation that shaped 7 years of intelligence work before any of the startup experience. The question Jason starts from is what his mission is today, and whether that mission is aligned with the life he's actually building. That's a different entry point than personal preference or mood, and it came from years in environments where the mission was the whole point.

That filter has a practical edge to it. Some seasons are hard. Building anything that matters comes with sacrifice, and Jason is not trying to avoid that. But there is a specific cost that signals the mission has gotten too expensive, and he names it precisely: when it starts to erode health, key relationships, or integrity. Those aren't negotiable. A mission steadily grinding down any 1 of them isn't worth the output it's producing, regardless of how meaningful the work appears on paper.

The question he applies is tripartite: does this matter? Is it mine to carry? Is the cost temporary or purposeful, as opposed to being called discipline when it's actually burnout? Projects that fail all 3 are easy to decline. Projects that pass all 3 can absorb hard seasons. The ones that pass 1 or 2 are where the real decision lives, and having the filter makes those calls faster and cleaner than trying to evaluate them without a framework.

Working in an industry accelerating faster than most people's ability to adapt means everything can feel urgent, high-stakes, and mission-critical at once. The value of a clarity filter isn't for the obvious cases. It's for the commitments that pass a surface inspection and fail a closer one: the projects that feel productive but are consuming attention without building toward anything that actually matters.

Key takeaway: Apply a 3-question filter before committing to any high-stakes project: does this matter, is it yours to carry, and is the cost temporary or purposeful? Projects that pass all 3 can absorb hard seasons without depleting the reserves that sustain everything else. Start applying it to the commitments already on your calendar before adding new ones.

What Jason Is Reading: Intelligence History, Mind-Opening Nonfiction, and Dune

Jason's reading is organized around the same themes that shape his professional thinking: how humans process information under uncertainty, how intelligence tradecraft works at the operational level, and what fiction can tell you about the limits of prediction and control.

The nonfiction category runs toward the psychology of cognition and bias, books about how unconscious assumptions govern decision-making and how to build habits of inquiry that surface the blind spots most people carry without examining them. The intelligence category goes deep: podcasts and books on CIA operations, analytical tradecraft, the mechanics of building reliable assessments from unreliable information. These aren't hobby reads. They're the background literature for the problem Jason has been working on for 20 years.

The fiction pick is Dune, and the reason is specific. His recommendation is for the argument underneath the plot: pattern recognition generates the illusion of control without actually giving you any. The Bene Gesserit can predict with extraordinary precision. Paul Atreides can see further than any human has seen before. Both of them discover, across several thousand pages, that seeing a pattern clearly and having authority over its outcome are completely different things. A product that correlates with high LTV and a lever that causes high LTV are not the same thing. A prediction and a policy are not the same thing. Dune makes that distinction visceral in a way that no analytics framework manages.

The reading list turns out to be a coherent research program: how do humans build trustworthy assessments under uncertainty, what happens when they're wrong, and what the actual limits of prediction are once you've built the best possible model of the future you can manage. That's the same research program as the rest of this episode. It just runs a few hundred years further out.

Key takeaway: Read Dune if you work in AI. The book's central argument, that pattern recognition generates the illusion of control without giving you any, maps directly to every agentic workflow question in martech right now. Start with the first book. The distinction between predicting an outcome and governing one is the clearest available warning about the gap between a model that's confident and a system that's trustworthy.

Episode Recap

Jason Dobbs makes 1 central argument and defends it from every angle across 10 chapters: AI readiness is a context engineering problem. Most teams that struggle with AI deployment are running good models on top of undefined terms, unresolved ownership questions, and workflows with no guardrails on what the system can do autonomously. The failure mode isn't obvious hallucinations. It's believable nonsense, outputs that look operational until someone asks the follow-up question and the logic falls apart. He learned this from his own greenlit deployment at Kumo, and the framework he built from that failure is the backbone of the episode.

The tactical thread connecting the chapters is the minimum viable readiness framework: 5 specific requirements a workflow needs before any AI system gets real authority. Shared definitions, so the AI isn't scaling a disagreement the business hasn't resolved. Trusted access, so the system can actually reach the right data with enough freshness. Named ownership, so a specific human is accountable when something goes wrong. Authority boundaries, so the system knows what it can do autonomously versus what needs a human sign-off. And an eval path, so there's a way to test outputs before the workflow runs at scale and a rollback plan if it doesn't hold. Score any workflow across those 5 criteria and you have a faster and more honest readiness assessment than any strategy presentation can produce.

The bigger-picture implication Jason draws out across several chapters is about the marketing ops function itself. As AI systems take over execution, the teams closest to the business logic governing those systems become more important. Marketing ops is one of those teams. The definitions, the routing logic, the exception handling, the quality checks: these are the operational layer that determines whether a model produces business value or amplifies existing problems. The convergence of that ops work with data engineering is what Jason calls GTM engineering, and he makes the case that it's a genuine evolution of the function rather than a rebrand. The organizations that treat these skill sets as permanently separate will be slower on every AI initiative that depends on both.

2 tensions in this episode are worth naming. Jason is making the argument for careful AI readiness while leading marketing at a company that sells AI infrastructure built on warehouse data. He acknowledges the conflict directly but doesn't fully resolve it. His argument that "the warehouse is a context layer" and Kumo's argument that "you should buy our platform to act on your warehouse" sit close enough together that the line between thesis and pitch is sometimes blurry. The second tension is the ship-first argument. Jason's answer is "start with 1 bounded workflow," which is right, but he's also honest that organizations under real revenue pressure don't always control the pace of their AI deployment. The gap between the right way to build this and the way most organizations will actually build it doesn't close just by being named.

You can find Jason on LinkedIn, where he writes on GTM engineering, AI data readiness, and the ops-to-data-engineering convergence reshaping revenue teams.

What is Humans of Martech?

Future-proofing the humans behind the tech. Follow Phil Gamache and Darrell Alfonso on their mission to help future-proof the humans behind the tech and have successful careers in the constantly expanding universe of martech.

[00:00:00] Phil: Garbage in, garbage out. AI is only as good as the data. You kind of feed it like everyone says, you need to fix your data. almost no one talks about what it actually means in practice to fix your data

[00:00:09] Jason: not the best label. it kind of makes this effort sound like some mythic authoritarian quest for the Holy Grail. Uh, you know, the issue is that teams jump from, Hey, here's a big pile of our data to, let's throw this agent on top that should now be able to like, act on any scenario without defining that layer in between.

[00:00:28] Darrell: what's the list of non-negotiables? You have to start with upfront.

[00:00:31] Jason: First I think. What's very important? Shared definitions, Do we mean the same things by what is pipeline or what's a qualified lead second, trusted access. can the system actually see the right records with the right joins, third, I think named ownership. you know when something goes wrong or needs to be fixed it needs to be a person or maybe a. Few named people, fourth, authority boundaries.

[00:00:51] what's the system allowed to do on its own and then fifth is you need a way to test whether the output's actually good enough.

[00:00:58] ​

[00:01:24] In This Episode
---

[00:01:24] Phil: What's up everyone? Today we have the pleasure of sitting down with Jason Dobbs, head of marketing and GTM Engineering at Kumo Before Kumo, Jason's held marketing ops, rev ops and lifecycle roles at big brands like Logitech, Seagate, apple, and Google. In this conversation, we cover the five and non-negotiables for AI readiness in marketing ops. When to ship AI before your data is ready Why marketing Ops is the context architect And we'll also get Jason's take on what the heck GTM Engineering even means. All that and a bunch more stuff after a quick word from two of our awesome partners.

[00:01:57] Sponsor: MoEngage
---

[00:01:57] ​

[00:02:54] Sponsor: Knak
---

[00:02:54] ​

[00:04:00] Phil: Jason, thank you so much for your time today, sir. Really excited to chat.

[00:04:04] Jason: I am so pumped to be here. Uh, really love, you know, the work that you know, you Phil, and you Darrell, are are doing in the community. I've been watching from the sidelines for a long time, um, you know, cheering you and, and everyone else on. Um, and yeah, like I said, so excited to to be on the show today.

[00:04:22] Phil: I really appreciate that Jason means a lot coming from you. Uh, so yeah, like we were chatting uh, a lot before, uh, you kinda came on here about what's the main topic gonna be here. And we kinda landed on this idea of AI data readiness. And

[00:04:35] 1 — How Undefined Data Definitions Make AI Confidently Wrong
---

[00:04:35] Phil: one thing a lot of marketing ops people talk about when they come on the show, as soon as we mention AI is.

[00:04:41] Garbage in, garbage out. AI is only as good as the data. You kind of feed it like everyone says, you need to fix your data. We've beaten that horse to death. Uh, almost no one talks about like what it actually means in practice to fix your data. Like who owns it, where do you start, how much is enough before you move to.

[00:04:57] Prevent AI and agents from, uh, you know, just [00:05:00] spitting out chaos in, in your system. Maybe we can start with that like chaos element, because you said before we recorded that you learned this the hard way at your current startup. So anyone that's using LMS on a regular basis, we've all had our first encounter with an LLM being confidently wrong.

[00:05:15] And at Kumo you said that you greenlit ent predictive workflows before the data was ready for it. Can you take us back to that moment, Jason? Maybe we can start there.

[00:05:24] Jason: Yeah, a hundred percent. And you know, I love the example of, of leading, um, with failure. Uh, you know, because I know, you know, for, for stubborn. People like myself anyways, uh, failure is, is unfortunately the best, uh, and quickest way to learn. Um, you know, going back to to, to some of the, you know, we talked about some of our personal interests, um, you know, kind of over the show, you know, I ride these high speed, you know.

[00:05:48] Um, F1 skateboards ago, 50, 60 miles an hour. And yeah, you know, I've crashed or, or fell off, fell off a, a few times, but, you know, I can tell you I've never crashed or, or fallen off the same way twice. [00:06:00] Uh, so I try to, to take that same philosophy through the rest, the rest of kind of what we're talking about here.

[00:06:06] Uh, you know, and especially, you know, the age of AI that we're in, you know, everything's moving so fast, there's so much. Um, testing going on, new products coming out, new models coming out, uh, almost every week. Uh, you know, it's a constant, uh, process to go through that. Um, so. My own experience there, you know, talking about green lighting, kind of agentic, um, flows that weren't quite ready.

[00:06:29] You know, it can essentially be dangerous and, you know, what made it dangerous wasn't really like the obvious hallucination that we all see or used to with lms. Obvious hallucinations, easy. Um, you kind of reject it, you move on. I mean, I think what, what we were seeing looked polished enough to be operational.

[00:06:45] Um, at first glance, you know, the scores looked precise, the summary sounded coherent. Uh, the recommendations felt data backed. But the moment you ask, like the simple follow up questions, like, uh, and that's why explainability is so important. Like, okay, [00:07:00] well why did you choose this account? Or, um, why is that happening now?

[00:07:05] Or what data drove this decision? Um, you know, the logic started to thin out. So that's really the layer, the, that you need to, to be able to, to dig into. Um, so, you know, the lesson for me wasn't like the data was bad or the warehouse was bad, or the model was bad. Uh, what's, what, what was wrong is we were trying to automate ambiguity.

[00:07:25] Um, you were, we were asking a AI to solve for confusion that we hadn't yet ourselves solved for, uh, internally. Um, and, you know, and once you do that, you kind of enter the danger zone because, you know, the, the failure is essentially believable, nonsense. Uh, and that, and that's dangerous because people trust it.

[00:07:43] Um, if you, if you don't know what to look to look out for, so you know what the top of me is, you know, trusted data, shared definitions. Guardrails, uh, workflow ownership, that's not the boring back of office work. Um, especially, you know, that's a lot of the, the lifeblood, uh, the, [00:08:00] you know, m ops folks, ops folks bring the table.

[00:08:03] That is the product. Uh, you know, once the models are good and you know, the data's good enough, like those are the things that matter. Um, and analytics at the end of the day only matter, you know, if they drive a real life decision

[00:08:15] Darrell: Right.

[00:08:15] Jason: and impact.

[00:08:16] Darrell: Really good insight there. Um,

[00:08:18] 2 — Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck
---

[00:08:18] Darrell: Jason, I wanted to ask you, you said in your pre-interview we were trying to automate ambiguity. We were asking AI to solve for confusion that we hadn't solved operationally. So, um, I wanted to ask you like, who actually does the data fixing on a team? Like, what's their roles and what does act, what, what does fix the data really mean?

[00:08:38] Jason: Yeah, great question. You know, I think. The fix the data may, may be, uh, not the best label. Uh, you know, it kind of, it kind of makes this effort sound like some mythic authoritarian quest for the Holy Grail. Uh, you know, it's the one quest we all seek out for, but clever never quite actually seem to [00:09:00] make it to the end.

[00:09:01] Uh, you know, regardless of, of kind of how good we are. Uh, you know, I think the reality is that. The warehouse is often where the richest relational signal already lives, or, you know, breakout kind of wherever. I mean, it's different for different organizations or wherever your core, uh, data sets live. Um, so the, you know, the issue isn't usually that the business has zero signal.

[00:09:22] Uh, I think the issue is that teams jump from, Hey, here's a big pile of our data to, uh, let's throw this agent on top that should now be able to like, act on any scenario without defining that layer in between. Right. So I think it's not really like how do we clean everything? Um, it's more like, what minimum context and control does a workflow actually need to become liable?

[00:09:45] So that includes, you know, things like what are the definitions, you know, what is the source of truth? Uh, what's the freshness of the data? What's, what is the permission that we're actually giving for this? Um, you know, defining those thresholds and then like figuring out like where [00:10:00] does human judgment still belong?

[00:10:01] Like, uh, in all this. So, you know, we talked a little bit about, you know, how prompt engineering can make something smart. I think contact engineering, context engineering is really what makes it dependable.

[00:10:13] Phil: Yeah, the, the context engineering part is, uh, like the, the hottest buzzword. Um, like, uh, Scott Brinker wrote a whole report on. On context engineering. And when we were trying to figure out like cool questions to ask you about that, uh, one thing that popped up in your job history is that you spent seven years as an air force intelligence officer before you went into tech, and some of your work included the president's daily intelligence briefing.

[00:10:40] And I had this crazy idea about like, Hey, why don't we ask Jason about. This job, like how it's probably one of the highest stakes content context assembly jobs in the world. Um, take us back to that time, like how much of what you're arguing about AI readiness and data quality is actually intelligence trade crafted with [00:11:00] like a different label.

[00:11:01] We chat about that for a bit.

[00:11:02] Jason: Yeah, you know, I actually love this example because I think it has, at least for me personally, formed, um, a lot of how I like tackle even, you know, business challenges. Uh, and, you know, we could probably nerd out and make an entire episode about. Uh, kind of the correlations between that also. But, you know, a lot of, a lot of what we are talking about is intelligence trade craft with a different system.

[00:11:25] I mean, an intelligence just like in, you know, operations, like you're almost never working with perfect information. Uh, you're building a decision picture from incomplete often, you know, contradictory, time sensitive inputs. So the real skill, not really collecting more information, it's knowing what to trust, what to discount, uh, what stale and you know, where uncertainties high enough that we need to invest more human cycles.

[00:11:53] Um, so in the intelligence world, just like business world, we have a lot of different data sources that we pull in. We call them, [00:12:00] uh, you know, intelligence collection sources, things like. Um, human intelligence, signals intelligence, geo imagery, intelligence, uh, measurement signature intelligence, open source intelligence.

[00:12:12] Uh, so, you know, that's, that's how I think about AI readiness too. Uh, on the business side, we have, you know, our CRM data, our product data, our, our engagement history, our all the support history, like tons and tons of these different data sources, you know, that by themselves don't really mean much, but you start to build that in, uh, you know, you, you bring all of the different, sort of connect the dots and bring all the breadcrumbs together.

[00:12:33] Um, and, you know, essentially that's, those are just enterprise versions of intelligent source streams also. So, you know, the job's the same. Assemble enough trustworthy context to make a good decision without fooling yourself. Yeah.

[00:12:47] Phil: We, we won't ask you a political question, uh, with the, uh, the, the climate today. We can keep that for another

[00:12:53] Jason: Yeah. No, a hundred percent. Yeah. Hmm.

[00:12:56] Darrell: So, um, we've been, uh,

[00:12:59] 3 — The Five Non-Negotiables for AI Readiness in Marketing Ops
---

[00:12:59] Darrell: so there's this concept of minimal viable readiness and, you know, I think that that's what a lot of folks are trying to achieve at minimum. Before layering on AI and agents, what do you think are the bare minimum requirements for you to feel like, okay, our d our data's in a good place, might not be perfect.

[00:13:18] Um, it'll probably never be perfect, but what's the list of non-negotiables? You have to start with upfront.

[00:13:24] Jason: Are you sure you don't wanna undertake the quest for the holy Grail, Darryl? Like it could be perfect.

[00:13:29] No, but actually I love this, uh, this term minimal viable readiness. I feel like we just need to put a stamp on this right now.

[00:13:36] Phil: Yeah, I actually didn't Google to see if this was like a

[00:13:38] thing or

[00:13:39] Jason: Phil. We'll let you take the credit for this one, man. Yeah, we'll just, we'll go ahead and put a trademark on it and move forward.

[00:13:44] Uh, but no, it's a great question. So, uh, you know, first I think. What's very important? Shared definitions, especially like, okay, it sells marketing and rev ops talking about the same thing. Do we mean the same things by what is pipeline or what's a qualified lead [00:14:00] or, uh, you know, things like that. So that's, you know, I talked a little bit about automating ambiguity.

[00:14:04] Like we were asking AI to solve for processes that we hadn't yet like defined ourselves. So this is where you can kind of get wrong in this. Uh, and if you don't have those shared definitions, you know, the AI's just gonna scale that disagreement essentially. Um, second, trusted access. So not. Like we technically have the table or the pile of data, but can the system actually see the right records with the right joins, with enough freshness to make the decision that it needs to for that task.

[00:14:33] Um, third, I think named ownership. Um, so you know when something goes wrong or needs to be fixed or like there's gotta be a human owner, not the model or the data team. Uh, it needs to be a person or, or maybe a. Few named people, um, look for a shared type responsibility for sure. Uh, fourth, you know, I'd say authority boundaries.

[00:14:57] So what's the system allowed to do on its own [00:15:00] and what still needs review or approval, um, from humans like us? Uh, and then fifth is really, you know, an eval path. So before anything gets real authority, you need a way to test whether the output's actually good enough. And, uh, you know what to do about that and, and reverse that if it fails.

[00:15:17] So that's really the heart of it. Uh, not perfect data, you know, trustworthy context plus a clear approval path. So, you know, I'd say for teams wanting to tackle this tomorrow, it's like, take one workflow, you know, score it red, yellow, or green on those five items, and that'll tell you faster than any strategy deck, whether you're actually ready.

[00:15:38] Darrell: Awesome. Awesome. No good insight there, Jason. Um, so

[00:15:42] 4 — Why Marketing Ops Is the Context Architect in an AI-First GTM Stack
---

[00:15:42] Darrell: let's move over to a topic. That's close to my heart, which is marketing ops. Um, I'm fascinated by the overlap between data engineers and MarTech and ops and, you know, it's, it's, uh, it's kind of like a blurry line between who does what. Um, because some of the work that we do is, is pretty technical and does require, you know, typically coding.

[00:16:03] Um, but when it comes to things like system administration. You know, you might not need a computer science degree to, to fix some of those problems. You know, it's more like, kind of like configuration. Um, and I wonder how you think about who tackles what problems when it comes to data. Um, is, is, is ops sort of maybe managing the project and you're looping in an engineer?

[00:16:27] Or how, how do you think about that? Maybe riff on that a little bit for us.

[00:16:30] Jason: Yeah, a hundred percent. Uh, and I think. You know, super important question, and I'm passionate for me as well because I came up in the lifeblood of, of ops. Uh, you know, we talked a little bit about my intelligence background, but my first career. So many moons ago. And, and tech was, uh, you know, on an ops team as a Salesforce administrator, like, uh, like that, that was kind of the lifeblood of coming up and then growing into becoming a data scientist and then into kind of business leadership and, and engineering side.[00:17:00]

[00:17:00] Um, and I think, you know, that's super important, uh, because especially with how we see. Just the, you know, how AI has overtaken the, uh, the ecosystem and how roles are shifting, especially between data engineering ops. Uh, you know, how we need to essentially think about that, uh, and scale up as, as individuals to get ready for kind of the, the next evolution.

[00:17:23] Um, that we're going through. So the role itself is, is getting more important, not less. You know, as like, as these human roles shift towards supervising outcomes, uh, as delegated systems become more common, I think in practice marketing and ops becomes the, the business side context architect. Um, the team closest.

[00:17:41] I mean, they are the team closest to the definitions, to the routing logic, to the handoffs, to the exceptions, and, you know, real world process integrity. Um, so, you know, talking to that, I wouldn't start with like a giant backlog of every bad field, every sync issue, every message table in the company. I think that's how teams get [00:18:00] stuck, uh, become very overwhelming.

[00:18:02] And start with one decision loop, right? Like map the loop end to end. Um, what source systems fed it, you know, what signal or prediction gets produced, uh, where it lands, you know, what action follows and who can stop it if confidence is low, you know, so that really kind of falls in line with some of the, uh, rest of the, the things we've been talking about.

[00:18:22] So that's where marketing obstacle comes incredibly important in my mind. You know, um. They're the team closest, closest to that. Uh, and, you know, in the real world process, that that's what determines whether a, a model actually creates a business value. So, you know, I wouldn't map that entire customer universe first.

[00:18:41] Like I said, start with one workflow, prove it matters, use it as a pattern and a blueprint, um, to kind of move on to the next one.

[00:18:48] Phil: Yeah, it's a cool call out there. I feel like, you know, fixing the data in the marketing ops world, we think of the CRM and the marketing automation platform, the customer engagement platform, depending if you're [00:19:00] B2B or B2C, and those are like systems that we administrate. We have access to them like it, it's kind of on us, but more and more orgs are moving to the data warehouse as the source of truth.

[00:19:11] And so these tools are kind of sitting on top of something that we don't necessarily have the keys to. And that's like the question about the data engineering role versus the marketing ops role. So I'm curious to ask you like, you know, in that world where maybe, you know, there is a data warehouse in the company, uh, hopefully there is.

[00:19:30] Um, and there's a lot of like the fixing the data things that fall out of our world in, in the marketing ops world. Um, like what are your thoughts on, you know, sometimes there is still a lot of stuff that marketing ops and MarTech folks can do themselves without having to. Submit a ticket with the data team and constantly have to like, bug the data team.

[00:19:50] Or sometimes like it falls under the product team. Um, you know, like marketing ops can't necessarily rebuild the warehouse or create new tables all the time on some teams, you know, we can, [00:20:00] 'cause, you know, there's a dedicated data engineer that is servicing the marketing ops team and sometimes like a blend of the two.

[00:20:06] Um, but you know, we're, we're not helpless in, in that world. Maybe like what can someone in this role marketing ops role actually fix, um, you know, without the data team kind of on their own this week, and where exactly does the line fall between, like where they need to go get a ticket and get that prioritized?

[00:20:25] So I kind of like. I came up with like three big areas of things that are like maybe higher level of, of things to, to go and fix this week or, or whatever. I'm curious, like if, if there's any in there that, that are missing, you got a chance to kind of like look at this first, but the first thing that comes up to me is obviously like de-duplication.

[00:20:43] Like we talk about this all the time. This is the most visible one that comes up, especially when you're like going through audit logs or just like. Quick searches and you find like three people with Darrell at Daryl Alfonso comes up seven times in the database. Like, what the heck are we doing here?

[00:20:58] Like, [00:21:00] ddu deduplication is, it's ours. Like it's, it's on us. Um, there's a lot of tools out there that help you. That you kinda like slap on third party tools. It duly clouding go whatever. Um, there even like a lot of maps have like a native D dupe feature. It's not glamorous work, but you know, that's one of the areas.

[00:21:16] The other one was like basic ID resolution. This one is kinda shared between the data team, the marketing ops team, because Id res between product and, you know, pre identification on the website. Like it, it kind of crosses paths with a lot of different folks. Sometimes it's us, especially like on the B2B side, like enrichment tools can kinda come in and help out a lot with that.

[00:21:40] And the third one I had is like the bane of every marketing automation person's existence. Like the sync issues between the CRM and the marketing, uh, automation platform. You know, there's a lot of configuration problems that aren't necessarily architectural problems that don't require a data eng team.

[00:21:57] Wrong field mappings, like seek [00:22:00] filters, um, bidirectional conflicts, all that stuff. What, what are your thoughts on those three? Am I missing any, just riff on that for bit.

[00:22:06] Jason: Yeah, mostly, you know, uh, I'm just reliving the stuff of nightmares and, um.

[00:22:12] You, you know, going through PTSD and trauma right now. Yeah. As you know, as someone who came up in the trenches of, of ops, uh, you know, I've lived that life for the last 15 years. Yeah, a hundred percent. But you know, my answer with that be is marketing ops is way more powerful than people think.

[00:22:29] Uh, you can fix a lot this week without a data engineer. Um, you know, moping ops can absolutely do real readiness work without waiting for huge data engineering project. Um, you know, like we talked about, improve duplication, enrichment rules, uh, field governance, sync mappings, routing, logic, suppression rules, lifecycle stages, qa, the, the real life systems that, that people are actually using.

[00:22:54] Um, you know of sure, maybe a lot of that work is not glamorous. Uh, but it's the lifeblood [00:23:00] actually of what a I sees, uh, and what the business trusts that we're in the background. And that's a lot of, like we talked about. Once the model's good, um, like those are the things that are actually gonna impact, like how successful, um, are these things, uh, within your organization.

[00:23:16] So, you know, where the line usually shifts to data engineering more, you know, the things, the, the other things, you know, the core IDs, warehouse modeling event schemas, you know, semantic consistency across systems, real time freshness or you know, of course those are some of the things that, you know, maybe, you know, there's a lot of things that, that, that, so like, you know, I think that's one.

[00:23:36] Trap I devoid is, you know, more tool access, um, with more readiness. You know, exposing more systems to AI, doesn't necessarily make the workflow trustworthy, you know, better definition, cleaner handoffs, clear controls, like a lot of the things we're talking about that MOPS has direct impact, um, and command and control, uh, too.

[00:23:54] So, you know, I think, you know, people who wanna. Kind of get a, get a [00:24:00] fresh start at that and take a look. Like, do something like make a two column list, like called Ops can fix this now. Uh, and the second list called needs Data engineering. You know, you put dedupe enrichment Sync, logic, field Governance, routing Rules in the first column, all the other shit goes in the other one.

[00:24:16] And then you kind of prioritize and, and see like where to go from there.

[00:24:21] Phil: I love it. Yeah, it's, it's a good, good first step to, to take for sure. Yeah. It's, it's not glamorous work. Um, but, you know, may, maybe earlier in my career, I, I was excited to do it because no one else was excited to do it. And it is important work, like you said, because, you know, like AI is, is only as good as, you know, fixing some of that foundational work.

[00:24:41] And part of that is not. Glamorous stuff. Someone's gotta do it if you want the context to be better. Um, but the kind of related to that, Jason, like,

[00:24:50] 5 — Which Data Problems Block AI Deployment and Which You Can Ignore
---

[00:24:50] Phil: I think a lot of operators are wondering like, what can I ignore for now? Because like maybe they're starting that list and it's actually a pretty long list.

[00:24:59] Even the stuff [00:25:00] that doesn't require data engineering is stuff that's never been prioritized. It's fallen through the cracks because it's not. Directly tied to revenue and the company wants to, you know, quick wins and it's never been one of the quick wins ones. Um, so like. You know, if the answer is like, clean everything, no one's ever gonna start doing that.

[00:25:20] So like where do you draw that line? Like what data problems are ugly but kind of tolerable at, at, at first, like tolerable at first? Like, and and which ones would you say are like not, uh, are disqualifying them? Like, I guess what I'm asking is like there's a lot of readiness work that becomes abstract, like dashboards, governance docs, architecture diagrams.

[00:25:43] If you had to like make this tangible for a team, like what are the first few checks you would run to determine whether they're actually ready enough to do some agentic stuff? Like where does that diagnostic kinda look like for you?

[00:25:56] Jason: Yeah, I, I love that question actually. And. So I think the [00:26:00] first thing, um, I would ask is not necessarily like how clean is the data, I would say, you know, what authority are we delegating and, and what's needed to actually be successful, um, within this workflow or process or whatever. So, you know, if the system is summarizing through things like summarizing, ranking, drafting, you know, we can tolerate more mess.

[00:26:20] Um. don't have to be as strict there, you know, spin cycles on that. You know, if it's changing records, controlling spend, contacting customers on our behalf, making decisions that impact revenue, then yeah, the bar jumps pretty fast, right? Um, so you can, you can ignore some ugliness at first, like, um, you know, messy, free, messy pretax, some like missing non-critical elements.

[00:26:46] Um, sure. Like you talked about, we talked a little bit about duplicates, you know, some low stakes, duplicates. I don't know if anyone's ever like, eradicated 100% of all, uh, things like duplicate records [00:27:00] for some reason in the year here we are in 2026 and we're still plagued by this. I know there's a lot of tools out there that make it a lot easier, but, um, so, you know, I think, but when you, when you can't ignore, you know, undefined business terms, uh, broken, you know.

[00:27:16] Issue resolution still or unknown freshness on like that decision critical data that ai, uh, needs to make those decisions, like unclear approval paths, like, and then, and then no way to like, turn things off or, or wind it back, like if, if something's going wrong in that aspect. So I think my diagnostics for that's pretty simple.

[00:27:34] Like, uh, what exact actions AI gonna take, you know, what fields, uh, drive that action. Can a human reproduce the answer from source symptoms if needed? Like I talked about getting that extra layer down, not just accepting an answer that seems believable, blah, blah, but like, how did you actually, like, where did it come from?

[00:27:54] You know, what's the explainability behind that? Um, you know, that [00:28:00] what kind of threshold matters, um, for, for getting to a good outcome there? What happens if it's wrong and you know who can stop it? So, you know, I think if teams are looking for like a quick exercise, like how do I actually implement this tomorrow?

[00:28:14] Like, take 20 of your historical examples that you have. Workflows like if, if a, uh, run 'em through, you know, if a human can't explain the output, trust it, or identify the owner, then the system doesn't get, you know, more authority to move on yet.

[00:28:29] Sponsor: GrowthLoop
---

[00:28:29] ​

[00:29:32] Sponsor: AttributionApp
---

[00:29:32] ​

[00:30:34] Darrell: let's talk a little bit about Fal, false positives. What are common, like most common false positives that you see where a team thinks they're AI ready Because they have things like a warehouse, A-A-C-D-P, or cleaned up dashboard, but then underneath that the foundation is kind of actually not ready.

[00:30:52] It's too shaky for agents to actually perform well.

[00:30:56] Jason: Yeah. Uh, I think it's a, a fair question, you know, and I think you've had [00:31:00] some other, uh, guests, you know, on the show have had opinions about that. Um, uh, as well, um, a lot of, a lot of great things to unpack there. So I, you know, I think I'd slightly reframe the warehouse question. Um, just being selfishly where I sit, um, you know, I'd say, you know.

[00:31:19] I wouldn't say having that is a false positive. You know, where I sit at Kumo, I think the warehouse is actually a, a hidden strength, um, because it concentrates, you know, the richest relational context in the business. Um, so our, you know, our own products connect around directly connecting warehouse, you know, generating, uh, predictions, you know, explainable outcomes from that relational data structure and pushing those.

[00:31:42] Um, you know, into, into workflows, like I said, with explainability. So, you know, the false positive thinking like warehouse, CDP, clean dashboard plus shiny agent equals uh, readiness, right? I mean, those are ingredients. Those are ingredients at the end of the day, right? So, you know, [00:32:00] what gives me confidence is, is actually a much less, uh, glamorous, um, kind of viewpoint.

[00:32:05] You know, one clear system of record, you know, for the motion documented process named owners. Defined exception handling human validation where, where stakes are high, uh, and narrow use cases with, you know, uh, a bounded blast radius, uh, you know, in case something goes wrong there. Uh, so, you know, at the end of the day, I trust a boring well run system more than a Franken stack.

[00:32:28] Um, so yeah, that's, that's kind of, you know, where I would land on that.

[00:32:33] Darrell: Yeah, it's like simplicity, I think. Um, and not like too complicated processes because I was also gonna ask like the converse of the question, which are like, what are some hidden strengths that a tool, uh, that a team may have that make them more ready or maybe like low hanging fruit or signs that a team can really run fast with, with, um, ai.

[00:32:54] Anything you can think of there that you've seen?

[00:32:57] Jason: Um, yeah, I think I, you could ask one [00:33:00] uncomfortable question in your next meeting, you know, like, um, is this AI workflow, like if it makes the call wrong, call tomorrow. Like, who finds out first? Who decides like, how do we stop it? Like if nobody can answer, that's your readiness gap. Um, so there are tons of like hidden strengths and it's like really a lot of the things that we, we talk about throughout this episode, uh, all the things that MOPS is bringing to the table that were all like. Excellent at, uh, that's the core, like lifeblood of, like we talked about, not model creation. Like eventually we're gonna get to the point we already are at the point where like there aren't gonna be teams, huge teams of data engineers needed anymore to build like all these different models. There's no more training that's gonna be needed.

[00:33:43] Like we already have these, like pretty much one size fits all models or fine tuned models for specific use cases they've been trained on like. Millions of rows of synthetic data. Um, so that whole like needing the data [00:34:00] engineer and the whole team and six months to build a model for this one like use case, like that's gonna go away pretty fast, honestly.

[00:34:07] Um, so what the strengths are is really a lot of these things I were talking about that Miles Springs to the table is once the model's good, like what are the other things that are needed to actually like execute this?

[00:34:19] Phil: I love it. Jason, you talked a lot about the data warehouse throughout the conversation today, and

[00:34:24] 6 — What Goes Wrong When Agentic AI Optimizes Directly on Warehouse Correlations
---

[00:34:24] Phil: there's kinda like this growing trend of letting agentic AI kinda loose on the company's data warehouse. Um, I had a guest on, uh, from Growth Loop that kind of like called this a. Terrible idea. Uh, he said that since a warehouse is really only reflecting a brand's current status quo, which may have nothing to do with causal relationships, what are your thoughts on the risk of accelerating negative dynamics, like aggressively prompting a product that correlates with high LDV, but doesn't actually cause it?

[00:34:56] Like, what are your thoughts about just letting agentic AI loose on the warehouse? I.[00:35:00]

[00:35:00] Jason: Yeah, I have a, you know, I have a unique viewpoint on that as well. I'm happy to share. You know, I, I think I'd partly agree with the warning, but I'd narrow it. You know, the warehouse isn't the problem. I think, um, unbounded autonomy is, like we talked a little bit earlier, like, you know when teams go from like, oh, here's a big pile of data, like AKA, our warehouse, and here's, and here's an agent, and we're just gonna throw it on top and expect it to like. Like, no, the answer answer every possible, like, use case under the sun. Right. So, you know, I think selfishly I have a, a unique viewpoint just because of where I'm at at Kuo. You know, like I talked about our whole like. Uh, thesis is essentially aru, the structured relational data warehouse is oftentimes the highest signal context in the business.

[00:35:46] Um, you know, so we're built to connect to that turn relational context into, you know, real life like kind of business outcomes and, and push those into operational workflows, explainability. So overall the warehouse is, in my opinion, like [00:36:00] a context layer. Um, I think where I agree with the critique you talked about is.

[00:36:05] Uh, you know, a warehouse is a record of what happened. It's not necessarily a rule book for what an agent should do next. So, uh, you know, if you let a generic agent optimize directly on historical correlations with unbound authority, yeah, you can absolutely scale the wrong behavior. Uh, a product that correlates with high LTV does not necessarily cause ILTV, um, you know, so my view, I guess, you know, the warehouse is great context layer.

[00:36:32] You know, systems like, you know, where I sit, what we work on, you know, can make it a very strong, uh, next layer. Um, but you know, prediction's not policy. So once you cross into that action, like you still need guardrails, business rules, approvals, evidence to six is actually like driving business income. Um, you know, overall, like if I had to compress, you know, everything we've talked about today into like one idea, I think it'd be this like.

[00:36:59] Most teams [00:37:00] don't have a data problem. You know, they already have more signal, uh, than they think. Uh, what they often lack, you know, are, are the things that we just talked about. Um, and a practical way to test whether, you know, AI should advise draft act. I think that's really what minimum viable readiness is really about.

[00:37:17] So, you know, if you wanted to give like one concrete thing listeners could actually use tomorrow, um, you know, choose one workflow, not 10. You know, write down the exact decision that AI's informing list the five fields or signals driving that decision. You know, name the, the, the source of truth, the owner, the approval boundary.

[00:37:39] Run it on historical examples that you, that you already, you know, have confidence in before giving an authority. Like, that's it. Like there's no, uh, if there's no owner, no source of truth, no rollback, pat, then it's not ready.

[00:37:53] Darrell: Yep. Just the fundamentals. I love like the emphasis on first party data. Two, which is great, and I think it [00:38:00] kind of leads into this question that I have that I wanted to ask. So you are at Kumo, which exists because structured warehouse data is the highest signal context available. And your whole argument, or the main point is that most companies fail to use it properly.

[00:38:16] What, what does that mean? Like most companies fail to use that properly and how do you think about that at Kumo and like what, what does. Your solution due to like make this better.

[00:38:32] Jason: Yeah. Yeah, it's a, it's a good point. So, you know, at Kuo we. We've built, uh, what we call Kumar fm, uh, which is the world's first relational foundation model. So you can think of that like chat GBT, but for structured data. Um, so that's built, you know, connecting directly to your, to your warehouse data wherever that lives, whether that's, you know, snowflake, Databricks, Amazon, like wherever.

[00:38:56] Um, and, you know, generating, you know, predictions from [00:39:00] relational structure and pushing those into workflows with, with the explainability that we talked about. So it's all the common things that, you know, we're working on as, uh, actually there's like so many use cases. Like, I'm not gonna get into like a whole customer testimonials section.

[00:39:14] I, I don't wanna turn this into like a, a plug. Um, but, you know, simple things like, oh, is this transaction fraud? Like. Some of the world's largest like crypto, uh, institutions actually use us on the backend to determine like, is there fraud happening in real time? Uh, when's the next customer gonna turn? Uh, you know, where should we place this ad?

[00:39:32] Uh, what's the demand gonna be next quarter? So a lot of these, like very mission critical business flows. Um, so, you know, the platform's already been pre-trained on billions of relational, you know, patterns across thousands of data sets. You know, delivering a combination of accuracy and speed that would otherwise, you know, be impossible to achieve.

[00:39:51] And that's really what I talked about earlier is, um, I think what we're gonna see going forward is, um, [00:40:00] you know, the, the size and time that it takes for like these engineering teams and data teams to build these models. Like that's gonna continue to shrink and shrink and shrink and go away. Um, and, you know, everyone will, will kind of.

[00:40:12] Uh, grow through that and, you know, the work that MOPS is doing will, will kind of also grow into, you know, we have this convergence of the data engineering world and the operations world, and that's kind of how we set some of these new teams coming up, like GTM engineers, which is really a combination of those two, like skillsets of what was, uh, you know, someone working on marketing automation, for example, in the past, or someone who was also working on like building data models and things like that.

[00:40:38] Um, so that's my own, um, take, uh, on that. Anyways.

[00:40:43] Phil: Yeah. I love it. Jason, we, Darryl and I, were, were chatting before this looking at Una's website and like all the use cases and then like at the bottom of the menu it's just like, see o all other a hundred plus use cases. And I was trying to empathize with. The product marketer on your team who's having to like [00:41:00] write copy for all these different personas and use cases and we're like, man, that must be, must be tough.

[00:41:06] But it is a really cool platform and um, like I first discovered it many years ago when, uh, my former cos and I did like a super deep dive, uh, in like 2023 about like AI and marketing and, uh, at the time the positioning with Kuma was like. Democratizing machine learning pipelines. And I was working at WordPress when we had like a big data eng team and it took us like couple of weeks to create one pipeline for one event in our homegrown CDP.

[00:41:34] And at the time you guys were just like, you know, anyone on marketing can democratize creating ML pipelines. So it's cool seeing the evolution of that and all the use cases and, and how powerful the platform is. Uh, I wanna bring us back full circle though, Jason. We started the conversation talking about.

[00:41:50] You know, your first experience with rolling out Agentic workflows and agents at Kuo and how it kind of like ended up being pretty messy because you didn't fix some [00:42:00] of the foundational things at first.

[00:42:02] 7 — When to Ship AI Before Your Data Is Ready and When to Fix the Foundation First
---

[00:42:02] Phil: I wanna like get your take on the ship first argument here for the folks that are kinda listening and are just like, Hey, we need to move faster than pausing and fixing this like laundry list of data.

[00:42:14] Jason, so. Like I've heard some really smart people argue the opposite, where like ship the ai, let the bad output create the pressure to fix the data as opposed to like, let me get priority on this project that hasn't been prioritized for many quarters to fix the data before we do ai. These people are just like, nah, like.

[00:42:34] Before we fix the, the data, let's ship the ai, let the bad stuff happen, the chaos that you can talked about, and let that kind of be the pressure to actually then get priority to fix the data. The failures kind of become the business case, if you will. Is, is there like any version of that that's actually right, based on what you went through?

[00:42:52] Or is it just kind of rationalization for, for moving fast?

[00:42:56] Jason: Yeah. You know, I think it honestly, um, we [00:43:00] we have these two extremes, right? Where, uh, of course us, you know, who live in the ops world we like, because we live through the pain of like. The problems that, like the bad data causes, and we, we see the impacts of that. Um, so the more we fix that, the easier our life is and the better the outcomes.

[00:43:19] Right? And then you have the, I'm not gonna call 'em the opposition because they're our partners and I'm actually on the business side myself now. Uh, but then you have those on the business side who, who maybe don't always, uh, understand that or wanna learn like. They, they just have a number to hit this quarter, or they, we need to, you know, we need to increase pipeline.

[00:43:38] Uh, and it's like, okay, like, um, I don't care how, like it's your job to go figure out how to do that, but we need to also, we can't wait six months, uh, to, to like, uh, increase pipeline, right? So I think there's always gonna be this like, um, chaotic environment of moving. Fast while also [00:44:00] creating structure and scaling like appropriately.

[00:44:03] Um, so I think, you know, the reality is it's, it's gonna be a combination of both and that's like the kind of the lessons we talked through earlier, you know, which is really to, to break those down. You know, start with one workflow. You use historical examples like not trying to tackle the entire, like data, data ecosystem at once.

[00:44:22] Uh, and that really makes it much more manageable and kind of bite-size because. Um, look at the end of the day. you're, if you're, if you're based on revenue and, and you know, that's not, you're not, you're not driving, that pipeline's not going up. Like that's a problem, right? At the end of the day. But also what, why, what is the causation or what are the problems like behind that?

[00:44:44] There is all the things that we talked about that we have to fix on the back end. So it's, it's, really, I think, fearing out that, uh, that happy marriage, um, and, and the size of your organization matters. Like if you're, if you're extremely lean, uh, and you have a queue of 200 things to get to, like. That's [00:45:00] much harder than a team that has, uh, 200 resources at their disposal and like, you know, so, uh, I think, you know, there's definitely gonna be some of us who suffer more than others through that.

[00:45:10] Um, but that is, I think, you know, the way forward for the most part.

[00:45:15] Darrell: Yep. Totally. Yeah. And it really depends, you know, on what the impact could be. Is this gonna be a really big thing? Like I've always loved the, uh, the two-way door concept where if you go through a door and you. Can't come back, then you have to really take your time and, and, and make a right decision and make sure you're thinking about all the risks.

[00:45:34] But if you can come back pretty easily there, there's not too much risk in just maybe trying it with ai. Um, what. This one's a, a, a cool question. Um, especially now that things are changing so quickly and I feel like at work we're needing to try new things, but also get approval to try those new things.

[00:45:54] So like what's your best tip for getting internal buy-in from leadership? You know, [00:46:00] especially if it's like an unorthodox or like crazy idea.

[00:46:05] Jason: You know, this is, uh, I, this is a good one that I really like. I think, um, you know, my best tip is don't try to sell the whole idea, right? Uh, try to sell the bottleneck and the reversible next step. So like, uh, a lot of internal buy-in dies because people. Feel like they're being asked to buy your whole worldview at once, right?

[00:46:27] Like, like who's are you, if you're trying to get them to undertake the quest for the Holy Grail with you, like. That's probably a harder sell than, uh, you know, no, we're actually just trying to get to the next town and get a, a, a pouch of water to, uh, you know, fuel us to the next day or whatever. Um, so like I've learned to make it much smaller than that.

[00:46:50] I think. Like, uh, if something's worth doing, I try to frame it like, here's the actual bottleneck, you know, here's the business consequence of leaving it alone. [00:47:00] Um, here's the smallest test that we can do to tell us if we're right in this before we invest too much time or resource. Uh, and, you know, here's the, here's the blast radius if we're wrong in that.

[00:47:09] Again, you know, I think at that point, you know, people don't have to believe in the whole vision. They just have to agree that the problem's real and what's the reasonable next move. And then once you actually start to gain traction, um, and success around that trust grows. Like, of course, like people open up more and start to see, okay, this has actual value.

[00:47:27] Um, and then you're gonna be able to move much faster on the, you know, kind of the rest of the, the things you wanna achieve there.

[00:47:33] Phil: I love it. I, I like how you said unorthodox there, Darrow, because like, I, I feel like if you're just trying to pitch, let's fix all of our data, that's probably falls under the, the crazy thing that you're trying to get buying for, but. I love your advice there, Jason. Um, another fun one, uh, before we get into some of the last ones here, uh, your current title is Head of Marketing slash GTM Engineering and GTM [00:48:00] Engineering is one of the most debated job titles in marketing ops these days.

[00:48:05] Uh, so it'd be fun to get your take on. Like you've previously been head of Revenue marketing, head of marketing ops, head of marketing Analytics and Data science, director of Growth and Lifecycle. Like you've had your kind of taste across the landscape here, not even like touching some of your earlier experience.

[00:48:23] 8 — What GTM Engineering Actually Means When AI Automates the Middle
---

[00:48:23] Phil: What the heck does GTM engineering look like for you? Like is it that different than marketing operations? What, what are the differences for you?

[00:48:32] Jason: Yeah. Uh, you know, I love this question also. Uh, and it is probably is, you know, very, uh, debated. So, um, let's get into it. You know, I think this is exactly bridging, you know, what we were talking about. Um, really the future of. Both marketing operations and data engineering world. You know, as we talked about, systems are, are taking over more and, you know, human's role and supervising those outcomes.

[00:48:58] Um, [00:49:00] I think, you know, the reality is where I'm at, uh, is, you know, we're doing an extreme amount of work with an extremely lean team. Um, and, you know, being an AI first company, you know, one of our, you know, biggest pushes is always like. How can we solve this challenge with ai? Of course. Um, and, and a lot of that is ly actually, you know, implementing agen flows for, um, things that used to require either a data engineer to do or a marketing operations person to do.

[00:49:32] Um, like, and yeah, I still have, you know, a head of rev ops, head of marketing ops that, that work there. So, so there's still definitely humans in the loop. Uh, but I think what we're seeing is machines are now automating a lot of these tasks. Um. Around, you know, all of the flows of marketing, you know, uh, you know, lead generation qualification, um, early, uh, you know, driving early pipeline.

[00:49:57] Uh, and that's really kind of what that, what that is to me. It's [00:50:00] the, it's the, it's the machine and the loop now. Um, so GTM engineering is combining, um, you know, essentially the data folks, the engineers and the, and the, and the marketing operations of rev ops folks. Into kind of one function that is, uh, cyborg in nature, I guess.

[00:50:20] Phil: I love it, Jason. It's actually pretty spicy because I think most people think of just like a technical sales role. When you think of GTM engineering, like I've seen a lot of non-technical sales. BDM people like call themselves GTM engineers,

[00:50:39] so

[00:50:40] Jason: not, I would not agree with that, uh, that assessment probably, but yeah. Yeah.

[00:50:45] Phil: Yeah, no, I, I like, uh, I, I land a lot closer with, uh, where your definition is. It's a, it's a fun time to be in, in marketing ops and, and all the GTM space for sure.

[00:50:55] 9 — How Jason Dobbs Decides What Deserves His Energy
---

[00:50:55] Phil: Uh, we got one last question for you, Jason. You're obviously GTM engineering expert marketing ops leader, but you were also a. Adrenaline junkie, an electric longboard modeler.

[00:51:05] You got a ton of stuff going on on this side. One question we ask everyone is how do you decide what deserves your energy at any given moment, and what's your personal system for staying aligned with what actually makes you happy?

[00:51:18] Jason: Uh, I think, you know, I love that question. You know, we talked a little bit about, you know, my, my, my adrenaline junkie side, you know, whether it's riding, you know, F1 longboards or e foiling or snowboarding or free diving somewhere in the world. Um, you know, but happiness is, uh. Is is a very important one, and I think it's different for all of us.

[00:51:40] So I, I'm not gonna say what happiness should be for you, but I'll guess I'll just talk about it from my lens. And I probably have a slightly unorthodox answer because you know, of my background, um, and a lot of my life was shaped by, you know, mission first environments. So I think I don't usually ask like, what makes me [00:52:00] happiest today?

[00:52:01] Um, you know, I kind of ask like, what's my mission today? And that is that aligned with the life that I actually wanna build. Um, so for me, happiness is less about comfort and more about alignment. Um, you know, some seasons are hard. Uh, you know, we talked about where we're at and whether you want to agree we're in a global recession or not, or have we, or, you know, I'm not really here to get into that, but, you know, building anything meaningful always comes with sacrifice.

[00:52:29] Um, but I've also learned not to romanticize the grind and the burnout. Right? Um, so if a mission is. Steadily cost me my health, relationships, or integrity, then it's too expensive, right? Uh, so, you know, I think my filter for happiness is pretty simple. Like, does this matter? Is it mine to carry? Uh, is the contemporary, is the cost temporary or purposeful?

[00:52:51] Uh, and or am I just calling this like burnout discipline, right? Uh, so when those things lined up, you know, I can, I can give something a [00:53:00] lot of energy and, you know, in turn, um, you know, be happy as well.

[00:53:05] Phil: I love it. It's such a cool, uh, filter there.

[00:53:08] 10 — What Jason Is Reading: Intelligence History, Mind-Opening Nonfiction, and Dune
---

[00:53:08] Phil: Uh, last one, Jason, I lied that you said we don't have to ask, uh, you about books that you're reading right now because you're reading a bunch of weird stuff. I'm putting you on the spot here. What's the weird stuff I want to

[00:53:19] Jason: oh. The weird stuff. Oh man, you're gonna put me on stuff with the weird stuff. Um, no, I'm a, I actually, I'm, I read a lot about, uh, you know, as a human, like coming up. I think we all have. Oftentimes are locked by our own, like unconscious bias or like even things like that. So a lot of what I'm reading is like, you know, how to even open up my own mind to like new ideas that maybe wouldn't be, um, possible, um, kind of without this.

[00:53:48] So that crosses into a lot of different realms, whether it be, uh, knowledge or meditation or kind of, you know, other things. Um, but. Also, you know, I'm big into, you [00:54:00] know, of course my background, uh, in the intelligence industry. So I, I, I read, enlist a lot of podcasts on, um, you know, things, things in that environment.

[00:54:09] Um, you know, a lot of kind of CIA, uh, operational things. Uh, those are a lot of things I nerd out on. But then if you want to get into fiction area, you know, we can talk about, I'm a big science fiction nerd. As well. Um, so yeah, talk about a book. Let's, let's talk about dune. Let's talk about dune, I guess, right?

[00:54:27] It's, it's popular. We got the new movie coming up. Maybe not because of sci-fi cannon, but like what's underneath? It's, you know, underneath. I think it's really a story of power incentives, prediction, and the danger of, uh, thinking that seeing patterns means that you control outcomes, right? Uh, and I think that theme has, has aged really well today and kind of the age that we're in also.

[00:54:50] Phil: It's super cool. Yeah. I'm pumped for, uh, the new movie, uh, huge fan of, uh, de ne the, the director. Um, yeah, I Are you reading, have you [00:55:00] read the Dungeon Crawler Carl, uh, books Darrell and I are are, are binging

[00:55:04] Jason: Oh, okay. All right.

[00:55:06] I'm gonna have to put that on the list. I'm gonna put that on the list.

[00:55:09] Phil: Yeah. We'll, we'll share some ideas there. Didn't know you were a big, uh, sci-fi guy.

[00:55:12] That's pretty much all Darrel and I read.

[00:55:14] Jason: Oh, love that man. Yeah, for sure.

[00:55:17] Phil: Awesome. I really appreciate your time, Jason. This is super fun. Thank you so much for joining us.

[00:55:21] Jason: Yeah, it's been amazing. Thanks, Phil. Thanks Daryl. Look forward to, um, you know, seeing you guys again.