• 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 Keith Jones, Head of GTM Systems at OpenAI.

Summary: The best martech buying process isn’t a spreadsheet. It’s a cognitive extraction exercise. Keith Jones asks stakeholders to write what they want, say it out loud, and then feeds both into GPT to surface what actually matters. That discipline applies to agents too. Most teams chase orchestration before they have stable logic, clean data, or working workflows. Keith is betting that the future of SaaS is fewer tools, built in-house, coordinated by agents, not a graveyard of dashboards pretending to be automation.

In this Episode…

• The Difference Between GTM Ops and GTM Systems
• Why Data Dictionaries, Syntax, and Prompt Engineering Will Reign Supreme
• Every Martech Vendor Wants to Be the AI Orchestrator. You Still Have to Be the Operator.
• The Ritual of GTM Ghost Stories That Turn Pain Into Pattern
• Why AI is Rewriting, Not Killing Martech
• Startups Built by One Founder and a Bunch AI Agents Are Already Emerging
• An Operator’s Framework for What Gets Done, Delayed, or Silently Dropped
• The Buying Process Isn’t a Spreadsheet. It’s a Cognitive Extraction Exercise

About Keith

• Keith started his career across various industries in sales ops and marketing ops roles
• He moved over to Mural where he led GTM Systems
• He later joined Gartner as their Sr Director, Analyst covering Revtech
• Today, Keith is Head of GTM Systems at OpenAI

Just a quick disclaimer that Keith is joining the podcast as Keith the technologist and human, not the employee at OpenAI. The views and opinions he expresses in this episode are his own and do not represent OpenAI.

Why Sales Ops People Who’ve Actually Sold Have the Sharpest Knives

Keith Jones did not set out to work in sales operations earlier in his career. He landed in it sideways, like a lot of the best people in ops do. He was hired with the catch-all title of “Business Operations Associate,” which could mean anything or nothing, depending on the day. His job, in practice, involved forecasting bookings and revenue in Excel based on shipping data. No one told him he was in sales ops. No one even used that phrase. If someone had asked him whether he wanted a career in sales operations, he wouldn’t have known what they meant.

The company later shifted him into a field sales role. They were trying to grow the team internally, so they dropped him into the southeast region and told him to start talking to CIOs and chief nursing officers. He moved to Atlanta and started selling. That job was hard in a way that most people who build systems for sales teams never understand. The structure was just enough to keep things moving, but not enough to support real learning. He had a quota, a few tools, and a manager who held weekly one-on-ones. There was no real training. No consistent coaching. No safety net. If he wanted to make it work, he had to figure it out himself.

That experience never left him. Now that Keith leads systems for go-to-market teams, he still thinks about what it felt like to sit in a seller’s chair. Every tool that didn’t work, every field in Salesforce that meant nothing, every process that made his job harder stuck with him. He builds differently because of that.

“You’re given a quota, a few tools, some vague expectations, and then shoved into the wild.”

The biggest disconnect he sees in GTM systems comes from people who have never sold anything. Many of the systems designed to help sales teams are built by career admins or operations specialists who’ve never had to ask for a purchase order or explain why a deal fell through. These people often optimize for what the business wants, not for what the seller needs to survive the quarter. Keith doesn’t speak about this in abstract terms. He lived through it.

After his healthcare role, he joined a startup in Atlanta as employee number eight. He came in as an account executive, but quickly became the go-to person for explaining the product. He wasn’t the most technical person, but he could speak the language. That mattered. As the company grew and new reps joined, Keith found himself teaching them how to explain the product to customers. He was still selling, but he was also building shared knowledge. That part felt natural.

Then his CEO pulled him into a room and told him something blunt. “You’re really bad at cold calling. You don’t even do it.” Keith agreed. He hated that part of the job. As an introvert, it never felt right. But the CEO followed up with something more important. “You know the product better than anyone else on the floor. I think you should be our first sales engineer.” Keith said yes immediately.

There was one more thing. The Salesforce admin had just quit, and the CEO asked if he wanted to learn Salesforce too. Keith said yes to that as well. That moment when he stepped into a role that combined technical depth with operational design set the course for everything that came next.

Today, he leads systems at a scale that touches thousands of sellers. He remembers what it felt like to sell without support, and he refuses to push that experience onto others. He builds tools that actually work because he knows what failure feels like.

Key takeaway: Sales ops works best when it is built by people who have actually sold. If you want to build tools that sellers will use, you need someone who has lived with the friction of broken ones. Sellers do not care about elegant reporting architecture if the CRM slows them down. They care about speed, clarity, and context. Hiring operators who have carried a quota gives you an unfair advantage. They remember how it felt to lose time chasing bad leads or cleaning up messy data. That memory turns into better workflows. You can teach someone how to configure Salesforce. You cannot teach someone how it feels to miss your number because your systems were designed by someone who never had one.

Back to the top ⬆️

The Difference Between GTM Ops and GTM Systems

When people talk about GTM operations, most of them blend it with GTM systems like it’s all one job. It’s not. They share a Slack channel, maybe a budget, and definitely a few dashboards, but the actual work is completely different. Keith has lived on both sides of that line. At OpenAI and before that at Mural, he ran GTM systems. Back at Gartner, he saw how every company defines these roles differently, sometimes with intention, sometimes out of inertia. But when he breaks it down, the split is actually pretty clear.

GTM ops exists to support the field directly. That means helping sellers, marketers, and customer success teams get their work done. Think enablement, process design, live troubleshooting, deal support, and training that doesn’t feel like a waste of time. These teams sit next to the people they’re helping and shape operations based on actual conversations and feedback.

GTM systems is a whole different rhythm. These are the people writing the workflows, building automations, owning the CRM, and threading together tools that are supposed to work seamlessly but rarely do. They are not front-facing. They are deep in the guts of your tech stack. They touch code, configuration, architecture, and logic trees that determine whether your rep gets the right lead or a ghost contact from 2017.

“We rely heavily on our ops colleagues to feed us guidance from the field so we can build the right solutions. That’s the balance that works.”

Keith’s favorite model is one where GTM ops and GTM systems are separate but inseparable. Not one inside the other. Not one reporting into the other. Two teams, side by side, solving for different parts of the same outcome. Ops listens and adapts. Systems builds and scales. When that rhythm is right, sellers feel supported without even knowing why. When it breaks, people stop trusting the process and start hacking together their own.

He makes an important distinction when talking about marketing ops. Unlike sales ops, which skews toward operational execution, or systems, which skews technical, marketing ops often lands in the uncomfortable middle. It needs to speak both languages. You might be setting up nurture logic in Marketo one hour and then coaching a team through campaign QA the next. Keith sees it as a dual-mode function, one that requires:

• Operational discipline to support marketers with templates, briefs, budgets, and targeting logic
• Technical fluency to build and maintain systems that track performance across platforms

The tension between systems and ops is real. I’s not a fight. It’s a rhythm. And when it works, it frees both sides to go deeper.

At OpenAI, Keith runs GTM systems. His team handles the tech that supports everything from sales to support to customer education. They do not guess what the field needs. They partner with GTM ops to find out. That way, the systems they build actually get used.

He’s clear about what doesn’t work. Systems teams that try to handle ops work directly end up shallow on both ends. You get half-baked tooling and slow response times. On the flip side, when ops tries to own systems without technical depth, you get duct tape solutions that break the moment the org scales. The handoff between those worlds needs to be clean, constant, and rooted in mutual respect.

Key takeaway: GTM ops supports people. GTM systems supports tools. When these two teams try to do each other’s jobs, everything gets slower, messier, and harder to scale. Keep their mandates distinct. Let ops stay close to the field and define what needs fixing. Let systems go deep on the build. Then connect them through weekly touchpoints, shared roadmaps, and actual conversation. You’ll know it’s working when sellers stop complaining about Salesforce and start asking for more of what works.

Back to the top ⬆️

Why Data Dictionaries, Syntax, and Prompt Engineering Will Reign Supreme

Everyone wants AI agents in their go-to-market stack right now. Not next year. Not post-cleanup. Right now. Every exec deck has a slide that says “agent-powered” even if the team can’t explain what that means. The hype is louder than the implementation. And if you’re the person responsible for actually making the tools work, not just pitching them, you already know where this is going. Most teams are nowhere near ready.

Keith Jones, who runs GTM systems at OpenAI, has seen the reality under the noise. The models are strong. They keep improving fast. And yes, agent-style automation can absolutely save time in real workflows. But they can only do that when the inputs are clean and structured. Right now, for most companies, that’s a fantasy.

Agents today are best at handling the kind of tasks humans never enjoyed in the first place. These are the rule-based, deterministic, repetitive chores you find buried in every sales and marketing org:

• Routing leads using fixed logic
• Pulling summaries from meeting notes
• Tagging records based on rules
• Parsing doc content to classify fields

These are the areas where agents already shine. They don’t need creativity. They need structure. And if you give them clean structure, they return value fast.

“The agents that are worth serious attention today are the ones built to handle robotic tasks we’ve been stuck with for a long time.”

That’s the bright side. The hard part is this: you do not get to skip the boring prep work. If your data model is a mess, if field names mean different things in different reports, if you’re still reconciling accounts across three tools because no one agreed on a single syntax, agents will not fix that. They will magnify it. They will move fast and confidently into the wrong direction.

Keith puts it bluntly. You need clear, unambiguous field definitions. You need consistent tagging and syntax. You need structure that works for a machine, not just something your RevOps lead can interpret after ten years of tribal knowledge. And this isn’t just philosophical. It’s mechanical. Models cannot make assumptions the way humans do. They will not connect a mislabeled status field with the right intent. They will just get it wrong, quietly and at scale.

The good news is that you can use agents to help you build that foundation. Keith’s team built their entire internal data dictionary using OpenAI’s own models. The system took raw field labels, proposed reasonable meanings, suggested standardization, and helped them get to consistency in days instead of quarters. It didn’t do the job end-to-end. But it gave them a massive head start.

That’s what agent-powered GTM should look like right now. Not an army of bots running deals end-to-end. Not a fake copilot that hallucinates notes. Just smart, structured deployment of technology to automate boring, high-volume tasks once the groundwork is in place.

Key takeaway: AI agents can drive value in GTM today, but only if your foundation is already clean. Focus on the mechanical stuff first. Standardize your data model. Define your terms. Use consistent syntax. Then deploy agents to handle repetitive work at speed. Let the models help you build faster, not guess harder. Every time you delay fixing your data structure, you’re building a higher wall between hype and execution. You don’t need more dashboards. You need clean inputs, structured logic, and workflows that actually make sense. Build that, then let agents take it from there.

Back to the top ⬆️

Every Martech Vendor Wants to Be the AI Orchestrator. You Still Have to Be the Operator.

AI agents are turning every Martech product into an orchestration platform. One day it’s a lead scoring tool, and the next it’s promising autonomous campaigns powered by agent logic and “intelligent coordination layers.” Every vendor wants to be your operating system. Every vendor claims their agents are smarter, faster, easier to use. And if you’re running systems for a GTM org, your inbox is already full of conflicting promises that all start to sound the same.

Keith Jones has seen this movie before. He runs GTM systems at OpenAI now, but he’s spent years dealing with tech stacks that don’t play nicely. The names change, but the job stays the same: get systems to talk to each other without tearing the whole thing apart. The rise of agent-based orchestration makes this harder, not easier… at least in the short term.

Vendors aren’t offering you interoperability. They are offering you autonomy, on their terms. That means the second you turn on AI features in one tool, you’re committing to that tool’s logic engine. And when another vendor does the same, your ops team ends up caught in the middle trying to referee a dozen smart tools that each think they’re in charge.

“You’re playing translator between vendor A and vendor B and the agents or orchestration layers within them.”

Keith breaks it down like this. Think back to the CRM and MAP integrations you’ve done in the past. They were fragile. You had to understand:

• How each system queued processes
• What its API rate limits were
• How it handled errors or failures
• What happened when the same record got touched by both tools at once

Now add agents to the mix. Add logic branches. Add conditional triggers that can be modified by a model’s interpretation of user behavior. This is not just automation anymore. This is system logic layered on top of more system logic.

You cannot automate what you do not understand. You cannot orchestrate across tools unless you know exactly how each one works under the hood. That means knowing not just what the tool *can* do, but how it processes instructions, what its queue timing looks like, how it retries failures, and whether it even knows what a failure *is*. Most vendors are not going to tell you. You have to learn that yourself.

There may be a “master orchestration layer” someday. Some platform that acts as the central nervous system, coordinating your agents across tools. That day is not today. For now, the job still falls to humans. You are the orchestrator. You are the debugger. You are the one who has to say, “Yes, we’ll turn on the AI logic in Tool A, but not in Tool B, because Tool B doesn’t handle race conditions well and will break our attribution model.”

That decision isn’t strategic. It’s mechanical. And if you do not understand how the engine works, you are not in control of where the vehicle is going.

Key takeaway: Every Martech vendor is trying to sell you orchestration. That does not mean they can deliver coordination. Before you turn on any AI-powered logic, get intimate with how each tool handles automation, sequencing, and handoffs. Know what order things happen in. Know what breaks. Know what it takes to recover. If you do not understand the mechanics, you cannot trust the automation. That way you can decide, system by system, where agent logic adds value and where it introduces chaos. You are not just a systems leader anymore. You are the air traffic controller in a sky full of pilots who think they’re flying the same plane.

Back to the top ⬆️

Agents Work Best After You’ve Translated Instincts Into Clear Steps

Everyone wants AI agents. Most companies barely have documentation. The pitch is always the same: “Imagine if your team could focus on the big stuff while agents handle the repetitive work.” But when Keith hears that, he sees a giant warning sign. He leads GTM systems at OpenAI. He knows what happens when companies try to scale logic they never bothered to define.

He compares agent workflows to lead scoring, and not the polished kind that shows up in a vendor demo. He means the messy, early-stage kind you build yourself with feedback from reps who still think it’s useless. Years ago, Keith stood onstage at a sales kickoff to unveil the company’s first lead score. One of the reps pushed back. “Why do I need this?” Keith asked the rep to explain what made a lead good. The rep rattled off four traits. Keith smiled and said, “That’s exactly what the lead score is doing. It’s just automating what you already do; so you can focus your time at the top of the list.”

“Let’s replace something I already do, automatically or subconsciously, and do it better, at scale, with an agent.”

That’s the entire premise, clean, mechanical logic drawn from real human behavior. If you can’t explain how your team decides when to follow up, route a lead, or prioritize a renewal, you have no business automating it. You can’t improve what you haven’t mapped.

Agents work best when they replace invisible labor. The stuff you do by feel, out of habit, every day. You can train models to mimic that behavior, but only after you’ve translated instincts into process. That translation is hard. It requires sitting down with humans and asking annoying questions. What fields do you look at first? How do you know this account is warming up? What red flags make you bail?

The payoff is worth it. Keith believes the point of AI is not to replace the work. It’s to create room for better work. The more clarity you build around how things get done, the more freedom you give your team to focus on what matters.

Key takeaway: AI agents are not mind readers. They are logic engines. If you want to use them well, you need to extract the rules your team already follows and write them down. Choose one task that your team does often, does well, and does the same way every time. Document it step by step. Build your agent to replicate it. Review the output, tweak the logic, and only then scale it. You cannot automate instincts. You can only automate structure. That way you can reduce decision fatigue, save time, and give your team space to think bigger.

Back to the top ⬆️

The Ritual of GTM Ghost Stories That Turn Pain Into Pattern

AI is rewriting the playbook in real time. GTM teams are being asked to scale systems while the ground beneath them changes shape every quarter. Job titles evolve mid-project. Tooling shifts before the integration is stable. Everyone wants to sound like they’ve got it figured out, but very few actually do.

Keith learned how to stay relevant by building through chaos, not waiting for clarity. Early in his career, he stepped into ops with no formal training and no working playbook. One idea carried him through: Do it. Try it. Fix it. That pattern became his default. Build something. Test it. Learn by doing. Adjust fast and keep momentum.

This rhythm has carried him through years of shifting stacks, overlapping tools, and high-pressure asks. Instead of freezing, he gets moving. Instead of planning forever, he launches, observes, and corrects. That momentum creates clarity faster than theory ever could.

“The failures in the beginning are smaller. The risk is lower. But the education is just as valuable.”

Every lesson that matters leaves a mark. Keith runs a ritual with his team called GTM System Ghost Stories. Everyone shares a moment when they built something that blew up. Each story comes with a scar. No one forgets the day they triggered the wrong webhook or deleted a core automation rule by accident. That pain turns into pattern recognition. Those patterns build judgment. That judgment makes future decisions faster and sharper.

Keith stays sharp by leaning on a network of operators who live in the same mess. They send screenshots at 11:47 p.m. They share notes on what quietly failed. They learn together by comparing damage reports, not polished case studies. That kind of community turns personal failure into collective knowledge.

Progress in GTM starts with forward motion. Speed shows up later. First you build a cadence of testing and fixing. Then you refine the judgment that helps you skip bad paths. That cadence, more than any tool or trend, keeps you relevant.

Key takeaway: Staying sharp in GTM means building small, real things under live conditions, before you feel ready. Choose a problem that matters. Launch something narrow. Watch what fails. Fix what matters. Track your own learning like product telemetry. Talk to operators who’ve done it badly and survived. Trade war stories. Compare logic. You will not learn this by watching. You have to try it. That way you build instincts that scale faster than any roadmap can keep up.

Back to the top ⬆️

Why AI is Rewriting, Not Killing Martech

The AI-fueled panic about the “death of SaaS” keeps showing up in threads, keynotes, and VC Twitter sermons. Some of the loudest voices are already carving the tombstone. Keith has a different take. He sees something dying, but it’s not SaaS itself. It’s the lazy, overbuilt, one-problem-one-tool model that defined much of the last decade.

Buying a thousand seats of a single-function SaaS tool used to be standard. That model is collapsing. Teams don’t want more vendors. They want more leverage. They want fewer tabs, deeper orchestration, and smarter logic that spans systems. AI agents are speeding this shift up, but they didn’t start it. Consolidation was already rolling before the hype cycle spiked. Mergers. Native integrations. Feature bloat disguised as expansion. All of it pointed in one direction: fewer tools doing more work.

“The version of software as a service where you buy a thousand seats to do only X, Y, or Z is definitely going away.”

The shift is structural. Teams now have the capability to rebuild internal versions of lightweight tools using agents, scripts, and just enough logic. That doesn’t mean engineers are about to custom-code CRMs from scratch. It means you no longer need a paid vendor to automate lead scoring, standardize lifecycle stages, or clean records across platforms. In a world with solid models, decent APIs, and a clear data layer, those once-sacred tools start to look like overhead.

Keith calls out the next phase clearly. Agentic orchestration will become the metric. Not features. Not dashboards. Not integrations. The winners in the new SaaS landscape will:

• Coordinate workflows across tools without constant manual maintenance
• Handle conditional logic, routing, and record mutation natively
• Support lightweight customization so operators can build what they need without waiting on product teams

The idea of agents talking to other agents used to sound like science fiction. It now sounds like Tuesday afternoon in a high-functioning ops org. Keith believes that cross-agent interaction will happen most often at the micro-transaction level. That’s where one agent passes off context to another, quietly and efficiently, without human input. Not because it’s flashy, but because it’s faster.

Some vendors will absolutely fade. Not because AI killed them, but because they stopped adapting. Others will evolve into deeper, more flexible platforms that can house agent logic and simplify operations. SaaS is shifting from product to infrastructure. The players who get that will still matter.

Key takeaway: SaaS is not disappearing, but it is being rewritten. The future belongs to platforms that act like orchestration layers, not just tools. If you own systems, start identifying where internal agent workflows could replace narrow point solutions. Push vendors to show you how they’ll support coordination, not just execution. Document where you rely on tools for things you could build in-house with model support. That way you can reduce costs, move faster, and avoid becoming the admin for five different tools doing the same job with different logos.

Back to the top ⬆️

Startups Built by One Founder and a Bunch AI Agents Are Already Emerging

The idea of a solo founder running a startup with a swarm of AI agents sounds like science fiction to some. To Keith, it sounds like something that already started happening quietly inside technical teams that know where to look. The tools are here. The difference is the founder.

Some CEOs will get there years before others. It has nothing to do with ambition or vision. It comes down to wiring.

The first wave will be technical founders. These are the people already building internal tools for fun, stringing together APIs, and writing scripts that feel like full features. They don’t need to wait. They already speak the language of inputs, outputs, context, and logic.

Right behind them are the systems thinkers. These are operators who understand how to connect dots even if they don’t write code. They move fast because they see patterns, build workflows, and map out processes that can be executed by agents instead of people.

The last group to catch up will be sales-driven founders. Not because they lack talent, but because their strength comes from human interaction, not orchestration. For them to run with agents, the tools need to get better at nuance, tone, and judgment. That gap is shrinking, but it still matters.

“Technical leaders are going to be the people who do it first. That’s how they think; how to multiply the force of humanity through the tech they’re building.”

The timeline will stretch across a curve. Some startups will launch next year with a single founder, a laptop, and a pack of agent workflows doing the heavy lifting. Others will follow as platforms become more abstracted and more forgiving. Eventually, building with agents will feel like dragging blocks around in Figma or using Zapier on steroids. At that point, the barrier won’t be technical skill. It will be imagination.

A one-person company used to mean tiny ambition. That idea is getting torched. The next generation of lean startups might look like ghost towns on org charts, but they’ll operate with leverage that used to require a dozen full-time employees. Some will stay that way by choice.

Key takeaway: Startups built by one founder and a network of AI agents are already emerging. If you want to run that play, figure out where you are on the curve. Technical and operational founders can start now by identifying repeatable work they already do manually and turning those steps into structured workflows. Build one automation at a time. Use agents for execution, not guesswork. Hire only when a problem truly demands a human. That way you build something real with less overhead, fewer dependencies, and more leverage than ever before.

Back to the top ⬆️

An Operator’s Framework for What Gets Done, Delayed, or Silently Dropped

Every GTM systems team drowns in ideas. Every quarter brings a fresh backlog of big bets, stakeholder requests, integration dreams, and “wouldn’t it be cool if…” tickets. You cannot ship all of it. You probably shouldn’t ship most of it. Keith has built a mental framework to qualify what gets done, what gets deferred, and what quietly dies without a funeral.

It starts with direction. You need a true north. If your team doesn’t agree on what actually matters to the business, then every prioritization conversation turns into a performance art piece. Keith looks for existential problems. These are the goals that define whether your function is driving revenue or just generating reports. Everything maps back to that.

Once you’re facing the right way, the filtering begins. He breaks it into three core dimensions:

1. Product-Need Fit: Every system or tool (internal or external) needs to pass this test. Keith asks whether the solution directly serves a meaningful business need. That match has to be real, not just convenient. The shiniest tool still has to solve a hard problem with precision. If it doesn’t, it goes cold.
2. Complexity vs. Composite Value: Some projects come with huge potential payoffs but drag weeks of scope and stakeholder friction behind them. Others are lighter, quicker, and easier to launch. Keith weighs whether a single high-complexity win is worth more than several smaller, cumulative ones. Often it isn’t. Four clean wins can outweigh one moonshot with a tangled setup.
3. Cost of Doing Nothing: This is the reality check. Keith asks the hard question: What happens if we skip this? Some ideas feel exciting but change nothing critical if ignored. Others carry quiet consequences that build over time. The work that passes this test often feels boring at first, but it stabilizes foundations. That stability is what enables smart risk later.

“You’ve gotta be truthfully honest with yourself and your team. What happens if we don’t do it? Will we be okay if we don’t?”

Keith shared an example from inside OpenAI. As the first GTM systems hire, he had full runway to build structure, process, and tooling from the ground up. As someone who loves clean workflows and labeled boards, he was tempted to over-engineer it all. He didn’t. Because the team was still delivering at a high level. They were fine without it. And building it would’ve just slowed momentum.

There’s one more signal Keith watches for. If a project starts to feel repeatable, if the logic gets clearer and the process tightens, it may be time to hand it to an agent. Those moments signal that a workflow is ready for templating. That is when GPT-level tooling shines. It doesn’t replace strategy, but it absorbs repetition.

Key takeaway: The smartest operators don’t start with what they *can* build. They start by killing everything that doesn’t matter. Use existential goals as your compass. Filter through product-need fit, weigh complexity against cumulative value, and always ask what happens if you skip the work. When a problem feels familiar enough to delegate, automate it. That way you protect your time for the decisions that only you can make and avoid spending a sprint on the stuff you’ll laugh about ignoring six months later.

Back to the top ⬆️

The Buying Process Isn’t a Spreadsheet. It’s a Cognitive Extraction Exercise.

Keith evaluates tech by mapping how people think before deciding what tools to use. His process extracts raw priorities directly from the team and turns them into structured input that actually reflects reality. Every step is designed to reveal gaps, clarify assumptions, and align people before anyone picks up the phone for a demo.

The process starts with a simple writing exercise. Each stakeholder fills out a short doc with three prompts:

• What problem are we solving?
• What are your must-haves?
• What are your nice-to-haves?

This part gives people space to put thoughts on paper. Once that’s done, each person records themselves reading what they wrote. Keith prefers video when possible, but audio works too. Speaking adds a second layer of signal. People revise, clarify, and add missing context as they say their ideas out loud.

“You’re going to add context when you read what you wrote. Even if it’s just an extra two percent, it’s going to come out of your mouth.”

Keith pairs the doc and the recording for each person, attaches metadata about their role, and sends the full input into GPT. Then he asks the model to run a structured analysis:

1. Synthesize the written and spoken input for each person
2. Group responses by function to identify patterns across roles
3. Generate a combined requirements set for the entire team

That synthesized output becomes the benchmark for every vendor or build conversation. It defines the problem, captures the context, and reflects the shared thinking of the people closest to the work. Keith uses this framework to guide internal decisions, push vendors for clarity, and cut anything that doesn’t serve the core need.

The system began with a Slack message. A sales leader asked if she could record a video instead of writing a doc. The result was clearer than anything Keith had seen in a slide deck. That moment shaped the process. Now it’s baked into how he evaluates every major tech decision.

Key takeaway: Ask your team to write what they need, then ask them to say it out loud. Capture both. Feed the written and spoken input into GPT along with each person’s role. Use the combined output to build your requirements. That way you build alignment from real thinking, not recycled templates. You will make sharper calls and avoid solving the wrong version of the problem.

Back to the top ⬆️

You Can’t Go Hard Every Day and Expect to Stay Standing

Keith stays grounded by chasing problems that are worth solving. He needs to feel mentally engaged to feel fulfilled. That’s the baseline. He’s not in it for the title or the next performance cycle. He wants to wrestle with work that pulls him in, where the outcome matters and the process stretches him. If the problem is stale, the burnout comes fast.

Satisfaction at work only gets you halfway there. You still need room to reset. Keith has spent years as a cyclist and, more recently, picked up running. Both have taught him what happens when you push without limits. You crash. You flame out. You wake up and the tank’s still empty. The lesson isn’t about sport. It’s about staying in the game long enough to do something meaningful.

“I’m going to do a nine-and-a-half mile run tomorrow. You know what that means I’m not doing on Sunday? Running nine-and-a-half miles again.”

That logic carries into his calendar. Keith blocks out mornings before 7:00 a.m. and evenings after 7:00 p.m. It’s not rigid, but it’s intentional. If something matters, he’ll make space. If it doesn’t, it waits. The habit isn’t about defending every minute. It’s about understanding his rhythm so he knows when to sprint, when to jog, and when to stop moving altogether.

Key takeaway: Fulfillment requires two inputs: problems that challenge your brain and time that protects your energy. You need both. Carve out space to recover. Stay honest about your capacity. The work will always be there. Your fuel won’t.

Back to the top ⬆️

Episode Recap

Keith Jones builds systems with the memory of someone who’s had to sell with broken ones. He split his career between carrying a quota and fixing the tools that made hitting it harder. Now at OpenAI, he’s clear: GTM ops supports people, GTM systems supports tools. Collapse the two, and your team slows down, your CRM fills with garbage, and your reps quietly build their own workflows.

The AI hype has only made this worse. Everyone wants agents, but most haven’t done the prep. Keith sees teams trying to automate logic that doesn’t exist and feed models data that no one’s bothered to clean. Structure comes first: clear fields, consistent tags, workflows that actually work. Without that, your agent isn’t helping. It’s guessing.

Meanwhile, every martech vendor wants to be your orchestration layer. They promise coordination, but they don’t play well with others. Keith knows what happens when you turn on logic in two tools without understanding how they queue or fail. You spend more time debugging than selling.

The best operators don’t wait for perfect. They ship something small, watch it break, and fix it fast. That’s how Keith’s team builds judgment. They track their failures like telemetry, not drama. SaaS is shifting too. Fewer logos, more internal builds, more agent workflows replacing shallow point solutions. But only if you know what matters and what to ignore.

Keith makes tech buying feel more like therapy. He gets people to write what they need, then say it out loud. GPT turns that into alignment. Structure built on real context with any fluff or assumptions. That’s how you build systems that work. Not from theory. From practice.

Listen to the full episode ⬇️ or Back to the top ⬆️

Follow Keith 👇

• LinkedIn

✌️

—
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