• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

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

Summary: Jason 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.

In this Episode…

• How Undefined Data Definitions Make AI Confidently Wrong
• Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck
• The 5 Non-Negotiables for AI Readiness in Marketing Ops
• How Marketing Ops Controls the AI Context Layer in a B2B GTM Stack
• Which Data Problems Block AI Deployment and Which You Can Ignore
• When to Ship AI Before Your Data Is Ready and When to Fix the Foundation First
• What GTM Engineering Actually Means When AI Automates the Middle

About Jason Dobbs

Jason is the Head of Marketing and GTM Engineering at Kumo, where he leads go-to-market. 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 also 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

The horse that is beaten to death in every AI meeting and podcast: AI is only as good as the data you feed it. Garbage in, garbage out. We get 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 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 decent, scores seemed okay, summaries were fine, recommendations felt grounded… The actual failure was invisible to anyone who didn’t already know what correct should look like.

“We were trying to automate ambiguity. We were asking AI to solve for confusion that we hadn’t yet ourselves solved for internally. And once you do that, you kind of enter the danger zone because the failure is essentially believable nonsense.”

The weakness showed up when Jason looked under the rock or tried to peer inside the black box. He asked: Dear AI machine, why did you score this account, what data drove this decision… and the logic fell apart pretty fast. Oh boy. 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.

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 sadly 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.

Back to the top ⬆️

Why Context Engineering Replaces Prompt Engineering as the AI Bottleneck

“Context engineering” is appearing in every AI strategy convo 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 term is more like a feeling vs a concrete set of decisions.

“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?

“Prompt engineering can make something smart. Context engineering is really what makes it dependable.”

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:

1. the definitions the system is operating from,
2. the data sources it has access to,
3. the tools it can invoke,
4. any memory it carries between sessions,
5. the guardrails on what it can do autonomously,
6. 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.

Back to the top ⬆️

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

Context engineering sounds like a new discipline but Jason’s 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 hot, Jason spent 7 years as a United States Air Force intelligence officer, working at 1 of the highest-stakes context assembly jobs that exists: the President’s Daily Intelligence Briefing.

Wait, what?? Yes actually!

Talk about a job that 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.

“The job’s the same: assemble enough trustworthy context to make a good decision without fooling yourself.”

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. Maybe the systems are different but 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 1 of the fastest ways to build a system that produces confident wrong outputs.

Back to the top ⬆️

The 5 Non-Negotiables for AI Readiness in Marketing Ops

Teams have been told to fix the data before deploying AI for years. It’s a reasonable directive with an impossible timeline. Jason’s minimum viable readiness framework reframes the question: what does this specific workflow actually need to be trustworthy? Trustworthy context plus a clear approval path gets you further than any open-ended data cleanup project.

The framework Jason calls minimum viable readiness has 5 components:

1. Shared definitions
2. Trusted access
3. Named ownership
4. Authority boundaries
5. Eval path

1. Shared definitions

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.

“If you don’t have those shared definitions, the AI is just gonna scale that disagreement.”

2. Trusted access

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.

3. Named ownership

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.

4. Authority boundaries

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.

5. Eval path

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 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.

Back to the top ⬆️

How Marketing Ops Controls the AI Context Layer in a B2B GTM Stack

Back in the day, Jason was a Salesforce administrator. He’s watched the marketing ops function evolve through every platform cycle, and his take on the craziness of AI in the role right now is really cool.

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.

“Marketing ops becomes the business-side context architect. They are the team closest to the definitions, to the routing logic, to the handoffs, to the exceptions, and real-world process integrity.”

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.

Back to the top ⬆️

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:

1. deduplication, the single most visible data quality problem in any CRM and almost always fixable without warehouse access;
2. basic ID resolution on the marketing side, where enrichment tools handle the pre-identification work;
3. 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 says those 3 are right, but 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.

“Marketing ops is way more powerful than people think. You can fix a lot this week without a data engineer.”

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: 1 column for problems ops can fix this week, 1 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.

Back to the top ⬆️

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 really hairy. But most of them aren’t relevant to the specific workflow you’re trying to run. The diagnostic question Jason uses to separate the two 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.

“If the system is summarizing, ranking, drafting, we can tolerate more mess. If it’s changing records, controlling spend, contacting customers on our behalf, making decisions that impact revenue, the bar jumps pretty fast.”

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: before any workflow gets autonomous authority, the team needs to answer what exact actions the AI will take, which fields drive those actions, whether a human can reproduce the answer from source data rather than accepting an output that looks plausible, what threshold defines a good outcome, what happens when the answer is wrong, and who has the authority to 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.

Back to the top ⬆️

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 an ingredient in the AI readiness recipe.

What actually signals that a team can run AI workflows reliably is admitedly, a 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.

“If this AI workflow makes the wrong call tomorrow, who finds out first? Who decides? How do we stop it? If nobody can answer that, that’s your readiness gap.”

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. 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.

Back to the top ⬆️

Why Prediction Is Not Policy When AI Agents Act on Warehouse Data

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 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.

“Prediction’s not policy. Once you cross into action, you still need guardrails, business rules, approvals, evidence that it’s actually driving business outcomes.”

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 actual gap is having the data and lacking a practical way to act on it.

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. They also need 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.

Back to the top ⬆️

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, supporting 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.

Those are 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.

“We have this convergence of the data engineering world and the operations world, and that’s kind of how we see some of these new teams coming up, like GTM engineers.”

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.

Back to the top ⬆️

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.

“There’s always gonna be this chaotic environment of moving fast while also creating structure and scaling appropriately. The reality is it’s gonna be a combination of both.”

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.

Back to the top ⬆️

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.

“Don’t try to sell the whole idea. Try to sell the bottleneck and the reversible next step.”

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.

Back to the top ⬆️

What GTM Engineering Actually Means When AI Automates the Middle

GTM engineering is one of the most contested job titles in marketing/rev 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 his 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.

“GTM engineering is combining essentially the data folks, the engineers, and the marketing operations and rev ops folks into one function that is cyborg in nature.”

What that looks like in practice is a function that holds 2 skill sets that previously lived in separate teams.

1. The first is the marketing automation and operations skill set: understanding lifecycle stages, routing logic, the commercial logic of when to act and how.
2. 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.

Back to the top ⬆️

How to Prioritize What Work Deserves Your Energy as a Marketing Leader

Jason is a cool dude. He 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.

“If a mission is steadily costing me my health, relationships, or integrity, then it’s too expensive.”

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 says: 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, and is the cost temporary and purposeful rather than burnout called discipline? 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.

Back to the top ⬆️

What a Former Intelligence Officer Reads to Stay Sharp as a Marketing Leader

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.

“Dune is really a story of power, incentives, prediction, and the danger of thinking that seeing patterns means that you control outcomes.”

His fiction pick is Dune. 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 100 years further out.

Episode Recap

Jason makes one central argument and defends it from a bunch of angles across the episode: AI readiness is a context engineering opportunity. 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 is 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.

1. Shared definitions, so the AI isn’t scaling a disagreement the business hasn’t resolved.
2. Trusted access, so the system can actually reach the right data with enough freshness.
3. Named ownership, so a specific human is accountable when something goes wrong.
4. Authority boundaries, so the system knows what it can do autonomously versus what needs a human sign-off.
5. 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 1 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.

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.

Full episode ⬇️ or Back to the top ⬆️

✌️

—
Intro music by Wowa via Unminus
Cover art created with Midjourney (check out how)

Apple •Spotify• Pocket Casts •Youtube •Overcast •RSS

Related tags

See all episodes

Future-proofing the humans behind the tech

Apple •Pocket Casts•Google •Overcast •Spotify •Breaker •Castro •RSS

• LinkedIn
• Twitter
• Instagram
• YouTube
• RSS Feed