Mark Lerner:
All right, everybody, welcome back to the RevAmp podcast. I’m here today with Nick. I’m really excited to hear more about his story and his insights. So why don’t we go ahead and go ahead and introduce yourself for the folks at home. Nick.
Nicholas Gollop:
Thanks, Mark. First of all, thanks for the invitation. It’s a pleasure to be here. Yeah, so my name is Nick. I am currently a rev ops and go-to-market strategy advisor for SaaS B2B tech companies, and basically spent my entire career in operations; started in sales ops and then progressively got exposure to mark ops and sales ops and then grew into revenue operations and currently actively fighting to get that concept out and about and getting people to really understand the value and understand the role and move away from the concept of just being a system admin and the typical understanding that you get when you talk about rev ops with people who don’t really understand the role. But yeah, doing this for almost 15 years and haven’t done anything else apart from that. So that’s me.
Mark Lerner:
That’s fun. So you’ve had an opportunity to kind of be in each of the silos, let’s say, that make up the rev ops kind of umbrella. Would you say that the responsibilities and challenges are unique things? Are they similar across each of those for marketing ops and sales ops, or are there unique things for each of those that people might not fully understand?
Nicholas Gollop:
I think they’re similar from a daily perspective. They’re similar from a high-level perspective, but the day-to-day is actually as in the activities and the things you actually do are different, right? You need different skill sets for different ones. You can’t necessarily go from sales ops to mark ops as a jump – as in just moving the – I’m not saying you can’t do it, I’m just saying that it’s tougher to do that if you don’t have an understanding of how to run campaigns or how to properly manage the marketing flow, the spending budget, so on and so forth. You need some idea of what that is to properly excel. And I would say then from a classic sales ops and then customer success ops, they’re the ones that I think are a bit more similar. But again, you also need exposure and an understanding of how the customer base works. It’s different from prospecting; it’s different when you’re trying to understand the usage of platforms or depending on what your product is. So there are nuances, but I think what I would say a complete kind of ops professional would have to have at least two of the three under their belt.
Mark Lerner:
So one of the things that I kind of wanted to focus on today was the concept of data integrity and ensuring that data is the same from when it first kind of gets added either and all the way further down the lifecycle. And so each one of those kinds of pieces we’re talking about has their own additions to let’s say, data, whether it’s automated or not, as well as needs. In your experience, I guess we can start here: have you found that in organizations where it was siloed, right, there were no rev ops – did you find that there were issues with data being passed from one stage to the next? Were they similar issues across the different experiences or, yeah, I would just love to hear your kind of experience there.
Nicholas Gollop:
I think the whole data idea of data and having the whole single source of truth of one, having in one system, single source of truth is a whole topic in itself. I think I believe that that should be the North Star, the ideal.
It’s not possible. You just don’t have that. Even in large organizations with a much more robust data architecture and structure, you don’t have that even in Salesforce. I had Salesforce obviously as a CRM and business object and Tableau for data visualization, even though Tableau is just a data visualization business objects for SAP did all the territory planning and all the idea of baseline comparisons between regions and territory. So that concept, I think, is good in principle as a theory but not in practice. It doesn’t really exist. But the data integrity, as a whole, really depends on the people using the systems and how it was built and idealized because you can have a Ferrari but go through a bumpy road; you’re not going to really do a lot with it.
And if you don’t have a super effective car, vehicle, whatever, but the road is smooth, it’s also you don’t feel like you’re doing what you could. You could be doing a lot more. So I think the idea with data is garbage in, garbage out, and you have to have some level of structure, some level of foundation to be able to do what you really want to do with it. And this, I think, is what companies overlook. The bigger you get, the more data you have, but the more noise you also have. So you get big, you can still have a lot of data and structure, but if you don’t really know how to harness that, it’s also pointless. But the same concept happens in smaller ARBs where there’s still a lot of data for the size, but if you don’t know what to do with it, it’s also pretty useless. And if you haven’t built a structure to harness that, it’s also just thrown in there. So that’s why I think the analytics side of the house is the last piece that you need to focus on because you can’t analyze data that’s wrong. You need to first fix the wrong data to then be able to analyze it.
So, that’s my take.
Mark Lerner:
Yeah, that reminds me; I think you and I were on a webinar in which we discussed this concept of a single source of truth. And I think you took the side that it was an ideal but not a realistic thing. And I think your conception was that there was a need to have something like a data lake to kind of act as the repository of all that data and be the centralized distributor to the different systems. What do you think the value of something of maybe for the folks at home, what a data lake is? And why it’s important in the context of what we’re talking about right now.
Nicholas Gollop:
So first, defining what a data lake is from a person who doesn’t actually manage or implement data lakes. I’m not in engineering or anything like that, but it’s essentially a place where you store data in a single unified format
Or as much as possible. So when you’re trying to export data from a specific CRM, or you have Excel CSV, there are all these formats, and depending on where you put that format in, it gets read in a different way, and it visualized in a different way, so on and so forth. The idea of Data Lake is to streamline that well data in a format that is as close to interpretable as possible for multiple systems. And the data lake usually connects multiple different systems coming from multiple different places. Wireless a Salesforce doesn’t necessarily out of the box or a customer success platform doesn’t. CPQ doesn’t, and so on and so forth. It doesn’t necessarily matter. But the idea of having the centralized data lake means that you can plug everything in, it puts all the data there, it puts it into a query that is interpretable across the board, and then you have a much easier way of harnessing that data and reading it.
So much more complex than that for sure. But the general idea is to have one centralized place, and if you remove that piece of the puzzle from the puzzle, you then have systems that are not necessarily pointing anywhere. And if they are pointing towards each other, they cannot really read the data instead of doing this, you’re doing this kind of thing. It sometimes might read, but it doesn’t all the time. And you get issues with integrations, you get issues with data being imported in different formats or incorrect format and so on and so forth. But that’s the general idea.
Mark Lerner:
Yeah, so I guess to visualize, it’s kind of like the difference between a web and a hub and spoke type of thing, whereas the central data lake would be the middle of the hub and spoke and a web or just kind of interconnected tools that all were meant to kind of be independent systems, maybe have some information coming in, but never meant to do this normalization where it created, let’s say something like a unified record across all these different tools. Because a very big challenge. And I think that talking about this idea of data integrity and ensuring that data’s correct, I think anybody here that’s ever worked interacted with a CRM, let’s say, or that has at least one integration has come across this; you get duplicates. It’s spelled one way in one record, spelled another way, another record in your marketing tool. The domain is different or something.
And it creates if you’re a smaller company managing these things manually, not so hard. As records multiply, this becomes a massive challenge. And at a previous job, I had a colleague he was the VP of revenue at a relatively large SaaS business subscription-based business, and he said his number one focus, his number one goal in his role, was data integrity. And because of the type of subscription models they had, not only was it important for him and revenue recognition and ensuring that the deal they signed was the same information that finance was looking at and then reporting on, but it was also for cross-selling and upselling opportunities because of usage and being able to ensure that all that data was correctly assigned. I thought that was a really interesting note because of the concept of revenue recognition, and I don’t know if this is necessarily in your real house or how much you think about it or anything like that, but it becomes a big problem if you’re charging someone billing somebody recognizing revenue and then having to go back and realize, actually no, that’s not correct. We have to scrub that. And it causes a lot of issues. And it not only affects your credibility, but you have issues with all sorts of legal and accounting issues.
So have you come across that as a problem in the past? Have you kind of interacted with issues regarding that?
Nicholas Gollop:
Yeah, I think the whole idea of data integrity is very crucial and should be center central to pretty much every business. And it’s not just the data that we input, but it’s thinking about the output, what we get from it. Because, sure, the reps can, or anybody can fill in this and that from a deal perspective to be able to close your deal, but what the moment that they flip the switch and start seeing that as a piece to something bigger, the opportunity that you first create for the prospect, all the details that you put there as a BDR, and then you move on to the sales rep, then the sales rep can already take that information if it’s correct, assuming everything’s correct and already act on it and understand the deal a bit more. And then, moving on to the customer success managers, they can also take that and design the scopes of work, and build enormous customer journeys depending on customer plans and onboarding plans.
So the data is essential to drive the customer journey across the board. It’s even more than just the actual fields that we actually do. But even more so from a legal perspective, countless times, there was one company I worked for where we were still trying to figure out if now was the time to scale versus be scrappy. I think this is the central piece of probably most of the issues. What can we do that will allow us a bit more speed versus agility versus doing it correctly? And my job was obviously to build those guardrails and approval processes and making sure that we were doing things according to not only the company but also laws. And we had countless times where the deal would eventually to this point where we wouldn’t have super rigorous checking on the actual data, and then we go through the entire negotiation with the customer prospect to then get at the end, and the people just announced this massive deal closing. And I’d be like, well, I didn’t see that one.
And we then get to the end, and the deal’s completely wrong. It doesn’t comply with any of the rules that the company would expect. So then you go about building all the approval process, making sure that we have a proper pricing and quoting mechanism in place. So yeah, multiple times. And then we have the crucial decision to either let it go or go back and fix it. Depending on the industry, going back and fixing it is a bit of a problem because you might eventually lose a deal. So it’s always that kind of balance that we need to find. But it’s really tricky.
Mark Lerner:
And I would imagine if you’re to working at a company that is a multinational, those legalities are different. Even within, let’s say, I’m talking to you from the United States, even within the United States, different states have different legal rules on slight variations. Obviously, the EU has its own thing. And so there’s a lot of complexity there. And I think that especially if you zoom in on a sales rep, they have one goal, which is quota, and they’re incentivized on that. And so they’re kind of maniacally focused on that, and they don’t want to be bothered with all this other stuff. And so you mentioned the concept of guardrails, and I think that that’s an interesting concept. I wonder, when you were working in that context, and you had deals in trying to create those guardrails and approvals, did you build kind of a formal deal desk process to do that? Or was it, yeah. So what did that look like?
Nicholas Gollop:
Initially, I was the one doing that. I usually, so if you’re hired to be the first rev ops person to build a function, most of the things you do yourself, but that’s kind of expected if you’re hired to then inherit and just maintain, that’s a different story. But most of the time, I had to build a function. I hired everybody and kind of built the teams from scratch. At the time, I was the only person doing it, so I had to kind of roll up my sleeves and just get it done. So I basically centralized a deal desk function within myself. And sure, at times, it got a bit overwhelming at the end of the month and quarter, depending also monthly businesses and quarterly businesses behave differently, but I reduced the margin of error to 1%, even though most of the people might come back and say, well, is that scalable?
You got hundreds of requests and all that. Yeah, sure. But it wasn’t something that I was going to keep on doing for a long time. So by doing that, I proved to the business that we needed a deal S function. It showed the amount of errors that we had per order or per collection of orders in a specific given period of time was around 30% obviously. And after that, I then show that it was decreased to 2%, one 2%. And still, it’s bad because it should be zero. You cannot let some things go. But the issue is I was doing it myself. So yeah, naturally, that’s going to be an issue, but if you have a team or a structure there, it’s even going to be less. But proving the value to the business made the business move on quicker to hire a deal desk function. And so they did, and that was the end of that. But it happens quite often.
Mark Lerner:
Yeah. Yeah. I’m trying to think of where to take this. So many different strands to follow here, but you mentioned this tension between moving fast and being able to, and then as you said, do it right. One of the observations that I’ve had over the last three, four years, I think covid and it’s things that have happened since then have really kind of sped this up, is how quickly the external environment changes and how much that impacts the way a company runs. If you have this rigid system in which you just can’t incorporate external changes fast enough, you’re going to die. And I think we’ve seen that. And so that requirement to be able to adapt quickly, I think, adds to that tension. And it seems to me that I’m not sure how much companies put importance on building this resiliency and adaptability into their process, and into their go-to-market. In your work advising companies, when you come in, is that a piece of the puzzle that you look at and how do you build them or help them build themselves to handle the big changes that are inevitable that we don’t know are going to happen, market conditions change or whatever?
Nicholas Gollop:
Yeah, that’s interesting because most of the companies that I worked with in the past had initially no clue of what RevOps was. They knew that operations existed, but they didn’t really know how that was supposed to be shaped. So it’s tricky because you don’t know what you don’t know, so you can’t go after rev ops or something if you don’t know that thing even exists. Most of the companies I worked with had no clue what they were supposed to be doing or what good looked like because they never lived unless we’re talking about non-first-time founders. So if we’re talking about people who’ve already started companies and then sold these companies or iPod and then left and something else, that’s a very different story. We are usually the first team to be hired rev ops, but in general, they’re not thinking that far out ahead because that’s something I was talking to a friend of mine who’s CEO of a company recently in practice from a day-to-day perspective.
If you’re a pre-seed series, a CEO, and you are focused on tomorrow, you need to get through the day. There are so many things happening at the same time. You have a team of 60 people, and if best and you need these small things that have a massive weight on you and you need to get through the day, you’re not going to stop to think about a year from now or six months from now. And you’re not really putting a lot of effort and energy into that thought because you need to sell, you need to hire people to build a product, you need to hire people, HR, and you need to hire people to sell the actual products and services and whatever it is. And that’s your priority. You’re not thinking about the quote that the person’s going to build if there’s an approval process; it just doesn’t cross your mind. And the moment you start talking to them and going through the processes and the things that you could potentially achieve by having these things, you then see on their faces aha moment or a light bulb – a switch. And then, the conversation takes a very different turn. And it is curious because even though sometimes they know that it’s something necessary, they still dunno how to action it, which is why advisory is interesting. So you can give them guidance, not necessarily do it yourself, but giving guidance on what should be your next step.
But it’s also a personality thing. It’s the same way that we look at companies that are small versus big VP of Sales at a massive corporation. We’ll probably not a hundred percent work to build a world world-class sales organization in a smaller company because they’re accustomed to a very different modus operandi. It’s a very different way of working and vice versa, right? Your VP of Sales at a 30 people company, you’re not going to be VP of sales in a massive organization. It just doesn’t work. And these personalities need to be taken into consideration when you are scaling because people behave in different ways. And that is, I think the primary thing that we need to consider when dealing with operations is the people.
Mark Lerner:
So as we round things out, I know that you’ve been spending more time working with different companies advising. What are some of the similarities or trends that you’ve been noticing that maybe some sort of insight into where the future is taking us? Are there things that you’re seeing across the different accounts you’re working with that are similar that might tell us, Hey, this is kind of coming down the pike?
Nicholas Gollop:
I think 2024 is the year the companies, the smaller organizations are going to realize that they really need to think long-term. And this is the direction I think that we’re in, and obviously, I’m not talking about AI and all that. Those are more the tactics that you’re going to use to get there. But the general trend is towards stopping looking at tomorrow, especially if you’re a C-level, CEO founder, whatever, stop thinking about tomorrow. Look at least six months or a year ahead, really, right? And don’t keep creating these enormous, inflated numbers to then not hit them again, do something realistic and have that outlook that is further than weak. You know what I mean? Because in 2021, 22, and 23, we started pivoting, and companies that realized that they went too quickly past the product market fit phase and went straight into go to market, they realized that, well, maybe the product isn’t really ready.
So I think we need to scale back and go back and do everything again and start from scratch, which results in layoffs and what we’ve been seeing. And now they’re going back to the drawing board to figure out where did we go wrong with our product or where can we improve to then go back and sell it to the market? Because what’s the point in having a product wants or it doesn’t fit? So now we’re going to see in 2024 companies moving back into the or start moving back into the go-to-market with a bit more nuanced thinking. So you need to really figure it out. And since they’ve lived through issues before, hopefully, they’re willing to do it correctly again.
Mark Lerner:
So I really appreciate that. I really appreciate your time today. Thank you so much. Before we end, do you want to tell the folks the best places to engage with you or see your content out there where they can learn more about you?
Nicholas Gollop:
Yeah, I primarily post comments, and write articles either on my website, RevOps On Demand, or directly through LinkedIn; easily reachable through there and respond pretty quickly. So yeah, happy to connect with anybody who’s interested in learning a bit more about Ops and go-to-market as a whole.
Mark Lerner:
Alright. Thank you so much, Nick. Thank you for your time, and have a great day.