---
title: "Convert Your Entire CRM to Apex"
episode: 118
podcast: "The LeanScale Podcast"
publisher: "LeanScale"
guest: "Steve Dinner"
guest_title: "VP of Revenue Operations, Owner.com"
date_published: 2026-09-15
date_modified: 2026-09-21
duration: 00:53:13
word_count: 8169
topics: ["revenue-operations", "ai-in-gtm", "gtm-strategy", "sales-leadership"]
canonical_url: https://www.leanscale.team/knowledge/podcast/steve-dinner-owner-com-the-two-week-sprint-is-dead/
source: "LeanScale Knowledge Hub — https://www.leanscale.team/knowledge"
license: "Free to quote and cite with attribution to The LeanScale Podcast."
---

# Convert Your Entire CRM to Apex — Full Transcript

> Episode 118 of The LeanScale Podcast, with Steve Dinner.
> Published September 15, 2026 · 00:53:13 · 8169 words.
> Machine-transcribed and **not diarized** — speaker attribution is inferred, so verify
> attribution against the audio before quoting a specific person.
> Structured breakdown: https://www.leanscale.team/knowledge/podcast/steve-dinner-owner-com-the-two-week-sprint-is-dead/

## 00:00 — Cold open + intro

**[0:00]** You just really run the risk of being left in the dust.

**[0:02]** Steve Dinner is the VP of Revenue Operations at Owner.com and he's back on the show because

**[0:08]** the operating model he walked us through last time is already being torn apart and rebuilt.

**[0:14]** And this conversation is about what's left of the RevOps job when the cost of building collapses

**[0:20]** and everyone in the company can build.

**[0:23]** I'm really at the point where I'm looking at it and I'm saying the build is super cheap now.

**[0:28]** You have this explosion of creativity and people building things on their own,

**[0:32]** shipping things on their own.

**[0:33]** How are you managing RevOps, managing requests that are coming in, managing rogue applications?

**[0:42]** I walk around the floor and I'll see a BDR director who's got a cloud artifact that looks

**[0:47]** just like something that I deployed that's, you know, custom.

**[0:51]** You made a very bold claim that everyone should be converting their CRM to Apex.

**[1:01]** I need to hear where that's coming from because that has gone against every bit of Salesforce

**[1:07]** advice I've ever heard.

**[1:08]** Why would you be stuck to this like Windows XP looking thing?

**[1:13]** I don't think you would.

**[1:14]** Is there any reason anyone would be logging into Salesforce,

**[1:18]** clicking buttons, or should everything be running headless?

**[1:22]** It can run headless or it can run as a custom app inside of Salesforce.

**[1:27]** I don't think it really matters.

**[1:28]** I'll be back on here being like, "I was wrong."

## 01:38 — Why the two-week sprint is finished

**[1:38]** Steve, last time you were on the show, the install you were proudest of was Agile.

**[1:43]** You told me the biggest value that consulting engagement wasn't the project you hired them for.

**[1:48]** It was permanently changing how your team worked.

**[1:51]** A few weeks ago, though, you told me the two-week sprint doesn't work anymore,

**[1:55]** and you're pulling some of those wires back out.

**[1:58]** What happened between the last time we talked to now?

**[2:01]** Well, a lot.

**[2:02]** Obviously, on the AI front, especially, there's just been like a collapsing of skill

**[2:10]** and technical knowledge that's really changed, I think, how you need to operate as a RevOps team.

**[2:18]** And so I would clarify and say that I still think that strong process does create a strong team.

**[2:24]** It's just a matter of looking at the reality of our situation right now and saying,

**[2:30]** "Okay, we need to be anti-dogmatic here about what we're going to hold on to

**[2:35]** and what we're going to throw away."

**[2:37]** And so I have team members who are so in love with the Agile system

**[2:46]** that this has been the way that I've kind of said it is there was waterfall,

**[2:51]** then there was Agile, and Agile was new.

**[2:53]** And it was this thing that was different, but borrowed concepts.

**[2:59]** And I think that it has always been morphing and changing over time anyway.

**[3:04]** And I've kind of said to them, somebody is going to name and write the book on whatever comes next.

**[3:12]** And particularly for a few of my team members who live and breed this stuff

**[3:16]** and who are really, really great at it,

**[3:18]** I don't even particularly consider it to be my personal superpower.

**[3:22]** It's just something that I recognize and believe in.

**[3:25]** There's a few members on my team where I'm kind of encouraging them.

**[3:27]** I'm like, "I want you to be the one that writes the book."

**[3:30]** So let's just take a long, hard look at these processes and ask ourselves,

**[3:35]** "What are the value that each individual component brings?

**[3:39]** What do we keep? What do we modify? And what do we throw away?"

**[3:41]** And so the two-week sprint in particular is an area where I believe that,

**[3:47]** at least for the majority of requests and deployments that you have,

**[3:52]** the way that things are moving, it just doesn't serve the business

**[3:55]** and it doesn't paint RevOps in the right light.

**[3:59]** And so where I used to really rely on that for confidently rolling out really strong,

**[4:06]** tested functional features, I think that you just really run the risk

**[4:14]** of being left in the dust and kind of being viewed in the wrong light

**[4:17]** if you just hold on to these things that no longer serve.

## 04:20 — The build got cheap. Planning and testing got expensive.

**[4:20]** So I'm really at the point where I'm looking at it and I'm saying

**[4:24]** the build is super cheap now.

**[4:26]** If you've got everything set up correctly, a first pass,

**[4:30]** if not the whole thing, can be done with AI deploying to a sandbox.

**[4:37]** Obviously, more complexity when you enter managed packages

**[4:41]** and additional systems into the mix,

**[4:43]** but significantly reduced development time.

**[4:46]** But that means that the areas that you typically wouldn't associate

**[4:53]** as the most important, which would be...

**[4:55]** I mean, you should always have considered the scoping

**[4:58]** and the planning process to be the most important,

**[5:00]** but the not fun part, the testing, all the different various types of testing,

**[5:06]** those now just get more important and you have to highlight them

**[5:09]** and you have to spend more time on it.

**[5:11]** I think that a lot of the AI is just built to do software development

**[5:15]** in the first place.

**[5:17]** So you don't actually have to invest as much time in that.

**[5:19]** There are some quirks around how you develop in Salesforce

**[5:23]** that you can kind of get more out of a cloud or a codex by teaching it.

**[5:30]** But in general, I think the value of your planning system

**[5:34]** and the value of your testing system just went up

**[5:37]** and you have to now invest a lot more heavily in your effort there.

**[5:41]** And so it's really just about building around that.

**[5:45]** And where I think triaging has always existed within Agile,

**[5:51]** I want to see that triaging happening out front

**[5:53]** and kind of by a different mechanism, which is just like,

**[5:57]** what is the likelihood that this can hurt anything

**[6:00]** or cause any permanent damage?

**[6:02]** And if it doesn't, you kind of live in an environment

**[6:05]** where software can be created out of thin air

**[6:08]** and your users sort of expect that kind of experience.

**[6:12]** So where possible, I think I actually want to more deploy

**[6:16]** on the basis of complexity and risk.

**[6:20]** And so I have a risk assessment that's done agentically.

**[6:22]** And based off of that, it's going to go down one of three tracks.

**[6:26]** And I think it's a necessary evolution in how we think about

**[6:31]** RevOps and system architecture.

## 06:35 — What's left of agile, and what gets thrown away

**[6:35]** Specifically in the Agile methodology,

**[6:37]** what are the components that you think really aren't serving anymore?

**[6:40]** Is it the length of time of two weeks?

**[6:42]** Is that too slow?

**[6:43]** Is it the grooming process?

**[6:45]** Is it the rigidity of locking in the sprint?

**[6:48]** Which components feel like, hey, these just don't fit anymore?

**[6:51]** Yeah, I mean, like it used to really be,

**[6:55]** if you're doing this well,

**[6:57]** a P0 is like, you cannot work on anything else while this is still open.

**[7:02]** And that is a business continuity, bug, failure type of a thing.

**[7:09]** And everything else then just falls into this two week bucket.

**[7:12]** Like, can you get this done in two weeks?

**[7:15]** And if it gets done on day three, it sits there, right?

**[7:18]** Like, and you can, sure, you can say, okay,

**[7:20]** I'm just going to still do the sprint, but I'm going to modify it

**[7:23]** so that I'm going to have two deployment dates or something like that.

**[7:26]** I think that's fine.

**[7:28]** And you can solve the problem that way and keep more of what you like.

**[7:33]** But I don't think it addresses the fact

**[7:35]** that everything is mostly treated the same unless it is like a four alarm fire.

**[7:40]** And I don't think it addresses the psychology of your stakeholders and your end users.

**[7:46]** And that is the part that's changing.

## 07:48 — Walking the floor: a BDR director shipping his own Claude artifact

**[7:48]** I walk around the floor.

**[7:49]** We have a huge sales office with basically just sales folks in it.

**[7:55]** And I'll look over and I'll see a BDR director who's got a cloud artifact

**[8:00]** that looks just like something that I deployed that's custom for a different use case.

**[8:06]** And he's just taking a screenshot of it, told the cloud what he wants,

**[8:12]** hit the Salesforce MCP.

**[8:13]** And now he's got an interface that's shockingly like mine.

**[8:16]** And I'll go to the next one and I'll see a personal tracker.

**[8:20]** I'll have like a SDR who's like running around using cursor

**[8:25]** and asking me for an API key for something that I'm unfortunately not going to give.

**[8:32]** I'll see on the TVs like these custom incentive trackers for spiffs and things like that.

**[8:37]** All of this like they know that that can be created.

**[8:41]** And we've just spent years telling them that if they didn't adapt

**[8:45]** and learn to use this technology, they were going to end up jobless.

**[8:48]** So you can't then be hypocritical and sit there as RevOps and say,

**[8:52]** you know what, that's all true.

**[8:55]** But like these systems are still my systems and I'm not going to consider

**[8:59]** the effect that that psychology has had on you and what your expectations are.

**[9:03]** At the end of the day, like the systems are designed to get an outcome from people

**[9:08]** and considering their thought process and their experience

**[9:12]** and what's going on in the world around them is a huge part of that.

**[9:16]** And if you ignore that, then I think that's where you just become the shop

**[9:19]** that nobody asks anymore because they don't think that they're going to get any help.

**[9:23]** Yeah, there's definitely a balance there.

**[9:25]** I think what it feels like is what maybe Google Sheets and Google Slides

**[9:32]** might have been a while ago.

**[9:34]** Like no one would ever say, hey, you're not allowed to use Google Sheets

**[9:38]** because you're in sales or you're a BDR.

**[9:40]** So I don't want you using slides and building your own presentations.

**[9:44]** Now, there might be a difference between whatever they're building

**[9:46]** and the board deck and the financial model that you're running the business on.

**[9:51]** But it doesn't mean you should lock the tools down or not give some access to the ability.

## 09:57 — Rigid business logic, democratized experience layer

**[9:57]** All right.

**[9:57]** Well, I mean, like most people don't know it, but if you're on a lightning page,

**[10:01]** you can go edit page for yourself right now.

**[10:03]** Like that, like it was always built that way.

**[10:08]** Is it user friendly enough that anyone does it?

**[10:10]** Absolutely not.

**[10:11]** But I think like the concept should be that you want to be really rigid

**[10:15]** about your business logic and any of the plumbing.

**[10:19]** And you want to be really experimenting with ways to democratize your experience layer,

**[10:26]** like your application layer and your logic and everything like that.

**[10:29]** There's a certain degree to which you just like can't let go of the reins on that.

**[10:35]** And your experience layer has like become something that you have to find a way to democratize.

**[10:41]** So like even just like take inspiration from something like Vercel,

**[10:47]** which like is designed for this, like, OK, any old user for any little use case, host something.

**[10:53]** Like we have like an internally built version of that that does exactly this

**[10:57]** because you know that the sprawl of shadow IT is going to get huge

**[11:01]** if you just like don't give people a way to host things.

**[11:05]** So if you can at least bring it into the fold and allow for that creativity to flourish,

**[11:09]** and then you can kind of peruse through and say, oh, man, look at that.

**[11:12]** That one's really special.

**[11:14]** Everyone should be using that easier said than done.

**[11:17]** And I think it kind of goes nicely into our next point,

**[11:21]** which is like in order for that to happen, then you need to be able to address any of the,

**[11:28]** you know, less experienced layer stuff really quickly and efficiently.

**[11:34]** So like the not so flashy stuff, your business logic, your processes

**[11:41]** and automations and things like that that the business actually wants.

**[11:45]** You have to be able to do that work confidently and thoroughly on a quick timeline

**[11:51]** so that you can also have enough time to be forward looking about some of this other stuff

**[11:58]** because it's always going to be a constant priority battle.

## 12:04 — The new model: two gates and one custom app per role

**[12:04]** >> So I know the book is still being written.

**[12:08]** So there's probably some unknowns here, but knowing, hey, there's some restrictions in Agile,

**[12:13]** some things that aren't really serving anymore.

**[12:16]** You have this explosion of creativity and people building things on their own,

**[12:19]** shipping things on their own.

**[12:22]** How are you managing RevOps, managing requests that are coming in,

**[12:29]** managing rogue applications that might be going against something else?

**[12:32]** What's the new method that you're using to manage the function?

**[12:36]** >> Yeah, still under construction is certainly correct.

**[12:41]** But the concept and actually there's like an epic on our board that has,

**[12:46]** I want to say like 27 or 37 individual user stories.

**[12:51]** And the first, I think it's 37 and the first 30 are like pretty routine

**[12:58]** security governance tech debt stuff. And then the last seven is where you unlock

**[13:04]** the ability to democratize these things.

**[13:08]** So I'm not going to sit here and pretend that there isn't a pretty substantial investment in

**[13:15]** very traditional things.

**[13:17]** So we have a solution architect who wrote all of those.

**[13:23]** In terms of like what changes day to day, I think the way that we're imagining it is like,

**[13:29]** actually I use like the personas on my team.

**[13:32]** I have one person who is like really good at beating the crap out of a brief and saying like,

**[13:40]** why does the business actually want this?

**[13:42]** No, no, no, why do they actually want this?

**[13:45]** Not that's actually just trying to tell me the answer.

**[13:47]** No, I have to get to the Y, I have to get to the Y, I have to get to the value.

**[13:51]** And I basically want like an agent version of that person that has seen the comments

**[13:59]** and has the transcripts of that person ripping apart briefs.

**[14:04]** And I want that to be gate number one that you have to pass.

**[14:07]** I want gate number two to be the architect on the solution design.

**[14:12]** And then overall, I think one of the directions that we're moving that is going to make it easier

**[14:18]** to enable this is just kind of going to be one custom app per role.

**[14:22]** So like if you're an SDR, if you're a BDR, if you're a account executive,

**[14:25]** you're a launch specialist, integration specialist, strategic CSM, whatever,

**[14:31]** we create an environment where there is an experience layer that is fully custom

**[14:36]** that can be modified without touching a whole lot of like metadata or business logic.

**[14:42]** So we create this like reality where there is something to modify that doesn't touch it.

**[14:49]** So that allows you to then I think, focus on triaging.

## 14:55 — Three tracks: skin, metadata, project

**[14:55]** So our triaging becomes, hey, do we just want to update the skin basically of any of these custom

**[15:01]** maps? And you can verify that it's not going to hurt performance.

**[15:04]** And it's not going to touch any, any metadata or flows or business logic

**[15:09]** and doesn't create a security issue. It just like in a request that meets that criteria

**[15:15]** and passes the two other gates can just go straight to develop, you know,

**[15:20]** like it hits the board overnight, someone develops it, someone has a look at it, pushes it out.

**[15:27]** Or like it passes some testing gates and it gets pushed out.

**[15:29]** And that would be like your happiest of all happy paths.

**[15:32]** And we had kind of create the environment for that happy path to exist.

**[15:35]** And then the second one is like a tiny metadata update that isn't like a huge deal.

**[15:40]** And you're still going to need some human, you know, in the loop for that one.

**[15:44]** And but it's still gonna be much quicker and it's kind of on demand.

**[15:48]** And then I think the third one are like, these are these would be things that contribute to like

**[15:52]** projects. And that might more closely resemble just the normal agile process that we're doing today.

**[16:02]** In that we're probably not racing to deploy those in piecemeal.

**[16:11]** But I do think that from inception, there's still opportunities to actually put a lot more

**[16:18]** emphasis on the upfront. Why are we doing this? What problem is it solving? What number does it

**[16:22]** need to move? Okay, what is the design principle that we need to meet so that the development

**[16:28]** process is super quick, and then we can be extremely thorough with testing and rollout

**[16:33]** and communication. So I think that like, just like without that center part eating up your

**[16:39]** the big projects, and a lot of the time, it like affords you more opportunity to do the other stuff

**[16:44]** better. So these first two categories, I think are where the real difference is. So it's almost like

**[16:49]** I kind of have like regular agile, then I have another one or two stacked on top of it is maybe

**[16:56]** a better way to think about it. Yeah, I like that a lot. There's still going to be some big ones,

**[17:01]** like a major quote to cash overhaul, if you're migrating CRM or something, like you're not going

**[17:06]** to be able to ship all that out in a couple days. But some of the things that maybe used to be a

**[17:10]** two week timeline could probably be a day. And you could set up your agent system to do the testing

**[17:15]** really well. So I think dividing those like yeah, it's run that like a traditional project or no,

**[17:21]** put that one in the fast lane, we can just crank that one through. Yeah, exactly. I do think like

**[17:26]** something healing progress is important to the people that you're shipping to. And so you create

**[17:31]** an environment where they can feel progress. I think that's what really been missing. Like it's

**[17:37]** been challenging to like, if you have an update that you want to make for one type of user,

**[17:46]** one little thing, it's a tiny quality of life improvement, like needing to slot it in and,

**[17:53]** and have it stack within everything else that you have to get done, like it's so easy to get the

**[17:58]** can kicked. But like if someone just submits the request correctly, and it's passes two gates,

**[18:04]** and there's a place in the CRM, a custom map for it to land at the experience, and it's just the

**[18:08]** experience layer. So like, there's no risk to this going out, basically. And an agent can develop it

**[18:14]** and then kind of like one person just has to go, Yep, and it's out. Right? Like, what that means to

**[18:21]** the people on the ground, I think it's like pretty meaningful. And they are the ones that are driving

**[18:26]** the revenue in this, in your business. So it matters. It's interesting you say that because

**[18:33]** it's really similar to how we work with customers. We have projects and then we have ad hoc. That's

**[18:37]** how we explain it. And you have your architect, that's the main point person that you work with

**[18:42]** here at LeanScale. And then you have a project engineer, they're working on the big stuff,

**[18:45]** the big needle movers. And then you have an ad hoc engineer, the simple stuff. And we always say

**[18:50]** the ad hoc is where you win hearts and minds. So it's that, oh my gosh, they turned this around in

**[18:58]** 10 minutes. Oh my gosh, they flipped it around today when I thought that was going to be a

**[19:01]** multi-week thing. And they just were super responsive. And then the projects are where

**[19:06]** you move the business forward and you're proactive. Yeah. And you know what, like maybe the ask is the

**[19:13]** wrong ask, but the way that your intake works, the way that our intake works at least is like

**[19:18]** trying to get to like, what is it that you want to see change as a, like, which is, you know,

**[19:25]** very well handled and agile. I want to, so as a, I want to, so that I can.

**[19:32]** And if you're doing a good enough job with that, like your first agent might stop someone in their

**[19:37]** tracks and be like, oh, like this isn't actually, you've asked for this, but what we actually want

**[19:43]** is this. And so you can actually have this whole like loop where something meaningfully is deployed

**[19:50]** that has been kind of argued. But it hasn't like taken up a bunch of your team's time like it

**[19:56]** normally would. Like a lot of the time you get an, if there's an intake process, the flaw in the

**[20:00]** intake process, I think is like the asynchronous element of it leads to like this weird scenario

**[20:06]** where as RevOps you're reading it and you're just being like, what? You think that is going to, no.

**[20:12]** And so you kind of like half of that ultimately kind of, I think come together most of the time.

**[20:18]** But yeah, no, I think like the whole point of this is like your users' expectations and

**[20:24]** understanding of what is possible in technology has changed. They are the ones that are, you know,

**[20:32]** pulling the rope for your business. And I always want to be focused on them and how I can make

**[20:41]** them feel like they're well equipped and respected for the job that they do. So even though, you know,

**[20:50]** you might say, oh, Steve, like an experience layer update, if it can go out without impacting

**[20:54]** anything, like it's unlikely to be that big of a deal. Like I would disagree.

## 21:03 — Does AI shrink the RevOps team?

**[21:03]** In this new era, are you seeing the need for more RevOps or is the efficiency allowing you to run

**[21:13]** leaner in compared to your overall go to market investment as before?

**[21:20]** I mean, I think the same is true of RevOps as it is anywhere. Like there was no real

**[21:27]** AI jobs apocalypse. Everybody just works longer, harder, saw that they could capture more territory.

**[21:35]** So the more that you have available to you in headcount is just more territory that you can

**[21:44]** capture more, more that you can get done. I think that it's allowing us to think in

**[21:55]** scales that we weren't able to before. I think it's allowing us to

**[22:04]** put down plans to service end users in a way that like we used to kind of only wish we were

**[22:10]** able to. And I think that it's also probably if you're going to continue to hire the same way,

**[22:20]** give you an opportunity to like, reduce some of your software spend in very like strategic places.

**[22:27]** I really think that you just sort of end up with more people who can

**[22:36]** manage projects all the way through and do a significant amount of the actual work. And so

**[22:43]** it kind of fits the principle that I had in the first place, which is like, I want people who

**[22:49]** can be strategic thinkers, understand the technology, but I'm not actually hiring them

**[22:56]** to be the ones to do all of the development work. That has like aged quite nicely. Like the more

**[23:03]** people that you have that can see a problem, diagnose it, design a solution, co-design a

**[23:11]** solution with AI, write up the scope. And then you're just kind of like, basically on the doorstep

**[23:18]** of like, okay, prototype it, like your PO in my environment can get to a point where

**[23:25]** any dream that they have become something that gets prototypes. And then we're storing all these

**[23:30]** prototypes, you know, whether we use it as is or not, in our knowledge base, as something that

**[23:37]** we can always draw on. That's like almost like a library or a recipe of services that we can

**[23:42]** always kind of come back to. So yeah, no, I don't think the need for RevOps reduces. I think perhaps

**[23:52]** where some of your allocation lies changes. Like I would probably not continue to hire

**[23:57]** offshore devs, like probably good, because the ones that I have, I can similarly supercharge.

**[24:04]** And then so any capacity increases are able to be met. You know, obviously that

**[24:10]** reaches a scaling point as well. But yeah, and if more work is delivered, then you need more

**[24:18]** people on maintenance. You need more people on refactoring. You need more people on testing.

**[24:24]** So I haven't seen, I haven't seen any opportunity to like,

**[24:27]** reduce the team and still produce the kind of output that I want to be producing.

## 24:32 — What becomes possible when three months turns into a day

**[24:32]** Yeah, no, it makes sense. I'm not, I'm not seeing that either. In a lot of ways, I'm seeing

**[24:37]** maybe even more investment in RevOps because before the scope of what was possible was

**[24:46]** relatively limited. There were things that I had in my mind all the time. I would love to be able

**[24:49]** to do. Oh, I'd love to build this. I'd love to run this analysis. I'd love to build a model for that.

**[24:54]** But immediately I would disqualify because I'm like, well, that's going to take

**[24:58]** three months to do and I can do it. And now I can get that done in a day. So

**[25:02]** the possible things I could work on today have gone through the roof. And I think people are

**[25:09]** seeing that a lot. One thing this leads to though is, and I know heads of RevOps are always

**[25:17]** in this tension with maybe CRO or CFO, is how much you should be investing in RevOps. So I think

**[25:27]** it's pretty clear. Like an investment in RevOps does a few things. When you get the GTM telemetry,

**[25:31]** you know exactly how things are working, what's going well, what to double down on, what's not

**[25:35]** going well. You are increasing conversion rates, decreasing time and stage. That at scale can mean

**[25:44]** millions, if not tens of millions. But what's the right level of investment? How do you

**[25:50]** have that conversation with your CRO, CFO when you're asking for more resource?

## 25:59 — The RevOps ratio: 15:1, 25:1, and the 29:1 problem

**[25:59]** I think really you have to be able to sooner or later establish some sort of a baseline ratio

**[26:09]** as like a starting place for this conversation. And then any deviations from that end up

**[26:18]** tying to particular metrics. Do you have any ratios that have worked well for you in the past

**[26:26]** that you like to use or even just some general guidance?

**[26:34]** I would say that in my experience, it's actually

**[26:43]** heavier ratio the further down the market that you are. If you're like an enterprise startup,

**[26:54]** you can do a lot with one really talented person. If you've got somebody who's like

**[27:04]** like a technical RevOps person, strategic mind, you can do a ton with one person. You can get to

**[27:12]** probably your first 30 or 40 reps, I bet, with AI. But that's an environment where

**[27:22]** the end of deals to hit your target is quite low and you can have one deal that makes your

**[27:31]** quarter, makes your year. The inverse scenario is one where that's impossible and basically every

**[27:39]** customer needs the same treatment and is as important as the one before it, which is closer

**[27:45]** to where we are at owner, like a fixed subscription price and some take rate. But ultimately the ACVs

**[27:54]** don't vary all that much. So there's not really like, "Oh, that one deal can save the year," which

**[27:59]** means you have to be technically excellent everywhere. And it means that the denominators

**[28:06]** in all of your conversion rates are quite high. So there's just the degree of excellence that you need

**[28:13]** at the number of places in the funnel, I think requires a much closer and much tighter ratio.

**[28:21]** So it's more of a like 20 to one type situation or 15 to one even. And it can probably expand,

**[28:31]** but I remember doing this exercise and seeing that we had gotten to 29 to one and being like,

**[28:39]** "Oh, that is a big problem." And we were feeling it and right sizing that. So I think it like

**[28:45]** probably starts out more ideally at like a 15 to one and then you can probably get more into like

**[28:51]** the 25 to one when you're a little bit bigger. But again, I guess it would reach a point where

**[29:02]** the specialization and the scale are going to have to kind of like flatten out somewhere. So this is

**[29:11]** more like startup experience I would say. Yeah, I think that makes sense. The more between enterprise

**[29:17]** SLG to I'll call it PLG or high velocity SLG, you would need a higher ratio of ops to overall

**[29:26]** good market spin, sales, marketing, et cetera. And then as you scale, then that ratio should start to

**[29:33]** go down as you get leverage out of the team that you have. Yeah, I think so. Because if you've got

**[29:38]** good people, one of the hardest things is to get terminal velocity in a sales group. You can have

**[29:47]** your first set of sales, who's that person who comes in, proves it out, carries a bag,

**[29:53]** hires the first couple of people, gets maybe to a team. Eventually, you're going to hire a more

**[29:58]** senior leader. But there are a bunch of events on that mountain that you've got to reach these

**[30:07]** thresholds. Otherwise, you don't really get to that sales culture terminal velocity. And I think that

**[30:15]** being able to nail the development of your RevOps team according to that scale

**[30:25]** is really helpful in trying to reach that point because you're introducing opportunity for

**[30:30]** repeatability and for playbooks and for reliably being able to bring on and rent new people.

**[30:37]** I would say the same for enablement. It's kind of hand in hand.

## 30:42 — How to pitch a CFO for budget

**[30:42]** For a head of RevOps who's putting their pitch together for more budget, more resource, they

**[30:48]** know in their head what they need, why they need it. How do you recommend they pitch that to their

**[30:53]** CRO or CFO or navigate that process? I mean, the only way is to speak their language.

**[31:05]** Find that you have a natural alliance or opportunity to build goodwill with the

**[31:15]** finance team as RevOps because of just how much the sheer number of dollars that run through you

**[31:21]** or that you have some ability to affect. For me, I always make sure that this starts

**[31:30]** way before the ask, which is be as good of a partner to finance as you can be. Heads up.

**[31:38]** This technology, this software spend, I'm actually going to swap it for this one,

**[31:42]** which is cheaper. So you can expect me to come to you with these two contracts instead of this

**[31:48]** big one or this one instead of these two. I think it starts early. There is the relationship trust

**[31:55]** building element of it first. I think it's a challenging position to be in to have your first

**[32:05]** serious dollars and cents conversation be the ask. I do everything I can to make the first

**[32:10]** dollars and cents conversation I have being me protecting the budget and then kind of establish

**[32:17]** yourself as a serious person who's thinking about the company's goals at large rather than

**[32:24]** simply just asking and being another person with their hand out, so to speak.

**[32:32]** I'm sure that every RevOps person in the world would say, "Okay, you have to tie this

**[32:39]** spend to ROI and you have to speak their language." My, I guess, more behavioral social

**[32:48]** advice though, is don't make that the first time that they've talked to you about dollars and do

**[32:55]** what you should do and be a good steward of the company's finances and establish yourself as

**[33:01]** somebody credible on that basis and that'll go a long way. I think it's really, really good advice.

**[33:10]** Then any head of RevOps that's going into a budget season or has that tension happening right now,

**[33:16]** I think that's helpful. Yeah, don't wait until the budget meeting for it to happen.

**[33:20]** Just imagine being the CFO and how many people are just asking, asking, asking.

**[33:25]** But you're right, you do have an opportunity to build that relationship. They want a clean

**[33:29]** forecast to run their models on, so if you're helping get them what they need and I think it

**[33:35]** makes a ton of sense. Not a lot of roles actually do have that opportunity to go and make the CFO's

**[33:42]** life a little bit easier. So take that opportunity. I love it. I'm going to transition a little bit.

## 33:51 — The Apex heresy

**[33:51]** You made a very bold claim that everyone should be converting their CRM to Apex.

**[34:02]** I need to hear where that's coming from because that has gone against every bit of Salesforce

**[34:07]** advice I've ever heard. People are sharing out in the market right now, so this is a huge

**[34:13]** turn from where people are thinking about their systems now. Why are you saying people should

**[34:19]** move to Apex? Yeah, I mean, it's like intentionally inflammatory. I say that as an attention grabber

**[34:28]** and actually this whole thing started, well, I mean, I guess privately I had the thought

**[34:33]** really early in the year when I built my first custom Salesforce MCP with just an external app

**[34:42]** and I was just sitting there being like trying stuff and noticing like a lightning layout.

**[34:51]** It doesn't do so well. You can't do UI stuff and flows. You can make a new small flow, but if you

**[35:00]** want to edit a huge flow, it's not super great at that, but Apex nailed just creating modifying

**[35:08]** metadata crushed. It really did really, really well. I was talking to Claude and it was just like,

**[35:14]** hey, look, that's XML underneath all of that stuff, the flows and the flexi pages.

**[35:22]** It's really long. It's verbose. It's not quite code, so I really struggle to know if it done

**[35:27]** it right. I can't really verifiably do this. You'd get it to do like really challenging stuff and

**[35:34]** then it would be like, and then seven steps for you at the end and they're all just like silly UI

**[35:39]** things or whatever. At the time I was hiring for a architect and I decided that after allowing some

**[35:49]** of my other teammates on the panel to grill them about architectural principles and stuff for a

**[35:54]** while, I would make this ridiculous claim and then just watch how they reacted. Really what I was

**[36:00]** trying to do at the time was get a sense of whether this person wanted to create the future

**[36:06]** or was comfortable hanging back until someone else had crossed the chasm, so to speak.

**[36:15]** Almost to a person, they were reacting similarly to what you were saying because the question

**[36:22]** was just like, hey, if I want to change the whole CRM to Apex, because I believe this,

**[36:27]** that it's easier for an LLM to actually then just manage the whole thing like you would a code base.

**[36:34]** What would you say? Most of them, the objections were, do you lose the visibility or easy things

**[36:44]** aren't able to be quickly fixed by a human or things like that. Things that I found to be

**[36:52]** an uninspired interpretation of this. If you want the visual documentation that a flow provides,

**[36:59]** build an SOP. If you create an automation that you have to use mermaid and create a diagram and

**[37:06]** store it wherever you want to store it. That's actually more in your principles for how you

**[37:11]** manage your LLM and your builds. Eventually, I found somebody who had a really

**[37:21]** interesting answer, which is that you wouldn't really necessarily run towards it, but you might

**[37:25]** start solving new problems by doing this anyway. Eventually, you run into race conditions and

**[37:31]** timeouts and things like that, that a large enough flow doesn't work. For the record, I was the same.

**[37:39]** I would actually just force someone to really argue with me as to why I should allow any Apex

**[37:45]** into my system, because I had had the experience and known about previous instances that I was not

**[37:51]** in charge of, but had worked in that had been 100% Apex and had caused a nightmare.

**[37:58]** I was the same way. I don't know. The Salesforce, we love admins days, quietly going away. I really

**[38:07]** think that you aren't going to go in and make a super quick change in your CRM anymore anyway.

**[38:15]** You're going to do this via CLI and an LLM is going to do it for you. I have been operating

**[38:23]** and moving towards a system that allows my team to be operating that way for a while now.

## 38:30 — Handing an LLM the gnarliest flow — and it finds two bugs

**[38:30]** For fun, I just actually not too long ago asked it, "What's my gnarliest flow?"

**[38:38]** It gave me something about one of our activities, because the principle of one trigger type per

**[38:46]** object. I just found one of my activity flows that was particularly nasty. I gave it free range to

**[38:53]** just try and totally wipe it out and create it with Apex. I just put on Fable and said, "How about it?"

**[39:02]** It was interesting because there are nuances and you would just hit, "Okay, sounds good," but it

**[39:09]** got through a significant amount of the testing and was able to actually find two bugs in the

**[39:16]** flow. It was like, "I can't replicate these because I don't think that you actually want this to

**[39:20]** happen," but it took a matter of hours. I think that if you were able to do that and get to a point

**[39:30]** where your CRM was all code, so therefore you didn't spend a whole bunch of time in setup

**[39:37]** going through and doing things manually and clicking buttons and typing stuff in,

**[39:44]** then I believe that you would be able to manage your business logic and manage your

**[39:51]** critical pieces of the CRM backend more effectively, which is what gives you the time to do some of

**[40:01]** that front end stuff that we started the podcast with. I think that those two things need to happen

**[40:07]** together because if they don't, you're asking for blood from a stone. If you want to be managing

**[40:14]** this super progressive experience layer that's democratized and things like that and super custom,

**[40:22]** it's easier to do that than it's ever been, but it doesn't hide the fact that you still got all of

**[40:28]** these tech debt and/or less flashy things that you have to do and things that are

**[40:38]** needing adjustment all the time. So I think in order to free up the resources to do things that

**[40:48]** will drive impact because they will improve and change behavior, this is probably a necessary

**[40:56]** step. So it's not a drop everything and convert all your stuff to Apex. It's more of a, "Why wouldn't

**[41:02]** you start?" Because on a long enough timeline, can you really imagine yourself going through

**[41:10]** clicking through Flow Builder or can you really imagine yourself

**[41:15]** going through and using a Flexi page? That's so obviously not the thing. You can just design

**[41:22]** whatever you want, get 10 iterations of it, hit deploy. Why would you not do that? Why would you

**[41:30]** be stuck to this Windows XP looking thing? I don't think you would. I don't think so either.

**[41:38]** And it's so ironic that Flow is what made everything so easy compared to what you were

**[41:43]** doing before. And now it's like running through molasses when you're trying to build things.

## 41:50 — A year out: does anyone still log into Salesforce?

**[41:50]** I'm curious, fast forward, extend it a little bit, maybe go a year out from now.

**[41:57]** Is there any reason anyone would be logging into Salesforce, clicking buttons, manually logging in

**[42:03]** opportunities and notes, or should everything be running headless?

**[42:10]** It can run headless or it can run as custom app inside of Salesforce. I don't think it really

**[42:16]** matters. I think that obviously their thought is that Slack would be the front end, which is

**[42:24]** something I thought for some time as well. I think, yeah, to me going fully headless is less

**[42:36]** the only way as it is one of the ways. This is really just about like, can you put the data in

**[42:43]** front of people, the data that they need to do their job better? Can you put it in front of them?

**[42:48]** If you can put it in front of them inside of Salesforce, great. I don't know, maybe you don't

**[42:52]** need to go headless. If you can't, maybe you want to put it into some sort of a headless format.

**[42:59]** It's really just all about the outcome. Will they log in? I think it depends. There's also this

**[43:06]** interesting, it's not really a phenomenon, but it's a behavioral thing again that I believe I heard.

**[43:20]** It was a different RevOps leader, I can't exactly place it, who was having all the

**[43:25]** medic fields filled out from transcripts. They actually turned it off because they found that

**[43:34]** the reps didn't know their deals because they didn't have to do that.

**[43:38]** Now, I think there's a balance there. Do I really want to force field entry

**[43:45]** just as a deep thought exercise, or is there another way for me to do that?

**[43:55]** I'm unsure. I do, however, think that if you could autopilot sales, then you would.

**[44:05]** There is something special about the salespeople, and there is something special about your

**[44:10]** implementation team and your CSM team, and people want that. The question is not necessarily for me,

**[44:18]** how do you make all of it go away? How do you maximize your outcomes? It's always actually

**[44:23]** about that. If I could get better outcomes with a pen and paper than I could with Salesforce,

**[44:31]** then I would use it. I totally understand. I just leave room for the fact that I still need

**[44:52]** my people to be doing what they do best, and I still need to be considering what workflow creates

**[45:01]** that environment. I don't necessarily think—because I think what I'm getting hung up on is what you

**[45:12]** asked was managing opportunities. I'm like, "Yeah, kind of, right?" Now, should it be easier than

**[45:18]** before? Should maybe I have a custom app on their phone where they can do a Tinder swipe and put

**[45:27]** things in and out of forecast? Sure, maybe. Can I make this as cognitively light as possible? Sure,

**[45:33]** but where I need their attention, I think I still very much need their attention.

**[45:39]** That's really the concept, and it's always been the concept. We always call them revenue-generating

**[45:45]** activities. If there's a revenue-generating activity, that's what I want to rev doing,

**[45:50]** and anything else, I don't. But sometimes, I think that there's a need for

**[45:56]** the deep understanding of the situation to still be left with the rep as opposed to auto-filled

**[46:07]** or auto-managed. It's a fine line. I leave the door open a little bit there.

**[46:13]** Yeah, tailoring it to the team and the things you need them to do. I'm just wondering,

## 46:18 — What is Salesforce actually worth now?

**[46:18]** I think a big part of the value that Salesforce originally brought was an easy way to manage your

**[46:28]** pipeline, an easy way to manage your forecast, a UI that helps people operate well, a data model

**[46:34]** that organizes and structures things well. I'm just wondering what the value is. I'm not

**[46:39]** recommending anybody rip out Salesforce today. I'm just trying to forecast a couple years out.

**[46:45]** What is the value of having something like Salesforce versus maybe, I mean,

**[46:52]** is it essentially just turning into a data warehouse or is there more to it?

**[46:59]** I have been thinking about that for a while now. I'm kind of wavered here and there.

**[47:08]** If you kind of look at Oracle as a predecessor to Salesforce and you could have maybe thought,

**[47:18]** maybe Oracle gets, maybe if you were 10 years ago, you'd be like, "Oh, Salesforce is going to make

**[47:23]** that company less valuable." Well, no, Oracle is more valuable than it's ever been. I think

**[47:27]** it survives in a way. It's just sort of a matter of how do cutting edge startups continue to use it,

**[47:35]** do larger legacy customers, regulated industries, things like that. They still

**[47:41]** tend to continue to use it almost certainly. At the same time, what they're doing right now,

**[47:52]** I don't know if I would do anything. I commend it. I think it's pretty bold for them and pretty

**[47:58]** brilliant. They're not holding you back from they're embracing MCP and CLI. Their acquisition

**[48:10]** strategy this year has certainly been around specialized agentic use cases. I think more than

**[48:18]** ever, the platform and the tools and the way that they're investing is very open. There's a decent

**[48:27]** likelihood that to your earlier question about headless, that move in particular kind of just

**[48:33]** maybe allows them to shed some of the legacy code that they would have had to build something

**[48:39]** beautiful on top of and say, "Hey, don't worry about all that. You guys handle that,

**[48:44]** this interface piece. Here's all this agent infrastructure that we have available."

**[48:52]** I don't know. As far as this goes, it feels like they're handling it so well.

**[48:58]** Yeah. I'm not asking because I have an answer. I'm asking because I'm genuinely curious what

**[49:03]** other people are thinking. Not that it matters. People like us will just pivot and ride whatever

**[49:11]** wave is happening, but I was just curious. At the core, what's the value of it?

## 49:19 — The most AI-friendly CRM there is

**[49:19]** At the same time, I agree. I do think they're handling it really, really well, but before,

**[49:22]** I would have said it's for an early stage company. There's a certain threshold where I say, "Hey,

**[49:27]** you should always be on Salesforce." The early stage company, this is a bit of a coin flip.

**[49:31]** Like, "Yeah, you could go up spot. You go to Salesforce. It won't matter that much."

**[49:34]** Now, even for an early stage company, we say, "Well, if you want a CRM that you can unleash AI on,

**[49:40]** you should go to Salesforce. It's the most AI-friendly CRM there is."

## 49:46 — Where Steve goes to learn

**[49:46]** Steve, this has been awesome. One last thing. I'm just curious. There's so much happening. I mean,

**[49:56]** I'm deep in this, and we work across multiple companies, and it still feels like it's hard

**[50:01]** to keep up with everything that's going on. Where do you tend to lean in to learn,

**[50:06]** get your information from, and get a perspective on what people in RevOps should be doing?

**[50:14]** Yeah. It's certainly a mix. A lot of my algorithms are obviously tuned to this,

**[50:22]** so it serves up to me quite a bit. I definitely have a small group of people that I respect and

**[50:31]** make a point of trading ideas with, and so they come back to me in kind.

**[50:41]** There's a flourishing community of these RevOps substacks, podcasts, things like that,

**[50:48]** as well as around certain technologies. Anyone who's a clay person by design,

**[50:55]** I'll peek over the fence and see what they do. As much as anything, to be quite honest,

**[51:07]** I feel like if I am actively looking at the most serious people in terms of folks who use

**[51:19]** AI for software development, and then I'm trying to read the tea leaves on how I can apply it,

**[51:25]** because it's not quite designed for us, but also someone talking about what they're doing

**[51:33]** in RevOps is kind of typically lagging because they've had to see something, figure out how to

**[51:39]** use it, prove that it works, and then tell you. I'm always actually trying to look a little bit

**[51:44]** upstream, and so that ecosystem tends to be Twitter, to be honest.

**[51:53]** I love it. I love it. Yeah, it's hard for me to shed the Twitter brand, too.

## 51:59 — Wrap

**[51:59]** Well, Steve, thank you so much. It's always a pleasure having you and just picking your brain,

**[52:03]** and I love how forward-thinking you are, how proactive you are, and just really setting the

**[52:09]** standard of what modern RevOps looks like. Everything you shared today, I think, is

**[52:15]** really, really helpful for anybody listening. Moving away from Agile or at least shedding the

**[52:21]** parts that aren't serving anymore, and I think the way you're prioritizing things between

**[52:26]** projects and smaller requests and having a different execution cycle for both of those,

**[52:30]** I think, is really, really impactful. Then following the trend of, "Hey, LLMs are

**[52:35]** really good with code, so why hold it back from building code in your CRM?" I think it's really

**[52:41]** thought-provoking, and I'm actually pretty confident it's the right move. Thank you for

**[52:46]** sharing everything. I'm really, really excited to follow everything that you do, and also just can't

**[52:52]** wait to see what you do next. Thank you so much. It's a pleasure being here. I'll hopefully do it

**[52:57]** again soon. I'm sure there will be new things to talk about in the next couple months, at the very

**[53:03]** least. I'll be back on here being like, "I was wrong."