The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/RevOps/Driven Ops Power Talk
Driven Ops Power Talk artwork

Ep. 29 - Being technical is great, but being understood is better

Driven Ops Power Talk · 2025-10-15 · 11 min

0:00--:--

Key moments - from our scoring

Substance score

27 / 100

Five dimensions, 20 points each

Insight Density7 / 20
Originality4 / 20
Guest Caliber4 / 20
Specificity & Evidence8 / 20
Conversational Craft4 / 20

When technical professionals buried in CRM administration, sales engagement platforms, and system integrations need to communicate with business leaders, clarity becomes a competitive advantage. Jasmine Warren and Rebecca Heisey tackle this challenge head-on using a real HubSpot form implementation scenario where a web developer's technical language created unnecessary back-and-forth. The hosts stress that jargon like HTML, user lookup fields, and credentials confuses executives and slows execution - and this applies broadly across go-to-market ops. They outline a practical three-part framework: first, always understand the underlying business process before solving technically; second, dig into the why behind any request rather than executing blindly; third, communicate using a simple structure that states the problem, explains business impact, recommends actions, and clarifies ownership and timelines. As an example, instead of telling your CRO about "misaligned user lookup fields," describe how outdated owner records mean leads sit unmanaged or route to former employees, then explain the mapping and reassignment work needed. The hosts note that platforms like ChatGPT and Gemini can help rephrase technical concepts for specific audiences. This episode benefits sales ops, marketing ops, and RevOps professionals managing Salesforce, HubSpot, or similar platforms who regularly bridge technical and executive worlds.

Key takeaways

  • →Technical professionals must translate jargon into business-friendly language when communicating with stakeholders - avoid terms like HTML, credentials, and user lookup fields in favor of describing business impact.
  • →Always understand the underlying business process and intended outcome before implementing technical solutions, rather than executing requests at face value.
  • →Structure stakeholder communications as: problem statement, business impact, specific recommendations, and clear ownership/timeline to minimize confusion and accelerate execution.
  • →Use AI tools like ChatGPT or Gemini to help reword technical explanations for different audiences such as executives, sales leaders, or marketing teams.
  • →Being technically skilled is valuable, but being understood by non-technical stakeholders is what drives actual business results.

Guests

Rebecca Heisey

Topics in this episode

RevOpsTerritory managementHubSpot form builderslead routing and assignmentSalesforce fields and mappingsales opsmarketing opsBDR assignmentCRM administrationsales engagement tools

Questions this episode answers

How should I explain technical issues like CRM field mapping to my CRO or sales leader?

Frame it in business terms by stating the problem (e.g., outdated owner records), its impact (leads sitting unmanaged or assigned to former employees), your recommendation (reassign leads and create new territory mapping), and who does what by when - avoid technical jargon like 'user lookup fields.'

What's the best way to structure communication when requesting approval for a technical project?

Use: problem statement, business impact, specific recommendations and next actions, and clear ownership with timeline - for example, 'I'll handle the mapping, our admin will reassign records, and I'll notify users by next week.'

When should you question a stakeholder's technical request rather than just implement it?

Always ask about the business outcome and process first - understand what goal they're trying to achieve and whether the solution will impact other departments before proceeding technically.

How can tools like ChatGPT help in communicating technical issues to non-technical teams?

Use them to rephrase technical concepts into layman's terms or to frame explanations specifically for executive, sales management, or marketing audiences so the message lands clearly.

What's the difference between being technical and being understood in a go-to-market role?

Being technical is valuable, but being understood by stakeholders is what actually drives business results and accelerates execution - clarity and business language matter more than demonstrating technical expertise.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

7 / 20

The episode delivers a few practical, actionable points (the problem-impact-action-who-when framework, understanding business process before building) but they are widely known communication basics. The HubSpot form builder anecdote and lead-routing example add a little texture, but the 11 minutes contains significant padding and affirmations that dilute the usable content per minute.

I like to state the problem, the impact, and the action required. Like keep it very clear and say, here's the problem we're having. This is how it's going to impact us. And this is how we fix it.
we have record owner properties that are not accurate. So we have some BDR owners that are not owners of their leads. We have some people who have left who are owners and it's causing some misalignment in leads.

Originality

4 / 20

Every idea here - speak in layman's terms, understand the why, state problem and impact - is standard communication advice that circulates widely across any management or ops resource. The ops-specific framing adds marginal novelty but there is no contrarian, first-principles, or counterintuitive argument anywhere in the episode.

You should avoid technical jargon. It's just going to cause frustration. It's going to take a lot of back and forth. You're going to waste time and you're not going to be able to execute.
you have so much access to AI, right? Like you have Gemini, you have ChatGPT, whatever you use, that's your favorite one, is a really great place to go to, to say, how can I explain this in layman's terms

Guest Caliber

4 / 20

There is no external guest; the episode is just the two co-hosts, who describe themselves as practitioners with roughly a decade of experience in sales and marketing ops. Their seniority level and scale of operations are never established, and the anecdotes suggest mid-level individual contributor work rather than leadership at scale.

I'm Jasmine Warren. And I'm Rebecca Heisey. We're two work besties who have spent over a decade learning the ins and outs of sales and marketing.
I was working on a HubSpot transformation project with a client, and I was working with their web developers to implement a bunch of forms.

Specificity & Evidence

8 / 20

The episode earns some credit for product-specific detail (HubSpot legacy vs. new form builder, WordPress embed behavior, Salesforce field-naming conventions) and for a concrete hypothetical lead-routing scenario with named roles (BDR, CRO, admin). However, there are no real company names, no metrics, no dollar figures, and the examples remain illustrative rather than evidential.

in HubSpot, there are two types of form builders. There's the legacy form builder, and there is a new form builder. And different features are in each one.
leads are routing based off of just an owner field and there are out-of-date owner fields and there's territories that aren't being accounted for

Conversational Craft

4 / 20

The format is two co-hosts where one (Jasmine) narrates and the other (Becca) predominantly affirms with 'Yeah,' 'Exactly,' and brief additions. There are no probing follow-ups, no pushback, and no productive disagreement; the conversation is essentially a monologue with agreement responses, which limits any intellectual depth the topic might have offered.

Yeah. And I think the great thing is that we have so much access to AI, right?
Yes, exactly. That's perfect.

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Most-used words

understand11form8back7technical7developer6role6leads6sales5market5season5excited5forth5trying5builder4terms4fields4

Episode notes

Technical folks, this one's for you! We're unpacking why technical messages don't always land and how to fix it. Skip the technical jargon and instead learn how to better align with business teams, communicate clearly, and keep projects moving without all the back-and-forth. Plus, we're celebrating the end of season two and sharing what's next for Power Talk.

Full transcript

11 min

Transcribed and scored by The B2B Podcast Index.

Welcome to Driven Ops Power Talk. I'm Jasmine Warren. And I'm Rebecca Heisey. We're two work besties who have spent over a decade learning the ins and outs of sales and marketing.

On this podcast, we discuss all things go-to-market operations. The people, processes, and technologies that make up the engine of a thriving go-to-market function. Let's get to it. Welcome back to Power Talk.

This is our last episode of season two. We made it. It's crazy. I know.

I'm so excited to kick it off. Today, I want to talk about something that has happened recently to me. So I was working on a HubSpot transformation project with a client, and I was working with their web developers to implement a bunch of forms. And the web developer, so in HubSpot, there are two types of form builders.

There's the legacy form builder, and there is a new form builder. And different features are in each one. and they embed their forms on their website, WordPress. So when you embed forms, depending on which form editor you use, that will depend on the level of control that the web developer has in styling the form.

So for some reason, the legacy form has more capability in styling than the new form editor as of today. So when I was working with their web developer, and they were sending emails back and forth, And then they randomly sent something that said, hey, this has the H4 and not the HTML version that we need, something, something. And it was like not a direct sentence to myself and another architect. And we're just like trying to read between the lines.

And it was we're not web developers. so it took a couple back and forth and it took me knowing so using like contextual clues and reading in between the lines to understand like oh okay so you need a new form created with the legacy builder rather than the new builder and so it was just a frustration because I feel like it wasted some back and forth time and it was all because of as a as a developer or technical person sometimes you have to speak to the business and you have to speak clearly and you don't have to speak technically.

Like if you're writing HTML and you're a developer, you should not be speaking in those terms to the business in my opinion, because it slows things down. Yeah. And you shouldn't assume that somebody understands that language. Like if you know you are in this role, sometimes you do have to use more layman's terms, no matter what role you're in, no matter what role you in you not always going to know like exactly what the other person is talking about when they referring to specific things So yeah it just good business etiquette to try to say okay this is really you know specific to my job.

And so you probably are not, that's why, you know, you've hired me to do this role. So, or whatever, you're working with me on a project to do this role. And so obviously you're not in that role. And I was just thinking, this comes up a lot in marketing and sales apps because We are the technical person on go-to-market a lot of the times because we're the administrator to the CRM or the sales engagement tool.

And we have to talk to the business a lot. And we've developed a skill to be able to do that. And I'm not just going to go to my CRO and say, hey, we're having sync issues because of credentials and all that. I'm not going to say that.

Yeah, exactly. And when you do have to have those difficult conversations, at least from my perspective, I feel like I'm already running through it in my head of like, how can I clearly articulate this to this group of people who is not close to this at all? You know, you have to be able to rephrase things to make it much more impactful so they understand the urgency behind it without confusing them and getting like bubbles in their head, you know, like over their head or whatever.

Yeah. I like to state the problem, the impact, and the action required. Like keep it very clear and say, here's the problem we're having. Yes.

This is how it's going to impact us. And this is how we fix it. Yeah. Just speaking layman's term, business terms, we don't need technical jargon.

Yeah. And it's really interesting because, I mean, I've had instances exactly even with general like fields and Salesforce versus fields and other platforms that don't have the same naming convention, but they're the same field because you're just mapping, you know, like a phone field could be called like a company headquarter phone or something. But then in another platform, it could just be phone one. You know what I mean?

Yeah. So we want to go through three lessons that we've learned in our careers as technical people working within go-to-market functions and having to build up that muscle in talking to the business. Yeah. So the first thing you should do is always understand the business process.

You may be managing the system, but understand the processes that this system is supporting so that when you're asked for an enhancement or you're asked to build something out or troubleshoot something, don't just go and do it technically. First ask, okay, what business outcome is this process for? What are we trying to achieve here? What is this not allowing us to do?

like ask questions that are related to the business. So then you can build the technology to support that Yes You have to understand the why behind what is happening but you also are the person then who needs to be able to say like this is what your goal is But like is this going to impact anybody else You have to be able to kind of be that mediator in between your departments because you know you handle that tool. And maybe this is one department that just wants some change.

But yeah, you definitely have to understand like, what is that end goal they're trying to get to? Yep. So know the business process one. Two, understand the why behind any technical or development asks.

The third lesson is communicate simply and clearly. And this goes back to my experience with a web developer. Just understand if you're trying to communicate something to an end user or a stakeholder, you have to avoid technical jargon. It's just going to cause frustration.

It's going to take a lot of back and forth. You're going to waste time and you're not going to be able to execute. Yeah. And I think the great thing is that we have so much access to AI, right?

Like you have Gemini, you have ChatGPT, whatever you use, that's your favorite one, is a really great place to go to, to say, how can I explain this in layman's terms or to an executive team or to like a sales management team or a marketing team? Like, how can I explain this in these kinds of group settings that will be the clearest to them? And those kinds of platforms can also help you reword things that maybe you just can't think of, but break it down a little bit simpler for those groups.

Yeah. And this is an easy way to frame what you're trying to communicate to stakeholders. So first state the problem, state why it matters, provide your recommendations and next actions, and then the who and the when. So for example, say you are working on some lead routing and you're having issues because leads are routing based off of just an owner field and there are out-of-date owner fields and there's territories that aren't being accounted for.

So maybe you're a sales ops manager and you're going to your leader, your CRO, and you're saying that, hey, we have some user lookup fields that are misaligned that we need to correct. And they're going to look at you with your eyes glazed over. So instead say, hey, we have record owner properties that are not accurate. So we have some BDR owners that are not owners of their leads.

We have some people who have left who are owners and it's causing some misalignment in leads. Because of that, leads are sitting in queues or sitting owned by people who are no longer with the company. And it's taking us a while to find and correct that. We have leads that are not being managed Yes exactly That they can understand and then give a recommendation Because of this we need to reassign all of these leads and we need to do a new mapping of BDR to lead territory so that we can understand what rules need to be in place so that we can mitigate this issue.

Yeah. And then give them who needs to do this. So I'll do the mapping and I will give this to our, say you have an admin, I'll give this to our admin to reassign and I will let the users know that it's happening and I'll do this next week. Yeah.

I think that's exactly such a great point. And I've used similar situations like that, just like that breakdown to explain things because it just helps to sort of paint that picture so that they can understand the pain point you're dealing with without being more confusing, causing more communication. Like you said, with your email, where you had to kind of read between the lines and go back and forth and waste all those efforts of not understanding each other. It just helps to clearly paint that picture and get to the resolution as quickly as possible.

Yep. As an admin or system owner, being technical is very valuable, but being understood is priceless. Yes, exactly. That's perfect.

it's time for coffee talk coffee talk all right this coffee talk is a little bit different today because it is our season two finale we have an exciting announcement so starting season three i will be taking our mission forward without becca yeah unfortunately unfortunately but good things are happening for Becca and me. So we're excited for our next chapter. I'm excited where this podcast will go. Becca, this has been amazing.

Awesome partner. I can't believe we've got through two seasons already. So much fun. Thank you for doing this.

Yes, it's been so much fun. And hey, I might still do some cameos here and there. But yeah, it's been such a fun time. And we hope that all the information we've done together has provided useful tips and information for everybody who's listened.

So it's been a good time. This won't be the last time you see or hear from Becca. I'm excited to have you on as a cameo guest every once in a while. Thanks.

All right. Well, that wraps up our season two of Power Talk. Thank you for all of our listeners. Thank you for our YouTube watchers.

I'm excited for season three. Good things are coming. Yeah. See you next time.

Be sure to like, subscribe, and follow us on all social media platforms. Keep up with us and all of our hot takes on all things go-to-market operations. See you next time.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • From Boba Shop Brainstorming to $1M ARR with Zero Sales Experience - How Sai and Atul Built an AI Roleplay EmpireFounder-Led Sales Stories with Pete Kazanjy · on RevOps91 / 100
  • The Journey to VP of Marketing Ops - Kimi CorriganRevOps FM · on RevOps82 / 100
  • Ep. 193 - SaaS AI Readiness: Why Most GTM Teams Aren’t Ready for AgentsSaaS Backwards · on RevOps81 / 100
  • Field Sales Is Far From Dead - It's EvolvingThe MDM Podcast · on Territory management80 / 100
  • How Greg Went from Zero to $100M Deals with Google & Apple in Just MonthsFounders Podcast · on Territory management78 / 100
  • Why RevOps Shouldn’t Be a Cost Center: Strategies for SaaS Growth with James McKaySaaS Growth Podcast · on RevOps78 / 100

More from Driven Ops Power Talk

All episodes →
  • Ep. 28 - The new era of the MQL
  • Ep. 27 - Let's talk about making AI your marketing power partner
  • Ep. 26 - When security breaches hit your sales tools
  • Ep. 25 - Sales process that works: aligning reps, data and leadership
  • Ep. 24 - Smarter Segmentation Is the Fix for Your Cold Database
Explore the best B2B RevOps podcasts →
All Driven Ops Power Talk episodes →