Session 4

Hey, everyone. Welcome. Welcome.

I hope you are doing great this morning, afternoon, evening, depending upon where you're joining us from.

Welcome back.

We have made it to our fourth session, the halfway mark. Brian and I were just talking about that we have made it halfway, and it's crazy how quickly it came, but it's also a beautiful thing.

That leads me to my thought. We will discuss this and we will share this news, but we are not going to have a live class next week due to the fourth of July in the United States. So just note that we will not be here. You can catch up on recordings during this time.

We will reconvene on, Wednesday, July tenth for our final half, the back half of our courses. Just wanted to notate that. If anybody has any questions during today's class, please don't hesitate to reach out to me. And, Brian, I will pass it over to you.

Welcome back. At this point, we're all old friends, so I don't have to do a deep intro.

Yeah. Thanks, Allison. I appreciate it. Everyone, thanks again for joining. We'll give it maybe sixty more seconds, and then I will hop in and get started.

Alright. We got several more people joined. So, let's go ahead and get started. And once again, thank you guys all for joining.

Go ahead and share my screen, and we'll get, rocking and rolling.

Alright. Everyone can see my screen and can hopefully hear me. Allison, can you confirm you can see my screen?

Sorry. New button disappeared. Yes. Looks great. You you changed the slide presenter mode. We can see the Sure.

Yep. But it looks great. Thank you.

Alright.

Alright, everyone. Today is session four, as Allison said. Today, we're talking about two different topics. First, it'll be, all around your CRM as a product, not a project.

And then second, we'll talk through how to adopt it and go through some adoption frameworks.

Class logistics, as, Allison said, no class next week. So use that time to catch up on recordings or, adding specific details to your workbook. And then this is kinda after today will be the halfway point. And so sessions five through eight are July tenth, through thirty first, and we'll wrap up right in time, for August.

I did have some questions on some feedbacks just to kinda be just to kinda over communicate. The final exam's gonna be short. I'm not gonna make you guys do a hundred question, you know, super tricky exam. It'll be twenty to four twenty five questions, true, false, and multiple choice.

So please don't stress out about the final exam. You guys will all be fine. It's really because the workbook is more important. That's where all the actionable insights are.

That's the that's where you're really applying these, things that you've learned to your business. And so we will have final exam. It is a requirement that I need to create, but just know that you guys will be totally fine with it.

Secondly, keep the feedback coming. All of your feedback is anonymous, so don't worry about me knowing who you are if you post it. But, Allison sends out feedback surveys after every class. We had really good engagement session one and two, but it kinda fell off after session three. So please, fill out that feedback survey. It doesn't take that long, but it provides me a ton of, insight into how I can improve personally going forward.

So once we end today, we'll have gone through the business model, the data model, the go to market motions, and then we'll we've also talked about primary KPIs, secondary KPIs, and then the revenue inject diagnostic.

After today, talking about CRM as a product and adoption, the topics still to cover are are around project scoping and change management.

Then we'll talk through rev ops maturity levels and quarterly business reviews.

We'll talk through hiring a plus rev ops talent. And then finally, like, the RED, revenue engine diagnostic presentation, and tie in everything together. So that's just kind of a look ahead on kinda where we are and where we're going.

Okay. So, again, today, there's two topics here. Kevin's already got me on the workbook. I'll just stop there and do that, hop in. So, the workbook, I'll go ahead and put the link in the chat. And then as always, what I like to do is just take the specific slides from this week and then copy them into kinda my my master course workbook. And so they should just copy right over.

And so looks like we got thirty one slides, and we got we'll go through the workbook sections today. So, hopefully, Kevin, you can, access that. Alright. Alright. Let's talk through the first topic today. This is all about your CRM as a product, not a project.

End of this class or end of this part of the class, talk through why your CRM needs to function more like a product instead of a project, go through product enhancements to find what an MVP is, feature release product launch, and then talk to the product owner. Where does rev ops fit into this, and how can you as a rev ops professional or the CRM owner kind of be a champion to foster a product based mentality?

So first, I know a lot of you guys know this, but just to kinda over communicate again, CRM means customer relationship management, and there are it's a software tool. The biggest examples of this are Salesforce and HubSpot. So I'm gonna use say the word CRM, like, a hundred times over the next forty five minutes. Just know that when you hear CRM, if you know what Salesforce is or HubSpot or Pipedrive or Dynamics or whatever, that's exactly what I'm speaking to, customer relationship management software.

Okay. So what is the problem we're trying to solve today? The problem is that up to seventy percent of CRM projects or rollouts fail. And so you can see here that we've got, six or seven different articles, and I've got these linked in a in a later slide.

But this is all about the project fail. Right? And so CRMs are kinda ubiquitous within business.

Everyone kinda has one or has access to one. So we gotta figure out why they fail so that you guys don't fall into the same trap that, you know, up to seventy percent of other companies have fallen into.

So why do they fail or become what I call Frankenstein like? So Frankenstein like is when you got a lot of technical debt. It's kind of like a a house of cards. You build things a certain way just because three years ago, you built it incorrectly, and you can't go back and fix it.

And so a lot of them aren't necessarily failed, but I see a ton that are what I call Frankenstein like, where they don't have a solid foundation and you're building on top of it, but it's not stable on the ground floor. So what are the five reasons why they become this way? The first is adoption, low user adoption. If your entire team isn't using this tool in the same way and you have low user adoption, you're not gonna get value out of a CRM.

This is the number one reason, and this is why the entire second half of the class is gonna be talking through adoption. The second is fragile. They're they're fragile because they have heavy customization, and they don't always support the business goals. There might be all this custom code somewhere and all this crazy customization that at the time sounded nice, but it became too confusing.

It wasn't adopted, and it actually isn't supporting the business goals.

The next is a common theme, not just with rev ops, but kind of any department. It's all about prioritization and scope creep. Everyone always wants something new. This is particularly tough in in my business. It's kind of like a fractional rev ops department is that the people we work with want something live, you know, on a Tuesday and starting up something new on a Wednesday. Always want something new. People feel like the more they build, the better this CRM is, and that's just not, not the case.

Part of the reason, it's it's very difficult is support, lack of training and support. It is so difficult to train on all the aspects of the CRM. HubSpot and Salesforce have new features that they roll out all the time. We're not supporting these on a super granular basis.

It makes super difficult. And if you only have one person internally that can provide all the training and support, it makes it very difficult for that person. And then, the last is data, lack of integrations. And so, CRMs are really good with plugging into other tools.

But if you don't have those integrations, you don't have those integrations live, you're managing different databases. And so if Salesforce isn't integrated with maybe your ERP system or your project management system or your marketing automation platform or your prospecting platform or your sales outreach sequencing platform, you have to manage all these different settings in these different databases, and it makes it very, very, difficult.

So what so the top five reasons why patients fail, we just went over those. And and, the overarching theme of it is that they all take a project based mentality. And so I'm telling you why they fail, and I'm saying if we if we bucket that together, it's all about this project based CRM mentality, and that's what I'm trying to get get us away from in this, in this presentation.

So have you worked at a company with the c Frankenstein CRM? Like and what do you think was the main cause? And so I'm gonna go through some, some questions right now. But if you if you have, I'd love to hear it, just because this happens a lot with people I work with, and it makes it very difficult from an end user or a rev ops person to come in and actually solve it because there's so much historical and technical debt already built in.

Rich call Rich calls is the Frankenforce instead of Salesforce. I think that is hilarious.

Yeah. So so, Lindsay, why is this the focus on the CRM instead of the entire go to market tech stack? This can be applied to the entire go to market tech stack. I don't know what your tech stack is.

I don't know what other peoples are. I know that most people have a CRM, and so I'm gonna use this. But the the tenets of this can be applied to not only software. They can be applied to any kind of process rollout or company initiative or or value that you guys have in your business.

And so CRM is the one that everyone knows, but this could definitely apply to your entire tech stack hundred percent.

Let's see. We got customization. Company acquisitions. Yes, Beth. Acquisitions make it extremely difficult to combine these IT led versus business led.

No owner. Yes, Maxine. Staff turnover.

Used opportunities at accounts. That's very unfortunate, Malcolm. And so it looks like a lot of people have that leadership now using CRM, Dan. Yes.

That is a hundred percent correct. All of these things are are correct in the summation. And if you get just one of these things, it could really or your tech stack or other tools or rev ops in general is to help drive revenue. Right?

Right? Why do we have a CRM if it's not helping drive revenue? So the reality is that a lot of these fail and a lot of them because it's a lot of adoption. And this is kind of the the five or six articles I pulled around, why these things potentially fail.

So So what I like to say is that CRMs help drive revenue sometimes. Right? It should be all the time, but the reality is it's sometimes my CRM that I own sometimes drives revenue. Sometimes it becomes kind of a mess.

And so how do we kind of get away from this and really focus on, really delivering this this promise they all make? So if you talk to a Salesforce rep or a HubSpot rep, they're gonna tell you that their CRM is gonna make your business more profitable and more efficient. Right? The is that every dollar uses of ROI.

They're saying it's a no brainer. If we can eight x your investment, why would you not do this?

It's gonna make your sales more effective. If you can get this adopted with your sales team and consistent, you you should do the CRM. You'll be more effective at sales. It'll make it more efficient.

This is this is the really funny thing. It says, it'll help increase sales by twenty nine percent, productivity by thirty four percent, sales forecast accuracy by forty two percent. Guys, sales productivity by thirty four percent. Are our sales reps working a third less just because they have a CRM?

It's the promise they make. Happier. This one's actually the funniest one. Sales teams using CRM confirmed.

They confirmed that their job satisfaction increased by seventeen percent.

Do you guys, do you guys know do you guys know any salespeople who are not maybe happier because they use a CRM?

I certainly do. And so while this is a the promise makes a lot of sense in a slide. You can take every single one of these and flip it on its head, and that's what happens a lot of time. So if you have a project based mentality, instead of this ROI, you're saying, wow. I spent maybe six figures on my CRM. It's not leading to revenue growth. Where's all this money going?

Effective sales, if they're not using it and they're using, you know, notebooks with their notes and things like that, they are not, you know, having a more of an effective sales process. More efficient. Sometimes a sales rep has to fill out, like, fifty fields just to move a deal stage. They are not more efficient at all. They're spending more time monitoring and updating the CRM that they are selling.

Forecast accuracy.

So many companies come to me with the spreadsheet and say, hey. We we could've you did it in Salesforce or HubSpot, but it was just easier to do in a Google Sheet. So they're not even using the forecasting feature. How is it gonna increase their accuracy?

And then happier teams, I've talked to several folks who, wish CRMs didn't exist and wish they, you know, work in sales in the seventy is because they but they would think it's a lot a lot easier here. And so I don't think it always increases the job satisfaction. Now if we do it correctly, if we treat our CRM make a product, I do think some of these milestones can be hit. But every single one of these, there's a very common use case that I think all of you've seen where this didn't hit and it led to, kind of the opposite effect.

So my CRM is finished. Right? Said no one ever.

Right? No one actually says their CRM is finished. So why do they act like it?

Right? They act like there's a start and there's end date, and there's a new start and end date. And this waterfall approach that we all know is not maybe the best way to approach software is kind of what the actions are, but they keep saying it's not finished. We wanna iterate. We wanna build. We wanna customize.

So what do they operate as if this is a start and end state?

So my kind of thesis on this is that most CRMs or your tech stack or your go to market functions are built with a never ending project list rather than a systematized product road map.

So the problem of having a project based mentality is that you've got unknown unknowns. You go in there and start building something or automating something, and you haven't really done proper scoping or discovery to know, what's out there that you might not be looking that could cause, you know, friction.

There's a lack of ownership. Someone said lack of an owner. I mean, that's a big one. Especially teams that don't have dedicated rev ops departments or IT departments that own the CRM.

Someone's gotta do what's good for their department or their part of of the CRM, and it might not apply to the other parts. Lack of ownership is huge. If you don't have a true owner, you're thinking project based. And then you don't factor in maintenance.

This is the biggest thing that happens with, in in my industry is that we build all these things and everything is working, and they say, hey. We don't need you anymore. Everything's done. They don't factor in.

You need to maintain this stuff every day. You have thousands of interactions in your CRM happening every single day. If you don't maintain them, it's just like you're not cutting your lawn. Right?

It's gonna get overgrown very, very quickly.

So what what is this product based approach I'm talking about, and what are these what are the benefits of it? Time efficiency. You're not always behind the eight ball trying to build, build, build, and release, release, release. You've got an entire road map that you're able to plan around.

Agility and scalability. You're collaborating and confirming with key stakeholders what things need to happen and when. And if you need to prioritize different things based on business initiatives, you can be agile enough from that road map to accommodate it. Scalability.

If we added twenty more sales users on my CRM today, that'd be fine. I'd have to do a lot of training and have to get them to adopt it, but our process is inherently scalable.

Very few manual things or very few non standardized processes we have. So as we grow, it can be scalable. Increasing adoption. This is so, so, so difficult, which is why I have an entire section dedicated to it. But if you can increase it, obviously, it's gonna be better because your entire team's gonna be able to get value out of the CRM. And then the long term maintenance is accurate data.

It is it is amazing how you could go on vacation for two weeks, and the data somehow becomes inaccurate just because you weren't on top of these things. The long term maintenance plan and accurate data is a huge benefit of this product based on your launch.

So if you're thinking to yourself, is my CRM owner or is my company a project based or a product based? See if some of these questions have been asked. Why isn't that data there? That's a duplicate or that data is wrong.

Right? Why isn't that data there? They don't understand, you know, what impacts that data source. And so they're confused on why it's not showing up.

That's a duplicate. Maybe they don't know if there's a duplicate management strategy. You can't do duplicates every single day. It's too much work.

Right? Maybe it's a monthly strategy. Maybe it's not really duplicate, but it's more like a child company and a parent company. Right?

Maybe they understand the infrastructure that you've built out. That data is wrong. Guys, there's so many times that ten thousand data points will be correct, but one will be incorrect, and they'll say everything's incorrect. So they invalidate the nine thousand nine hundred ninety nine that are correct by the one that is incorrect.

Not understanding the data. It says when it's wrong, I can't trust anything.

I don't know how to do that in the CRM. I get this excuse so often. Well, why didn't you ask me how to do it? Why didn't you look at our internal guide?

Why didn't you look at the Loom video I sent you two weeks ago? Right? And, again, that's my fault. Right?

I need to do better better at enabling them. But just because you don't know how to do something, it doesn't mean you go create a spreadsheet. It doesn't mean you don't update your records. Right?

And then I say, why is no one using the CRM? They're not using the CRM because they don't know how to do it, and so they create a spreadsheet, and then no one knows what's going on. And then the executive side, this has been a significant investment.

Of course, it is. Your entire customer relationship is gonna be, you know, integrated into this. It is a significant investment, but a lot of times with that executive buy in and leadership actually using the tool, they just look at the cost of it and not the value and then start to kinda rip things off or try to push things live before they're ready. So have any of you kinda heard some of these statements?

Looks like, yeah, lack of lack of leadership and accountability.

The service department of futures are enabled, Louis. I think that's that's a really good point. We don't want to be order takers. We wanna be proactive.

We wanna tell people what's coming up and when to expect things and not just be a ticket solution. All of them. I've probably sent them I I've sent them too, to be honest. Right?

Okay.

So what happens when you have a project based mentality for your CRM? We go through this what I call the reboot cycle.

The reboot phases are full implementation. This can be of, like, a new CRM, a new tool in your tech stack. This could be, like, a new process that you've released. So it doesn't have to be six to nine months.

It can be six weeks in some cases. But the point is you finally roll this thing out, and you spend a lot of time doing it, and then you have decreasing usage. Everyone's excited. You're really on them, and you're like, oh, no one's gonna forget about this process ever again, and then you have decreasing usage.

And then phase three is just repeating phase one and two. You change CRMs. You say, hey. I I grew HubSpot.

I need to go to Salesforce. You migrate a process from Excel to CRM. You gotta start over. You purchase something new in your tech stack.

You purchase a different tool. You connect something different, and you're like, hey. I just bought ZoomInfo.

I've gotta completely change how we, you know, use HubSpot now that we have this new tool. And so this reboot cycle happens so often, and it's just so frustrating for the rev ops folks because change isn't always progressive and change always happens. And so how do you actually change things without actually taking one step forward and two step backs? So this is kind of the way I visualize it where time is on the x axis here.

And so this is over five years, the x axis, and then impact is from low to high.

And so you'll see here in the beginning, that line has a pretty good vertical, angle. And so short amount of time, high impact. And that's, like, the first iteration of the CRM. And then you see it stalls out.

This is that one and a half to two years of decreasing usage, and then you kinda get to this failure point, and then you reboot it again. So you kinda have this downward trend. You say, hey. We need something new.

We just hired a new sales leader. We need to rebuild our entire sales process. We finally hired a rev ops person. We gotta redo everything.

We're so sick of Dynamics. We gotta go to, you know, HubSpot. Whatever it is, you boot it back up. And then let's try again.

We can do this. We're not gonna make the same mistakes we did last time, and then you go a little bit more and then you fail again, and then you reboot it. This happens so many times. The customers I wanna work with, I say, hey.

Why why is this this way? I'm not, like, poking holes in the process. I'm just I'm curious. Why is it this way?

Well, the person before me did it this way. The person before them did it this way, and now we're kind of stuck.

You know? Or this is the third agency we've worked with to try to get this right.

And you hear this a lot, and you're like, man, why are these people keep rebooting it? It's because everything is a short based project, and anytime anything kinda goes wrong instead of trying to fix the core problem of how do I actually approach this tool on their tech stack. They just say, hey. We'll just cut our ties loose and then reboot it again again. Yeah. Louis, sorry if you're that if you're a Dynamics person. I'm not I've never actually used it, but I think people do get sick of Dynamics.

Rashmi, that's a really good question, but, that's a little bit more robust to get into now, but I can probably tackle it later.

So we talked about the CRM reboot cycle, and we talked about, like, why. Like, this would never happen at my company. Right? Or you never want to happen at your company.

So this is the reason why the CRM reboot cycles exist, and a lot of you said some of these things earlier on. One of the biggest ones I see is change in leadership. They want to establish their process. You see this a lot in sports.

You hire a new coach, and they fire the entire staff and bring in all their friends. You know, I'm not saying that happens in business as much, but there's so many times where people change things just because a couple words are off, and they want to establish their process.

Oh, Spice doesn't work for my sales methodology. It has to be MEDDPIC. For these sales stages, we have to have seven sales stages instead of four based on my process. So a lot of time change in leadership is a big reason why this reboot exists.

Lack of alignment with the CRM actually driving revenue is huge. So many executives just see, like, their CRM and, like, people like me as, like, oh, this little admin, this person that builds reports and stuff. They they don't really connect it to driving revenue. They don't understand the alignment that the CRM needs to actually drive revenue, what we're unlocking for them. Of course, lack of trust in CRM data quality is a huge one.

This is, it's really interesting how, like, this the lack the entire CRM is broken if one report is incorrect, but the spreadsheet that has seven hundred formulas on it that if one breaks, but the entire sheet goes up, that one is a source of truth for them. Right? So the CRM data quality is a huge one. Low adoption of key journey milestones between teams.

There's been so many times where the sales team is actually really, really successful in the CRM, but marketing doesn't wanna play nicely. The customer success team doesn't wanna play nicely. The finance person won't go in there and actually pull the reporting needed or export what's needed. They'll just kinda live in their silos.

The spreadsheet folks. I don't know how to say this nicely, but these people are the the ones that kill the CRM the most. These are the people that create a new spreadsheet for every single thing that happens. A new doc for every meeting, a new spreadsheet for every new process. The problem with spreadsheet folks is that the visibility is not there. It's not scalable.

And it's as soon as they run into some kind of issue with the CRM, they immediately default to a spreadsheet, and they bring other people with them. So if it's one person managing one part of their process in a spreadsheet, not a huge deal. But the problem is if the sales manager decides we're doing forecasting in the spreadsheet now and they bring the entire team on board, now they're using that. And now we have four, five, six, seven, eight users that are not following the processes, and so it just spirals.

If you had to migrate to a new CRM or integrating a third party tool, that's a reboot that actually makes sense. But, again, why'd you have to migrate in the first place? And then people underestimate the change change in the admin of the rev ops folks like me. Maybe not at this company now because everyone kinda knows rev ops. But in previous companies, when I left, there was this big void of, like, you know, how do how how do we work now? How do we move things forward? And what happens if things just crumble and kinda fall apart immediately?

Charlie, you got a question?

Yeah. I just got a question, and and we we can take it offline or another point in the discussion. But how much ownership should the rev ops team, take for the poor use poor user interface and experience poor user experience for most CRM solutions. Because it's just you know, who gets excited about Salesforce? I I I may maybe with the latest and greatest, of lightning and all the bells and whistles, they can get excited about the UI, but most don't. And so, you know, that's why you're kind of and they're also not led at the CRO level. But, again, the back to the UI, who takes responsibility for that and providing an experience that people wanna be be a part of and not go to spreadsheets?

I don't know. You wanna talk to Mark Benioff, the Salesforce CRO to CEO to say why he built it that way. I mean, I get excited about the Salesforce and HubSpot UI. I think it's actually pretty intuitive.

There's not a ton of tools that I use that I'm like, oh my god. This is so beautiful and amazing to use. And so I don't know if it's as much as the UI as much as it is, like, the the process flow and do things make sense. It is not clunky to use.

So I don't think of it as more visual, something I can't really change, but more of do things flow naturally through the system. So maybe that didn't answer your question, but, I mean, if I could send my I mean, spreadsheets I mean, Google Slides aren't a very beautiful presentation mechanism either, but it's kind of the choice that we have.

Alright. So Haven't you haven't you guys gone through a CRM reboot cycle where, like, a new hire tries to rip and replace many of the underlying systems?

Does that ever happen with you guys?

Yes.

That means explained?

That was me two, two and a half years ago when my VP of rev ops left. I was like, alright. It's it's no sacred cows. It's tried to it's time to fix a lot of this reporting and the way that we report on revenue and da da da da da. So we've had new sales leadership come in and implement med MEDDPIC and do all that. Yep. But, honestly, a couple years ago when I took over the rev ops team, I started doing a lot of rip and replace myself.

So Kevin was a savior. You came in and saved the company from this Frankenstein disaster. Hey. Love to hear it.

I I no. I I've done similar things. You look at it and you're like, rather than trying to tinker this one by one, let's just let's just get rid of all this extra stuff that we probably don't need. Looks like Tanya might have a comment.

Yeah. I'm just I'm laughing at myself thinking about it, Kevin. So I didn't initiate it. I was at a company, and they had done so many acquisitions. And so we were running concurrently four instances of Salesforce and then had to migrate over to Lightning. So I'm just laughing thinking of it because it was, like, a massive, endeavor.

I don't even know if it was I guess it was called a reboot, but definitely had to consolidate, get to a common language baseline language, and then get on to one instance.

Was it And I don't know if this happened with you, but when I've seen that, they're like, oh, it's gonna take three to four months to do it. And I'm like, guys, you're not you're not thinking this through correctly. It takes three to four months just to get people to agree to agree on something. And so one of my, customers got acquired, and they didn't start this thing early enough.

They tried to push it live too soon, and it just became a disaster. You know? Mhmm. For sure.

Yeah. It took over a year.

Yeah. No. Yeah. It takes a long time, guys. You gotta invest in it. Alright. So let's go from some common themes in CRM as a project to talk about how they would work as a product.

So as a project, unknown unknowns become blockers to use.

But as a product, you're uncovering and addressing these issues as you go.

Right? The time to use is dependent on a scope of work. Right? Tanya was saying, hey. Took a year to kinda get this to kinda get use out of it.

Whereas as a product, maybe you can reach an MVP stage, begin testing things out, and validate some of these things before spending a year and then turning that button by by the last day.

As a project, the lack of long term ownership results in poor data governance. The whole ownership thing, who's gonna own the data? No one wants to do it. The product owner, you'll be the rev ops person, results having a product owner results in both process and data governance.

Right? As a product, there's no space for feedback loops. We have this project plan. We need to get this done. You know, this has to go live at a certain date. So it makes adoption difficult. As a product, the iterative updates, allows for increased adoption.

As a project, six months after post implementation, a lot of times they fail. As a product, six months post implementation, a lot of times there's time for growth. Once we got this implemented, we can actually build and actually add more value on top of it.

So how do you approach this as a product?

So the way to do it and when I say MVP, this could be just kind of like a new initiative you're working on. It could be the launch of a new tool in your tech stack. It could be kind of this, this new leader comes in and says, hey. I wanna approach things in a certain way. So you think of MBT, you can kind of relate this to a lot of things in your business. But first, we wanna identify it, then we build it, and then we adopt it. And all three of those things are very, very important.

So what are the core requirements that your CRM should be able to do? Right? You need to answer this question.

You need to gain alignment for on requirements from multiple stakeholders, and you need to separate needs from wants. Everyone's gonna want everything, But what are the actual needs? If the needs don't align to the actual business goals of what we're trying to do here, then you're not you you don't need to get them done, especially for your MVP. Wants can come later, needs to come first.

Then to build it, get to work. Right? This is the fun part. You're actually building the things within the CRM.

But don't get distracted. There's gonna be so many requests that come in. Make sure to own and finalize your MVP. Make sure that's their north star and prioritize accordingly.

Because automation is not always necessary.

When I build kind of new feature sets or product releases or whatever we wanna call them, I actually like to make the process manual in the beginning so that the user actually knows and is very intentional about the function that they're performing. If you automate everything in the beginning, a lot of times, they kinda miss the point and they assume these things are happening in the background, but they don't understand why. You automate before it's necessary. You're not actually gonna get adoption of the MVP.

And then, of course, you need to always test. A lot of my team gets angry because I have these test contacts and deals and all that stuff that I forgot to delete, but testing is always necessary. Run through it three or four times, Check a different use cases and test it. There's nothing more, worse than doing a live training on a Zoom call like this with the team and going through your process and it not working because you didn't properly test.

And then finally, adoption. This is what the entire second, half of today is gonna be about. This is the hardest but the most important part. Adoption is more important than the process and more important than the tool, and we'll dive into that a lot more. Lead with the why. If you don't tell people why you're doing something, no one's gonna get on board. How do you monitor your key KPIs to ensure adoption?

How can you put your finger in the air and say, hey. We're eighty percent adopted. I want it to a hundred percent. What kind of reports can you actually set up?

Does it always have to be, like, the end result reports, like deals being created or revenue being generated? It could be some of, like, the bad behavior reports, which is deals without a next deals that haven't had an activity in fourteen days, deals without this certain property filled out. Right? Those can be key KPIs as it relates to your MVP and adoption.

And then finally, create a feedback loop to leads into feature request. Ask for feedback. You don't have to make the adjustments right away, but ask for feedback, create a loop that actually leads into these feature requests. And if you have a road map that is kind of, visible by others, they're gonna know exactly where the request fits into that.

So the the point I'm trying to make here is that, you know, we kinda take in engineering and DevOps for granted, and it's so ingrained that those processes there that we don't always apply those to other parts of the business. And even if we're like a we're like a SaaS company you if you're a SaaS company, you have this amazing software tool. You use a lot of these principles internally, but you don't apply them to the CRM, which is just another software tool.

So if your engineering teams are doing it, whether it's, you know, engineering software engineering or, you know, mechanical engineering, these principles work with your CRM, and they work in rev ops. So about agile, iterative development.

Embrace change. Change is always gonna happen. It's okay.

Foster collab always try to decrease time to value and always continuously improve. It's all about making it one percent better. It doesn't have to be perfect the first way.

Monitor and feedback loops. Don't be afraid to track user behavior and figure out, hey. Maybe this process you built out is isn't actually the ideal behavior. A lot of times, I'll build something out, and then once they actually get to use it, I'll realize that I missed some key components of it, because, you know, I'm not the one actually doing this in a day to day.

Process performance areas for improvement. Again, don't be don't shy away from trying to improve this stuff and getting that feedback loop. Feature releases. Right?

Tell the team when you're gonna release something. Make it consistent. Keep improving. Ensure adoption one step at a time.

And then, of course, we need to maintain this forever.

If we do all this work on the front end and we immediately switch three months down the road and don't maintain these things forever, it's just it wasn't worth it. So the key component of all of this is that at the bottom, the product owner of these principles should apply to rev ops. They should apply to not, like, all of you. It might just be your functional area within the business. But if you're not doing these types of principles and all the different things you're you're doing, you're probably not thinking long term enough.

So in summary, project play based approaches lead to failure. Your CRM really is a product. It's not a project. And every solution is a feature update for a larger prod product.

These aren't just little quarterly projects that get done. You know? The quarter ends on Sunday, and it's like, hey. Q two is done. Let's start something new. It's a feature update, goes into a larger product. And, of course, the rev ops department, I do think these are CRM owners.

Product owners. Why? Because they establish processes and data. They lead to driving adoption. They help measure KPIs and, ultimately, you're driving business performance. If you can do those four things, especially as it relates to your CRM, there's no reason why you can't look at yourself as a product owner and really go into this drive business performance aspect.

Okay. Real quick. Do you have a do you have a regular CRM product releases or like, how do new processes get rolled out in a systematized way? I need to go check on my dog real quick, so I'm gonna go away. I'll be back in two minutes. So please enter that.

This is the time he acts up.

So it sounds like not, but it's a great idea. It's impossible. Maxime, it's impossible. Yeah.

And you could you could say that. But look. These big companies, Salesforce, they do a what? Like, three times a year, they do a big release.

You know? They're fine with it, but not smaller ones, Malcolm. I don't know. I mean, I'm not saying you guys do this every six months, but if there's a release once a month or once a quarter, I think it can work because it's really hard to adopt four different things over four months.

It's a lot easier to adopt four four at once, I think, for the most part.

So the company So what's the example go ahead.

Sorry. I I was just the company I I'm just leaving.

We had a product owner, and they were there were, a team of three in the end.

Yep.

And, well, and within sales ops, I managed them. And they did have the release cycles and and all of that. I think where there was room for improvement is the whole change management set thing. You know, like, the communication.

I mean, it was they communicated it through a website, but, you know, I think that could have been done more on communication, and and that was obviously something I was coaching them, around. So it can be done. But I think we were in a very unique situation. And, actually, what what happened is, you know, we wanted to actually push the ownership to some extent to IT because we then also were responsible for things like seeing event monitoring and stuff like that, which is not really a web ops topic.

But, but, yeah, I thought that that was always a neat setup.

Yeah. So you have the intent, which I which I think is really good, but the execution is very difficult. And I it's like you get so close, but getting it to a hundred percent is just so hard with all these different people. And then, like you said, people take rev ops for granted and say, oh, CRM is easy.

Right? Everyone can do it, and so they add more to your plate. And then what do you lack? You lack the time to overcommunicate, to train, and to adopt.

So it's a constant cycle. Alright. So what's an example of a potential product release? Just so you guys kinda figure out, like, how this might apply to your business.

So some of the three main tenants I always look at are how do we increase metric visibility, how do we increase overall CRM adoption, and then how do we increase performance of the business. So a couple examples around metric visibility is that maybe there's a reporting update that's in progress that carries over to the next time period. Maybe there's close lost reasons we wanna consolidate so that it's better better action plans for maybe nurture campaigns.

Maybe we have a go to market, go to market motion property on deals, but we need to update a workflow. Maybe we need to do an analyze that a little bit deeper to figure out how that affects the sales go to market. And maybe we have a new market segment. So for us, we had a are are selling more data migrations now. And so this is a new segment, kind of a product line. And so how do we increase the the visibility of how those deals are performing?

Around the adoption, always updating documentation.

So if you create a new stage or whatever it is, make sure that documentation is very visible and easy to find.

And then, of course, train. If you update things, train on the new entry and exit criteria. Make sure the managers know about it, and they're helping with the training. And then performance, you know, this is kind of like a a a constant thing.

And so a lot of these, you know, it's not all net new stuff, but, like, what are the some of the maintenance activities you're doing over and over again? So why are deals be being pushed? How to get proper attribution in the marketing campaign for a recent event? How to look at your website analytics and how it interacts with maybe forms in your website?

And And if you're setting up something new, like, maybe, like, a new renewal pipeline, how do you systematize that renewal process? And so these are examples of how you can kind of take that approach of a product road map, put these into each of these categories, and then begin prioritizing these and stack ranking them for what we're gonna do and when.

So finally, what do we get? We get CRM as a product. And so this bottom line is kind of that first segment where we have the CRM reboot cycle. And then from here, you see that the angle of that line continues to go up into the right because we keep we do these continuous feature releases.

Doesn't matter if it's quarterly if you're a large business or, you know, weekly or monthly if you're a smaller business. But the point is every time we do a new feature release, we're involving the entire team. We're doing the training, the discovery, the adoption, the reporting. And so that we're we're we're having that higher impact CRM over time, and we're making this scalable instead of, you know, taking two steps forward and one step back every time we're doing this.

And so the hope is that whether it's your CRM, whether it's a different party of your tech stack, whether it's just your, you know, how your comp how your team operates within a business, getting into this iterative approach and really trying to figure out how do we always take two steps forward is kind of what I'm trying to articulate here. So let's take a minute to go to the workbook, and I've got kind of a cool diagram that you guys can fill out, as it relates to as it relates to this section. So let me go ahead and pull it up myself. And then I do have a question here.

We kinda talked about this, but I think a lot of you have seen your CRM be treated as a project and not a product. Alright. So let me go to my copy of the workbook.

Hopefully, you have this. It looks like several of you have access to it. And so this is, kinda like the workbook example that I have that I want you to get just to take, take the next five five or so minutes to fill out.

So first of all, who's your owner? Who currently owns your CRM? Is this no one? Is this you don't know? Or do you put can you put their name in there? Or maybe it's department.

And then maybe who should own it? Is there a new hire that you haven't hired yet, or do you wanna keep the same owner?

And so if you just add a text box here, it should be fairly straightforward to, to put this in there. So, like, if I if I fill this out with my company, it's not gonna the formatting is not gonna be perfect, but, you know, hey. We're trying our best. So if I do this, I'm kind of the CRM owner at my company, and we call ourselves the playbooks team, and we kind of have shared ownership.

Right. So looking into the kind of primary KPIs or different KPIs that you gotta set up for yourself, Do you trust the metrics below? And so we have number of leads, qualified leads, revenue total, deals, you know, ownership of different object types, and then live customers. You can just put a a y or an n next to it. You can certainly edit this to make it more specific to your business. But what part of this data do you trust and what part do you not? And if you trust it, does the entire team trust it?

Next is your assessment. So in light of your data assessment plot where you currently sit, and so you you just take one of these and and drag it to where it needs to be. So do you have your, your customer journey process within the CRM, and have you integrated the data sources that you need? Do you have your primary KPI set up and accurate? Are you driving performance via those KPIs?

Do you have the secondary KPIs? And then are you driving business performance with full rev ops visibility? So kind of plot where you think you are, kind of on that, kind of on that assessment line.

And the next is, like, your next release. And so what are some must haves for your next CRM product release?

So if you think about and and, again, it doesn't have to be your CRM if you're, like, in marketing. And maybe it's your marketing automation platform. Maybe it's your sales acceleration tool. Maybe it's your finance tool. Maybe it's just that it doesn't evolve software at all. But what are some of the things you're thinking through that you need to have in your you know, in this kinda next as we start q three, what are some things you're thinking about if they're individually as a team? We kinda put some examples there.

So that is the first slide. I'll give you a couple of minutes to, fill that out, and then we'll move to the next slide, and then we'll get into the second half, up to that.

Charlie, what is the ideal product release frequency? I think it's it's very company dependent.

I I try to I I at least think through planning on a quarterly basis. There's so many things that add in midstream, but, it's it's hard to tell. But I I would say we plan quarterly and release release monthly. So we do, like, a monthly team training.

Once a month, we have an hour long meeting dedicated just to training. And so we that's when we release all of our new things. And so, at RevPartners, we release monthly, but we play quarterly. This the frequency is too high in my opinion.

So right now, we're planning for q three, and we'll have, you know, eight or nine items on the list.

Thank you. What is, reporting's done on the p b PBI side? What is that?

Anyone know what PBI is? I'm not sure what it is. Oh, Power BI. Oh, okay.

Okay. That makes sense. Yeah. I mean, that's totally fine.

Okay. So if you've got this, which, again, you could keep working on it, but I will, talk about some potential blockers. And so think about your CRM again. We're talking about any part of your tech stack. You know, if if we think about primary or secondary KPI visibility, what are some blockers to that visibility, and what are some unblockers? And so when you look at, you know, your part of your your next release plan, you're probably trying to unblock some things. And so what is that current blocker, and what is an unblocker?

So an example is, there could be a lack of a def definition around the marketing qualified lead, what it actually means, and then leads going associated with it. And so an unblocker would be to really sit down and map out the MQL triggers, create the list, automate the movement, and track all MQLs by lead score, and then audit those as they come in. And so there's this, this thing where I don't trust the data or maybe around lead scoring. And so that's a blocker. That's fine. But how do we map out the unblockers that we can actually move forward?

Especially in the rev ops focus role is that you'll get a ton of blockers from different leaders that will just kind of say blanket statements, like, I don't press lead scoring for instance. And so how do you break it down to say, if we did all of these things, could we unblock this? And so that's what we're really trying to do here. And so, again, I'll give you three or four more minutes, and it's really to fill out these two slides within the workbook.

And then at one fifty eastern time, we will hop in to the second phase. The reason I'm doing this is because I did receive feedback that I moved too fast and don't give enough time to fill these sections out. And so that's why I'm trying to be, give, you know, at least a full three minutes to kinda work through this. And so just so you know, it's a little different.

I'm trying to take your feedback in a minute.

Hey, Brian.

For this part d, what what types of things are we looking for? Is it like the must haves might you know, once that might be enablement, for example, or once that might be Yep. Documentation, or or am I thinking about that wrong?

Yep. No. That's perfect. So, like, for instance that's actually a good point. So, like, this is something that I'm doing right now.

It's like we're launching a ticket pipeline for presale scoping. And so the pipeline is the first step, but I need to update, like, super cards and process rules. This is, like, our documentation tool. And then I need to, like, hold team training and set up audit reports.

So these are these are kind of, like, sub bullets, if you will, but, you know, these things should be like, this is the main deliverable, and this is what this is what everyone sees. They're like, oh, there's a new ticket pipeline. Great. What people don't do is they don't document the new definitions.

This is actually process rules, and so these are kind of the error messages like validation rules in Salesforce, and then the team training and set up all the audit reports. And so the audit reports are where I give these to, like, in this case, the sales manager and say, if you show up on these reports, it means you're not following the process. So this could be things in a certain stage that where the field's not filled up properly. These could be overdue tasks.

These could be whatever it relates to a specific process. But instead of trying to, like, manually follow-up I mean, there's, like, eight people involved in this process. And so I just say, here's the dashboard. Once a week, look at this in your meeting.

And if you show up on here, there's there's a cross there's an adoption thing we're missing. And if you have questions about that, let me know. So that's the kind of the way that I handle it. But as you'll see in this next phase, it's just so difficult to do because we've got so much going on.

And it's hard. Right? It's hard to tell someone, hey, Kevin. You forgot to update the ticket again.

This is the fifth time this week. Right? No one wants to be that person, but you have to be. Yeah.

Looks like Eva doesn't have the workbook.

We have we've given the link a couple times, so I'll I'll comment it again.

How do you define come up with a list of improvements?

So we get we get requests, and I just kinda put them into a list. And then my team is myself and four other people, and then we just kinda put together a bunch of things we're thinking through. And then we'll have a meeting actually on Friday to run through and prioritize all of the things that we wanna prioritize. So a lot of them come come to us, but if we know we have to have an a fully up to date product road map, we naturally are always thinking about this and always adding things here.

We'll poll our team. We'll say, hey. Is this valuable? We'll put a poll in Slack to say, hey.

Here are the three options. Which one is most valuable to you? And we'll we'll consistently try to get that feedback loop. It's not super, super easy, but if you you understand, this is kind of how you operate, and especially with with CRM requests, I've never had nothing to do.

There's always these requests that come in. The key the key thing is what do you say no to?

You've struggled to create a rev ops road map, generally, Kevin.

There are so many things that come in all the time. Yeah. So, Kristen, yeah, I'm not sure.

Like, it really depends. So this is kinda where my, like does your does your team train you, or do you train your team? And what I mean by that is that do you allow kind of, like, bad behavior where just requests always come and you have to get them done, Or do you train them that you're only gonna release things once a month so that they know that if they send something in July twenty sixth, should it be on your hit list, but you're not gonna release it till July fifteenth? And people say, oh, well, this will never work in my org because people need things now, and we always move at a fast pace.

I kinda disagree. I think you are kinda being trained by, by your team instead of training them, and it's not easy to do. But getting into a consistent rhythm on it's on the road map. I can't do it.

Let me know. In my role, I get so many requests from every different department because we're kind of a support function. And I just say, if it doesn't if it's not on my road map and it doesn't fit into the core pillars of my team, I just can't spend the time to work on it. Just like I'm not gonna ask the sale a salesperson to go write a bunch of email copy or a marketing person to run a demo.

Right? People think of ops people as just whatever I don't wanna do, you can do it, which is could be the case. But if you have very clear expectations, a lot of times you can kinda mitigate that from my experience.

How do you roll everything out at one time? It's a lot of times you can kinda push things live and you can kinda train all at once.

But, like, I don't really use a sandbox, but, I won't turn on any automations ahead of time. I I mean, you can build all the fields and put them not put them on the actual, like, sidebar or, like, the actual record page and then easily toggle those on and turn on automation right after the training. So you can build a lot of stuff. You can build all the reports that that didn't catch the data, and and then you kinda turn them on at once.

You can use the sandbox. I just generally don't do that because we don't have these huge builds and this huge team. So, again, in summary, your shame is a product, not a project. The takeaways are CRMs are never complete.

They fail when treated like a project. It's an ever evolving product. Employ the scientific approach that you do in other rev ops functions, and don't let perfect get in the way of good. Nothing's ever gonna be perfect.

It's really hard to manage this data. You know?

Maybe don't let perfect get in the way great. Let's strive to be great, but don't let it be perfect. And then the principles of this is that you need visibility before anything else. You need to identify and build your MVP before moving on.

You have to create that feedback loop. Use feature releases to keep your team and processes updated, and then focus on adoption, which is what we're gonna do next. Focus on adoption because a process not adopted doesn't exist. And these principles, as you can tell, they apply to many other things, not just the CRM, not just rev ops.

Okay.

Let's go.

Juliana, how do you approach the road map planning and sending these pillars for the team?

This has taken a while to do. We we meet pretty frequently on this, and then we have a quarterly, like, review where we kinda do, like, a little, like, half day deep dive. And so, the pillars have evolved over time. It's definitely not like a a one size fits all, but I've got a couple hours in the calendar on Friday, for instance, to review our road map as a team and prioritize who's gonna do what and when.

So it definitely takes planning. Couple hours of planning in late June is gonna really help us up for July, August, December. Alright. Adoption is a true north.

Very passionate about adoption, and so, hopefully, you guys are too because this is very difficult. I think it's so important. So by the end of this topic or this section, we're gonna go through adoption framework. I think this I I think the framework to think about adoption takes this nebulous kind of concept and really makes it, you know, much more clear.

Talk about the context of adoption and then the maintenance mechanism. How to design a maintenance mechanism to ensure your CRM runs smoothly.

Okay. So why is process adoption so hard?

And put this in the chat, please.

I'm struggling this with with this right now. I'm trying to run a new process for a team where I don't directly manage them. I'm not in really their team meetings.

I certainly know the folks, but they need to adopt a process that I built on their behalf.

And it's not like I'm in their team meetings every day. Take laziness, may maybe Rich. I think yeah. Charlie, stickler alignment, understand it, misaligned incentives, all this stuff. It is it is really difficult because it's it's it's, especially as RevOps spoke sometimes, like me, the the reports that you can hide behind software, but adoption's all about the the people, person interpersonal, relationship. And so that might that sometimes makes it difficult as well.

Okay. So you guys all realize why it's so hard. And so, like, what do you picture when you think of how long an adoption or new process should last?

This is kind of, kind of a weird question. I don't know if you picture anything, but I definitely picture, like, a very specific image in my mind, which I'll show you next on when I'm thinking when I'm talking to different, like, business executives about adoption, I try to use this analogy and this picture in my head on on what exactly it is.

And so this is what I picture when I think of how to adopt a new process. I picture a little puppy on my doorstep with a little adopt me sign on their on their little collar. And so stick with me for a little bit. I know this is kinda silly, but I do think the analogy fits, and I do try to use it.

So when you adopt a puppy, the first part is super engaging. You don't worry about being up in the middle of the night. You don't worry about it, you know, peeing on your floor. You don't worry about the stuff because it's part of, like, the puppy phase.

You just adopted it. You're super excited. This is just like when you roll out a really big new feature. Everyone's interacting with it, and you get a lot of excitement.

You're watching it grow. You're getting it trained. You're going through that initial adoption phase.

But this is where that c CRM reboot cycle gets in. It would when the when the puppy starts to grow is that when that first phase turns into, hey, a long term phase, you still have to feed it, walk it, take it outside, play fetch every single day. I mean, fifteen minutes ago, I just had to, you know, talk to my dog because he was, you know, barking, you know, a little bit. And so a lot of times, like, we always want these new puppies.

Who doesn't want a new puppy every month? Right? They're cute. They're fun to play with.

Nothing's wrong with the puppy. And so we always are chasing, you know, the shiny object within our CRM or our tech stack or business processes. And we always adopt something, and then we want a new one immediately.

But if you think about it and you kinda and you kinda think of, like, a new process where CRM or a new tool in a tech stack as a new puppy, you can't just get a new one next month. You have this every single day forever. You need to maintain it. You need to feed it. You need to walk it every single day. The same is the same, but the same it's the same concept with the CRM already just let you roll out. So why don't we take a similar approach in business?

Right?

Everyone wants a new puppy. No one wants to deal with, you know, the constant feeding after the first couple months or taking it outside. And this is what happens with CRMs, and this is what, you know, gets me not angry, but I just don't understand the the long term approach is that if we're constantly trying to roll out something new over and over again, we haven't even adopted any of it. And just let's just pick one thing and stick to it forever.

Right? Okay.

So we got the puppy analogy, and we and we understand that we need to adopt processes forever, especially within something like the CRM. So when you think of process adoption, when you think of your sales and marketing and folks sitting at their computer, how are you ensuring the process adoption? How do we ensure that? So do you have a picture in your mind? Again, this is kinda silly. I've got something that I always picture, but I'm curious if anyone does. Maybe not.

Take it to the vet for vaccines. Yeah. Right? We we're a lot more than just, taking it for walks. Okay. So, again, this is a little silly, but this is what I picture when thinking about a process adoption. So if I'm going on a new process, how am I gonna get someone else who lives across the world in some cases to adopt this new process?

I picture a little man or woman sitting on my shoulder, begging me with a tiny hammer every time I don't follow the correct process, serving as a constant reminder to do so. So as soon as I do something incorrect, I get a little bang saying that was incorrect. Please fix it. And this is not meant to be, like, a negative think of process adoption. It's it's more of, like, we have so many things going on at once.

We've got social media. We've got Slack. We've got, you know, maybe things on the TV, news, a hundred and one things we all want in our business. It's impossible to memorize everything.

And so the way that I think about process adoption, which you could disagree, is that I don't mind having the reminders. I don't mind the Salesforce error messages because I know immediately what I need to fix and then I move on. Rather than spending hours and hours and hours memorizing this and being like, I need to be perfect a hundred percent of the time, we're all human. I just wanna be reminded what I'm incorrect.

Tell me what exactly what to do, and let me move on. Right? Of course, we don't want someone not following the process forever and using this as a as a crutch. But if you've got a hundred different things you need to update in your CRM every single day as a salesperson, If you do ninety of them correct, I think having ten little reminders, little little bangs with the hammer, I think is totally fine.

And so that's what I think of. And I think of when I think of process adoption, I think of limiting the, limiting limiting the guardrails so so that if you hit the guardrail, it immediately bumps you back. Kinda like bumpers and pull. If you go off track a little bit, it kinda puts you back in the middle a little bit.

Just gives you a little nudge. So that's kinda what I think of. So if you get anything out of this entire course, think of puppies and little little guys with hammers. Right?

That's what I picture.

So what are some best practices?

Reminders. That's the little the little hammer person. Create automated reminders. Create reports. Create documentation.

Create CRM flags. If this could be, like, deal tags or it could be, like, validation rules. Just to get someone back on track if they'd be off track. It's impossible to remember everything.

We've got so much going on. I've got seven sales calls this today. I don't really feel like updating all my deals. Just remind me.

Constant reminders.

Adoption timelines. Build in an adoption timeline or adoption period to set expectations that this is a trial period.

Limited new builds are happening during this time. So we rolled out a pretty big, like, cross functional thing in May. And we said, guys, all of May is the trial period. We're gonna work through the fixes, and nothing new is gonna happen.

And, immediately, we got all these new requests about new, new, new. And I said, no. You can talk to me in June. But until then, we're going through this adoption period.

We're gonna actually know this process.

The reason we could do that is because the expectation was set that this new process will be adopted forever, right, just like the puppy you adopted. So if you don't wanna spend the time on the front end, it may not be as important as you think. There are so many times where people say, I need this. I need this.

I need this. And I say, hey. Not now. It's not on the road map. And, you know, we're we're currently in a, you know, a trial period with this with adopting this new process, and they never bring it up again.

This thing that was literally burning a hole in their pocket, they never think of it again, and that talks about prioritization.

Just because you need or want something and ask for it does not mean I need to immediately do it. If we need to adopt this forever, you need to be part of the solution. If you don't wanna be part of the solution, maybe it's not as important as you think.

So the next part about how we think about this, and I'm a huge proponent of this or I truly believe this is that adoption is actually more important than the process, and the process you build is actually more important than the tool.

Most people start with the tool. If only we had a dedicated customer success platform, everything would be fixed. If only we upgraded from bad marketing platform to good marketing platform, everything would be fixed. It's all tool focused.

Guys, most tools can do most things. Right? A lot of them. The process is more important than the tool. If does it matter if you have the brand new deluxe enterprise edition of Salesforce versus, you know, whatever, if you don't have a process to actually get data flowing through that system?

And the the best process, it doesn't matter if you don't adopt it. We can spend so long mapping out this beautiful process. If no one follows it, it doesn't matter. Adoption is more important than the process, which is more important than the tool.

Adoption of the CRM is the most important aspect of any rev ops pro. If the users do not use the CRM, your value as a rev ops person comments.

So you can probably make analogies to if you're not a rev ops professional, other parts of your business. Whatever is the most important tool that you use, biggest high value Adam, you're responsible for that adoption, and your personal value to the company plummets if you don't get a use of it. That's why it's so important.

MVP to iterate. Use agile principles. CRMs are not static. Nothing's really static these days. To find the core function that will never change, and then scope changes as needs changes begin iterate on top of that.

The ability to adapt to new requirements and new initiatives is is fundamental. We can build if like, if you have a really solid foundation, you can build as much as you want as quick as you want. If you don't have that foundation set up, it's gonna be very difficult.

And then prioritize training and issues. This is something that I I really, relate to.

Asking someone to adopt a new tool or a new process is asking them to be bad at their job.

Think about it. You're used to doing something, and I'm asking you to do something new. I'm saying be worse at your job. Be less of be less efficient. Spend more time in this tool.

People don't realize this, especially as, like, a CRM admin or a rev ops pro is that almost everything I do ask people to be bad in their bad at their job in the short term in order for long term benefit.

So if I'm asking them to be less efficient, then why am I mad if they don't immediately follow this process?

Right?

Why why do we not have reminders? Not why do we not help them out?

Why do we add things on top over and over and over again?

It's hard to do something new. Change is hard for anyone. And so for asking them to be bad at their job for a little bit, you might as well prioritize training and really help you with their issues. It requires an uncommon level of attention.

Answer user questions and fixing small errors immediately.

As soon as something goes live, you need to be ready to immediately answer this. Don't push us a bunch of things live and go on vacation for two weeks.

Right?

So what's the what's the implication here?

Adoption is king. I just said adoption. I think it's more important, the process and the tool. So why is it important?

Is the process doesn't exist if people aren't using the process. Everyone you know, the common thing, you know, five years ago is if it's not in Salesforce if it's not in Salesforce, it doesn't exist. Like, everyone under understands what that means, and it's just the same thing with process. If it's not if it's not in Salesforce, if the reporting is not there, it doesn't exist.

And there's this downstream impact where it's got an outsized impact. So a five percent decrease in user adoption can have a significant impact in reporting and ability to answer the questions. And a lot of people say if this isn't a hundred percent correct, it's useless.

So you rolled out this great thing. You've got a slight decrease in adoption. Your reporting is not accurate. The spreadsheet's now more correct.

I don't trust the CRM. I'm gonna eject and go use my spreadsheet. Right? It's not what we want.

Implication is adoption of our function. Sacrifice function for ease of use and simple.

Guys, I can build all the automations I want or whatever. We've got a ton of developers that can custom code whatever you want. I try to simplify every single thing I do. Very few people have convinced me that more complex is better. Everyone wants complex.

Start with an MVP and iterate.

This process that I just did just now with these tickets, they wanted tickets immediately. I said that's that's too that's that's gonna be too much right now. Let's just start with a couple of deal properties and a couple of different automations to trigger tasks, and let's see how that goes. We tried it for six weeks.

They wanted something more robust. That's great. But we had an MVP. We iterated on it.

Now the team knows the process. So even though they're moving from the deal to the ticket, they're gonna be able to pick it up a lot faster. I did not say we're gonna do a full build for four weeks and roll this out. Let's start small with an MVP and then go from there.

What's your true north? What's the most important metric? The most important metric is adoption of the of the system. Does anyone question the ROI of email?

Does anyone look at their Gmail bill? I know it's low, but says, oh, man. I don't know about this one this week or this month. Not getting a lot of use out of it.

No. Because everyone uses email. If you don't use email at your company, you're probably gonna get exited from the company. No one questions the ROI of email.

Right? So how can we make that true with the CRM or whatever your job function is within within the company? How can you get such good adoption that no one ever thinks of it? Right?

And then ongoing. Implementations never stop. You must always be on guard.

One ex one Excel has the power to destroy a million dollar investment. Right? Because that one person branching off can bring people with them, and then it just steamrolls from there.

So the two ways that I think about adoption is passive versus active adoption. I think we all do passive adoption, which I'll go through. But if you do active adoption, one, it's way more time consuming and way more difficult, but I think you can see how it's way more impactful.

So passive adoption is more like, it's not my job. Right? I just rolled pushed something live this morning. It's not my job to get it fully adopted.

Might be one Zoom training call. Might be a public Slack message just in, like, the general sales channel that always has a bunch of messages to say, hey. This went live. Please do it. You might have a Google Doc or a Bloom video that you link in that message.

You may get angry when the process didn't follow.

Right? If they do immediately adopt this overnight through osmosis, I'm gonna get angry even though I'm asking them to get bad at their job. Right? And then low manager buy in. There's no plan to help them succeed. The best way to get adoption of any tools to get manager buy in and give them tools to be successful.

Here's one report to look at every single morning. If you see x, y, and z, you know it's being adopted. If you see x y or a, b, and c, you know it's not. Here's one view to look at. Here's I'm gonna actually say automatically send you a report at six PM every day to show the daily activity.

Help the managers help themselves. They're busy doing a bunch of other stuff. They don't have time to build their own adoption plan for what you build. Get their buy in and give them a plan to succeed.

So what is active adoption?

This is more about ownership. I own the adoption. I own the CRM. I own this part of, part of our business.

I'm gonna own this. First, defining what tangible success looks like. I I don't want a hundred percent of adoption and we overnight of this new thing I rolled out. It's not that's not that's not, realistic.

So what does tangible success look like? It means that we've got ten tickets currently in the queue, and each all ten of these scopings over the next two weeks get updated to their proper situations and all tasks get completed.

Right? I can easily pick out the ten. I can build a report, and I can define tangible success. If we get to here by end of next Friday, this will be a success and defining that upfront.

Doing a designated adoption period, setting the timeline and expectation across teams.

The next two or three weeks, we're gonna focus on adoption. We're not gonna get mad at this process at fault. We're gonna work as a team. We're gonna put extra visibility so things don't get fall don't fall through the cracks, and we're gonna put a time on here. A lot of people go on vacation next week, myself included. Right? We're not gonna pretend that this is gonna immediately be a hundred percent successful overnight.

We're not touching HubSpot until mid July.

Right? There's an adoption period for this team.

Multiple forms of training. A lot of people learn differently, especially virtually. Do a lot training.

Document that. Add videos. Add visuals like Miro boards like we went over last week, and then do, like, a smoke test if you want. A smoke test is when you, like, give them a scenario and say, create a test contact or a test deal and walk through this scenario. And if you get to the end and follow the steps correctly, you'll show up on this report or you'll receive this notification.

So it does work a lot because it's a lot more tangible. It's a lot more it's a lot more active, active form participation. Create adoption dashboards and have a weekly main review. Right?

Create the dashboard ahead of time. Communicate. You don't wanna be on these reports. You wanna be on these reports.

It means you're following the process. And then add this to your weekly meeting. For the next four weeks, when we spend five minutes reviewing this dashboard in the weekly meeting, no one's gonna say no. Especially if you join the meeting and you own it, those weekly meeting reviews really, really enhance things.

Nobody likes being the guy or the girl that, goes to the meeting five weeks in a row and is always, always the one that doesn't adopt.

One second.

Do go to go to DM people on Slack. You know, don't publicly call them out all the time. DM them and say, hey. I wanna help you. How can I help you?

Go show them a report that's specific to them. Hey. If you check this every morning, you should be good to go. Offer assistance. And then finally, help clean up the data.

If there's ten things they need to do in this new process and they do nine of them, just do the extra one for them. You should be monitoring this stuff too. You should help clean up the data around the edges too. The goal is not to get to a hundred percent immediately.

You're asking them to be bad at their jobs, but their job requirements don't change. You're asking them to adopt this new process. Help them out. You know, be a good teammate.

So in order to do active adoption, we need a framework. And so this is a framework that I hope we can apply to a lot of these things. So the adoption framework that I use is called CREDIT.

So credit is celebrate, remind, enforce, define, inspect, and train.

Now you're probably thinking, why are we enforcing things before they're defined?

And we're actually not. It's just if you put things in the right order, it doesn't spell an English word. So I came up with credit, but these things, they all need to happen, but maybe there's a different order. So don't get hung up on the order.

Just make sure to do all six. Okay? I understand you need to define the process before you enforce it, but credit sounds kinda cool. It's a it's a framework, so stick with me.

At least Nat agrees that, you know, we can all you know, not everything has to be perfect. Right?

So credit's the adoption framework. So So what are the adoption question? These are the five, w's.

Who should I ask if I have a problem? There are so many times when people roll things out, and they don't clearly say, if you have an issue or a question, go to this person. Be extremely explicit. Should they go to their manager, or do they go to me? Who should they ask?

What should I be doing? What are the exact steps I need to be doing at what time?

When should I be doing this? Is this every day now? Is this once a week? Is this a way when this action is triggered? Do I only need to do this when I get assigned to task? Do I only need to start doing this with at a certain deal stage? When should I be doing this thing?

Where should I be doing it? Should it be in the CRM? Should it be in this spreadsheet? Should it be in Slack?

Where should it be, and why should I do this? Why are you making me worse at my job in the short term? What is the long term impact? Is this for you, or is this actually to help me?

We take these for granted. We say they're so obvious, but we don't actually over communicate these. And so, of course, people get confused.

We roll things out, and we don't say why.

We want to roll out a new pre sales scoping process so that we can actually, get alignment on the entire process, get approvals quicker, get our statement of works quicker to our clients, and really understand how long it takes to do these and where we're successful and not successful. Right? There's very clear metrics and dynamics in place on why we're rolling this out.

So what are the tactics? Right? What answers those five w's?

We celebrate the actions.

We remind about the actions. We enforce them. We define them.

We inspect them, and then we train.

Again, not the right order, but all of these things can be done and should be done when when you're trying to figure out adoption.

The characteristics, what is the rhythm?

When when are these go to occur and when do these appear? Do they appear in a predictable pattern? Do we always celebrate the same way? Do we always enforce the same way? Do we set the expectation for users?

These are the requirements. And is it accessible immediate? Can we see the outcomes and answers? Can we see the reports immediately? Do we get the notifications?

Do we get that, you know, constant feedback that we need to actually understand if we are adopting this properly?

So that's the credit framework, and all of those questions, tactics, and characteristics are all kinda in this one slide if you kinda wanna look at in one place.

So do you guys have, like, an adoption framework or a process, or do you guys have some kind of adoption period built in, or does it change every time?

Like, I've made it very clear to my team over the next three weeks. Like, nothing new is happening because we are gonna adopt, you know, this new ticketing process.

And so that's kind of how I define it, but do you guys do anything similar?

Maybe, maybe not.

Okay. So what are some detractors to adoption?

Course Excel and Google Sheet. They destroy progress. They influence bad behavior.

Right? One person does it. They bring all their people on their team, and now you have this rogue spreadsheet.

Databases every database makes adoption more difficult. All these tools wanna be CRMs.

They all want it. They all want you to live inside them, but every other database makes it so hard to manage. I know so many people on this, including myself, who have five or six things that you own, and it's so difficult to make sure all six are, you know, are correct and clean. Just doing one database to CRM is more difficult. So everyone you add just makes it that much harder. And then how you onboard and roll things out. You can either have champions or haters.

The way you do this in the beginning, those first impressions, you can immediately have champions that buy and that help their teammates, or you can have haters, the ones that create the spreadsheet, the ones that say, I'm not following this process. So be intentional about how you onboard because the more champions you create, they'll flush out all the haters.

So let's look at specific tactics as it relates to, like, what does it mean to use the credit framework? So celebrators, a lot of these are notifications, email, or Slack. An example is a company wide notification when a deal is won.

Soon as we close a deal, it automatically goes to our company channel, and everyone can emoji and comment, you know, great job. It's a great seller. You followed the process correctly.

Reminders. Remind about actions. These can be notifications again in email or Slack. Hey. Your close date is overdue or old.

Please update it. These can be, like, DM notifications, or it can be a a a more general public channel. And then updates. Send in app updates about new features and where to find how to guides.

So consist consistently remind people, hey. This is a documentation. This is where it lives. If you need help, you know who to go to, but this is also a resource to use.

How do we enforce action? This is probably my favorite. It's the little hammer, you know, on my shoulder. Require properties, or validation rules in Salesforce.

You know? You must have a contact. You must have this deal filled in. Entry and exit criteria.

This is very common in, like, deal stages, but add entry and exit criteria. You cannot move to the next stage until you fill out this exit criteria. Right? And then maybe a commission game.

Right? Acquire property to be complete prior to paying commission. So you can see required properties. These are like, this is more like automatic.

These are these guardrails that will, like, literally error out if you don't do them. Entry and exit criteria, this is all about documentation training being more effective as a seller. And then the incentive based one is, hey. If you wanna get paid, you need to kind of fill this out.

So there's different ways to enforce actions based on different criteria that you have.

So let's look at the the back half of the credit framework defining defining fields and workflows. Do you have a data dictionary? Do you have embedded content overlaid so that you can actually see where this stuff lives? And if someone says, hey. This new drop down menu is, required. I don't even know what the values mean. Where can I find them?

Inspectors, are you inspecting the actions on a frequent basis? Are you attending the weekly sales calls or the weekly whatever call to inspect that this process is is following?

Things like deal tags. I'm not sure if, Salesforce has something similar, but other colored filters, other different views to say if a deal is in danger or if it's healthy. Right? Not all adoption has to be negative. We can actually we can reward good adoption as well. And then reporting. Can you schedule a daily or weekly reports to the manager or the executive team to, talk about tangible, progress?

And then finally, training.

Right? Do you have a repository of training on how to create a deal?

Do you have an issue tracker? So if this isn't working, help me. Right? It's, some people, like we have, like, a form that people can fill out if they have an issue.

They don't always use it. A lot of times, they just Slack people, but do they know where to go if this isn't working? I don't know if you guys have had but run into issues where someone says, man, I spent thirty minutes trying to find this thing. I couldn't do it.

I'm like, just just ask me. I I could find it in thirty seconds. Right? So have the location for you to just say, hey.

I need help. Don't enable them to not follow the process or not learn the process. But if they do have help, or they do need help, definitely don't help them. So document and train.

So when you get to that, when you combine CRM as a product plus the adoption and the credit framework, you get success.

This is what we're doing, not just for CRMs, for any tool or any initiative that you have within your company or department. We want the impact to remain, high over time. Doesn't matter if the impact is super high and short lived. We want it to remain over time. This concept of feature releases, consistently looking at what you have and what you have to do, organization, communication, visibility, all of these things really, you know, are a key component to, you know, really mastering these two things, which is treating your tech stack as more a product, product than a project and really ensuring adoption to get a success.

So with that, we do have one more exercise in the workbook, and then I can definitely answer questions as well. So quickly, the, we've got slide five here. And so this is pick a future process that needs to be adopted and apply the credit framework to it. So name your process and then go through the credit framework.

So celebrators, reminders, inspectors, definers, enforcers, and trainers. And right here, what you're gonna do to apply this to it. So, hopefully, this is something you're working on in q three, and you can think through all these six different actions that you can out now do to really get better adoption earlier on. And I do have an example if you wanna look at what this looks like.

And, again, guys, like, I don't I don't give you these things because I don't like. I use these myself, and so this is literally a process I'm rolling out in q three or just begun. And these are the things that I'm gonna do to kinda roll it out. And so all of these things I use for myself internally, and this is a real world scenario of exactly what I'm going through.

And this framework has really helped me go from, hey. This is passive adoption. You guys deal with it, not at problem anymore, to really activate the option. How do I do all six of these things to ensure the success, of of this specific process?

Right.

Let's see if we have any questions. Go ahead. I'm not sure who it was, but go ahead.

This is Kevin. This feels like maybe a silly question, but would you also go through this whole process here, for something like a process improvement? Or What's an example? Like a a change or an update in a process?

What's, like, an example?

Let's see. Okay. So for existing business, we use Medic on expansions today.

That same team doesn't use Medic's today on renewals, and we're soon gonna be rolling that out.

So it's it's a process they're familiar with. There's gonna be some changes to make it a little bit more specific to that opportunity type.

So we're kinda technically rolling it out. There's a few changes involved with it, but it's not necessarily an entirely new process.

Yeah. I mean, I think this applies. I mean, who doesn't like getting a site message saying they did a good job? Yeah.

If renewal is the medic like, the metrics, it it's probably different for renewals than it is for net new. Right? Because they're already a customer. So you're gonna need to define what medic means for renewal stuff.

We have I've had a customer that did that, and they had totally different definitions. They have the same fields, but different definitions.

Enforcers, if they're not used to be doing if they're not used to doing this, you're gonna have to set up their required properties or whatever you need to enforce it to make sure it is. And so this definitely works with process, like, process updates as well. And I think it it really establishes kind of the expectation of, guys, just because this is a process update does not mean we don't follow the same process and really go through the entire framework to make sure it's adopted. Because what happens, especially in that case is, hey.

They kinda do medic. They whatever. It's the renewal pipeline. They'll figure it out. They get one Slack message.

And then what happens three months later? You're like, damn. They they never picked this up. And so I would recommend following a similar process just to make sure you're thinking through things.

Maybe you don't need inspectors or, you know, celebrators or whatever, but at least thinking through it, I think, make sure you have your, bases covered.

Actually, I disagree.

I think inspectors, you need just as much because you you No.

No. That was, I wasn't I wasn't using that as a real world example. I was just saying in certain things yeah. No.

I trust me. I totally agree. The inspectors are kind of the most important part. No no issue there.

Catherine had a good question. How do you get a sales leader on board when they don't see the value in the change even though rev ops and their team does?

Well, maybe Catherine can come off mute, but, like, what what is the value? How do you communicate it? How is it gonna help them hit their sales goal? Maybe you can kinda speak to what this change is and why the sales leader doesn't see the value. Well, and let's see if you've articulated it in a way that makes sense to others.

Really just kinda thinking through, like, some of the process that we've tried to implement before.

One of them specifically was Gainsight, you know, just a big tool.

We had a Gainsight admin, and she was, you know, trying to really implement and adopt all these, like, really cool features. We do think that she might have been doing things a little bit too robust, kind of like Yeah. Going from zero to a hundred instead of, you know, slowly accelerating.

However, it was really a a whole thing of tug of war, to where some reps would adopt because they're like, wow. This is a great idea, but then other reps would really follow in the more or less the footsteps of the sales leader that was like, man, this seems kinda like a waste of time. So that's that's kind of my thought process. You know, how whenever it's not, like, a hundred percent adoption with a sales leader, it feels like there is a really big tug of war scenario to where everybody jumps in with both feet.

So, specifically, it was just, like, sales reps having to provide more information when they close a deal to, like, the customer success team so that they could port it over to gain insight?

That could be. Yeah. One scenario. It was it was really just gain side in general, like, you know, creating, like, risk CTA adoption and, you know, all these different process throughout really the whole cycle in general.

But, yeah, if we wanna focus on that, that's absolutely Yeah.

I mean, I think, like, again, defining what, you know, the key metric is. And so, if you think about, like, the sales perspective, if you have a better handoff, your customer's gonna be happy. They're gonna be onboarding quicker. They're gonna, receive value quicker and hopefully renew for longer.

And so I think it's kind of, like, self serving not to kinda think of the big picture for that sales leader and think about how it affects other people in the company, especially I know I know Terminus is a recurring revenue business. And so it's it's hard to know what specifics, but I think the reality is you need other, champions and stakeholders within that same level, kind of his or her peer, to really talk through some of the benefits from it. And, you know, just because it doesn't benefit you personally might not mean it doesn't benefit other people and other teams. And so I think the teamwork element comes into it as well.

But I could see, maybe someone, you know, in your seat or seat like, I have a lot of times where you're maybe not able to elevate that conversation to that person, so you might have to go to kinda your manager to see kinda where they fit in. But if to your earlier point, if they do over engineer it and it's too much at once, I think that can be kind of a detractor that has some relevance to it. And so that's kinda why I I kinda sometimes think about that that MVP approach. How instead of making the sales team do fifteen more minutes of work that they're gonna immediately say no to, how can they do five minutes to begin starting this process?

And then you add maybe five on top of it, or maybe you figure out a quicker way to do it, and you're not having to do all these things at once. And so I think kind of an MVP approach makes a lot of sense. And then you should potentially be able to, like, automate things and make things a lot easier. So an example that I have is that our sales team had to fill out, like, a template at Google Doc to pass it over to the customer success team once they closed a a client.

It's a very manual process. And so I built that into, like, a HubSpot playbook, and then it prepopulated, like, a note that was already filled out by the stuff they added to their deal. And so the process fundamentally didn't change. It actually saved time from the do it, and they got really on board because it was a time savings.

And so there might be some unique ways where we think of new systems always having to add new things. But what can you already take from what they have earlier in the deal, or can you require properties on stage two or stage three so they're already ready to go when that deal moves closed one? What I've seen with other customer customers is that they move something to close and they're like, congrats. You closed a deal.

Here's forty things to fill out. Well, no one wants to do that. Can we add some of those earlier in the sales process so that they only have to fill out ten when they close a deal? People, you a lot of times don't necessarily think that these might apply further up the funnel and wait till the very end.

And so how can you kind of, like, layer things throughout the process rather than saying, congrats. We're so happy you closed the deal. Now go do your twenty minutes of homework. So it might not answer your question exactly, but I think there's an MVP approach.

There's how do we layer things slower so it's not all at once, and then how do you get kind of that peer to peer buy in where it says, hey. This might, you know, temporarily make your team have to spend more time, but we're we're a company here. We're a team here. This is a team effort.

We want our clients to be more successful. So So if we can agree that we want happy customers, can you agree to do this with your team?

An approach like that may may work.

Yeah. We definitely have the mentality, and we we have a saying here that we use all the time. We have to slow down to speed up. And that was, like, really what we were trying to stress throughout the whole process, and it didn't seem like it was still kind of sticking, even whenever we were saying, like, slow down to speed up. Let's go ahead and add these couple of things here instead of having to do these couple of things here.

Instead, like, in regards to the CRM, we have Salesforce.

And so, you know, we add these couple of fields that they have to or they're supposed to fill out, and, of course, we have, like, the validations that give them errors when they don't. But then it's you know, we end up getting more or less complaints of, like, oh, well, this is a lot. This is a lot to have to fill in, but the information is vital.

Are they the only people that know this information? Or, like, is someone been on the contract or somewhere else where, like did you go into a deal and fill this out correctly based on other information that they might have?

So our fields come from different places. Sometimes it is, you know, put on the contract that the customer fills in. Sometimes it's, you know, just conversation based with the AE and the customer or with prospect.

Sometimes it's things we get from, you know, outside sources, like whenever we had Zoom info and and different stuff like that.

So it really just varies. But more or less, I'm Yeah. Thinking more or less the times whenever they should be on the call have Salesforce up and, you know, put in their notes and go ahead and fill out these couple of sections instead of, like, you know, the example earlier where you said, well, why have seven sales calls today?

I don't I don't have time to go in and and fill all this information out.

Well well, Catherine, if we all if we if we all had our notes up and we all had our second tab and we all I mean, like, I think it's, I totally sympathize with you. I just don't think it's very reasonable. I think, we're all humans there, and so they might forget. And so say, hey.

Maybe I can fill out ten deals for this person and gain that trust of them and say, hey. Catherine really helped me out here. Maybe I'll help her out in the future. Or maybe you can sit down one on one with the rep and have you have them walk you through this process and really figure out how cumbersome or how kind of annoying it is.

Mhmm. A lot of times, if you set time on the calendar with someone who's not following this, it's very hard for them to articulate why they might feel bad if you spend the time to sit down with them and go through it. And so, look. I wish all the notes were organized in a perfect way all the time as well, but I think sometimes we need to be a little bit more realistic about things because, there's a lot going on in a sales call, and the last thing they're thinking about is recognizing their notes sometimes.

So but it's it's difficult. That's why you consistently try to do this. Can you Can you inspect it in your Jason has a question.

I was just, in response to Catherine's comment, I do think that it it's something worth taking a moment to think about whether or not doing it for them one time is encouraging them to start treating rev ops like admins.

I've seen a lot of struggles, right, with getting accurate information inside of CRMs.

And just from a, like, a coaching standpoint, I I understand the theory of, like, hey. Let me show you how to do it. But I also have seen that turn into, oh, great. Just can you do this for me one more time? And then it just sort of becomes a habit. Right?

Oh, yeah.

That's potentially not good coaching to teach, right, as opposed to, hey. I can help you through this or look for ways to streamline the process.

And that's really where I'm, like, trying to bring in the sales leader, just because it's you know, the reps are they they have this tug of war just trying to adopt it and having the support to adopt it. But if the sales leader isn't adopting it or because they don't work in it every day, and they're like, oh, well, just don't worry about it right now. Just have, you know, so and so do it rev ops do it for you real quick this time.

Yeah.

That's whenever the adoption is the issue, and that's why I brought up the sales leader and and how to really bring them into the adoption.

Yeah. I mean, I think it it's, to your point, Jason, I think it's personality based. If you are the rev ops chair, which do you prefer? I am kinda more aggressive about it.

And so I'll say, look, man. I helped you out last week. You know, help me. Like, it's kind of like, it depends on the relationship.

I will also publicly kind of say, hey.

I see all these deals are missing x, y, and z. Could we could we, you know, think about why that is, give visibility to other people in different apartments? You don't wanna be, like, mean about it and, like, passive aggressive, but I think you need to take different strategies and different approaches. Make it visible.

You know? Who who else would would keep these sales leader accountable?

And I totally get the if you, you know, give them as a cookie, they're gonna ask for more and more and more, But you kinda have to be ready for that and kinda mitigate it. And so there's different approaches here. This is why it's such a tough domain and tough topic. There's a ton of different ways to do it.

And so, whatever works for you, probably work for you. But, you're right, Jason. Like, if you are gonna commit or if you're gonna there might be consequences to actions. And so if you're not ready to to kind of mitigate that consequence immediately, then maybe you take a different approach.

But at the same time, sending a Loom video over and over again saying, I told you to do it last week. That that approach also doesn't work on the time either.

Absolutely. And I agree with you there. I think the I think, you know, this was discussed a little bit. I have also found that sort of making something in you you know, I come from the automation side, so, obviously, there there's ways you can put certain functions in the process.

Right? And and part of queuing up the deal itself also involves, like, documenting this. I've also found, like, you know, you know, because my my team does a lot of presales design, and you're sort of getting pinged when they're trying to fill out the CRM. Hey.

What did we do here? And then Yeah. What that tells me is that is there's a lot of you get a lot better information if you made it a ongoing process through the discovery cycle to document what you're doing.

Oh, yeah. Yeah. Yeah.

And the same thing goes for, like, you know, I'm working in Jira and Zendesk and other tools, and same thing.

I've I've had to coach my team. It's like, no. I need you to document the stages of this so that I'm not trying to get a ten page follow-up when the technology blew up. I need to understand the journey of how you and that engineer put this together.

Somewhere, someone made an incorrect assertion, and I need to sort of understand how that came to be.

And that doesn't Yeah.

You can't look retrospectively and be accurate to how you got there, in my opinion.

Hundred percent. Guys, this stuff is hard. That's why we all have jobs. Right? Because a lot of people don't wanna do this stuff. It's really difficult to do this stuff.

If it was easy, I wouldn't have a job.

Right? So Yeah. Exactly. So, we're already able that's over. I I do appreciate everyone. Like, it doesn't matter what role you're in, you've had to kind of either get adopted something yourself or try to get other adoption.

And so, I think it resonates with everyone. So if anyone has any more, you know, comments, feel free to reach out or put it in Slack because, this is something that I have not mastered. And I'm going through it right now again, and I I'm trying to remember the principles that I'm trying to teach because it is so hard to go through all six of these and just keep on it every single day. We all have a hundred other things to do.

So, good luck in your adoption techniques. Go ahead. Think of it as adopting a puppy. Think of that little man or woman on your shoulder, having a little hammer, reminding people to do things a certain way, and, and good luck because certainly something that I'm trying to continue to learn and improve on, because I don't feel like I'm an expert either.

Thank you, Brian, as always. That's all I got. That's all you got? Final words? Okay.

Alright. Great. Great. We'll thank you for sticking around.

Yep. Thank you. Everybody, again, we'll we'll we'll not see you next week, but we'll come back on July tenth ready to rock and roll. Okay.

Thanks, everybody. For reading it. For everyone, please take a moment to share your feedback in the Zoom chat. This link is there. Have a wonderful week ahead. Feel free to reach out with any questions. Thank you, everyone.

Bye.