Podcast: Decoding Revenue Operations

Thank you to Trygve Olsen and Dave Meyer for inviting me to the Dial it In Podcast from Bizzyweb to discuss revenue operations (RevOps)!

If you'd rather watch and listen than read the blog below, here is the audio and video:

Or you can listen on any of these platforms:

• Apple podcasts
• Spotify
• Amazon Music
• iHeartRadio
• And you can also read takeaways on the Dial it In episode site 
  

The concept of revenue operations is a wide-ranging umbrella that covers a lot. So what does that actually mean?

That is the question: What is RevOps? I've been working on a book, and that is the title of it because there are so many different definitions. Pretty much every person and every company has a different definition, but some of the things that are common across all those definitions are combining operations for all the revenue-focused teams (sales, marketing, customer success) and really tying those together and aligning them. That's our favorite RevOps word, alignment. To make a better customer experience, which ultimately results in more revenue.

So, all things revenue, but probably a little bit more from the nuts and bolts and tactical side as well?

We try to avoid the word 'tactical' because that leads to a whole discussion about tactical versus strategic, but I'd say more on the people, processes, and tech side.

Trygve also explained RevOps as: the easiest way to get money from a customer is to deliver results and make them happy as quickly as possible. And so RevOps is building the infrastructure that allows your entire team to do that. Not just salespeople, because if you interact with a customer in 2026, you are a revenue driver. So that customer service person is [a revenue driver], that operations person is [a revenue driver], because everyone's really giving them an experience. Everybody needs to have a symbiosis where everybody's working together, and building the infrastructure is really the concept of RevOps, Trygve said.

As a fellow HubSpot bootcamp instructor, Trygve also participated in the first cohort of the RevOps bootcamp, and said he knows alignment is a big word and concept from class.

When you're talking about aligning sales, marketing, and service teams, what are the common misalignments that companies have?

I think the misalignments are when one team doesn't know what the other team is doing. When people hand off [customers or processes] and just shove them to the next team, not thinking about them again, not knowing what happens. That's not a great customer experience because customers have to repeat themselves, for example, or complete the same actions for the next team. The next team handling the customer doesn't have all the context they need to do a really great job and serve the customer.

If someone identifies that as an issue, what's the next step to actually start getting aligned?

The next step is one of the big topics I talk about: process documentation. This is a great way to start getting aligned. So few companies actually do it. Even fewer are doing it well. So even if you just make an attempt to document what is happening in your company (the processes, not just how the tech works), you're already ahead of the game compared to many other companies.

Documenting what is happening now is going to help you get on the same page, which is being aligned about how processes connect and overlap with each other in different departments.

And then you or other leaders can make clear decisions about how to improve the business, together with those teams, rather than just telling people what to do with no context. So that can be one way to help get alignment.

Trygve talked about when consulting, leading classes, and working with folks who are trying to rebuild or re-up their RevOps, you see a few things that are just consistently wrong. One of them is a lack of process documentation, not having all the things written down.

If we were RevOps doctors, what's the first question we would ask them? What's the 'where does it hurt' question?

Ask them about what people are complaining about the most, both customers and internal people. There's probably something in common between those two major groups' complaints.

Are people in your classes just struggling with revenue…or are there other sneakier issues that are popping up? Like a sales team is unaccountable. What are some of the common ones that people come to classes with?

 I don't think there's one common issue, but a lot of people just weren't given the time or haven't been able to make the time to set up the foundations, like documentation, process mapping, making project lists, and making road maps. Maybe immediately when they started their job or fell into their job, as many operations people do, they already had a big backlog to work off of and just weren't able to communicate that they needed the time to make a road map and do all of these foundational things to actually make all the work more efficient and solve bigger problems.

Trygve said this is fascinating because this is the work, aligning and documenting processes, that is so unbelievably, galactically difficult that people immediately go, ‘I don't want to do it.’ And there is light at the end of the tunnel, Trygve said. He described working tangentially in this field, and asking people: do you have an established process?

‘Oh yeah, of course we do.’

‘Great. Can you tell me what it is?’

‘Yeah. Oh, yeah. Absolutely.’

‘Okay, great. Do you have it written down?’

And then you hear crickets (no response).

Trygve said that doing the basics, even within a department, can be challenging, then the challenge gets even exponentially harder because somebody says, ‘okay I'm going to sit down and I'm going to write our processes out, then I'm going to give it to Dave, and Dave's going to look at it and go, ‘I don't do that at all, that's completely wrong,’ and then you're off to the races, he said.

What are some ways that companies can really [use documentation to get] aligned just within their own departments? Because more than likely, everybody's doing their own thing.

That's a great point. And that does happen a lot when everyone's doing their own thing. I think coming together to talk about what you're doing, what's working, and what's not working can help you choose which things are working [to document]. A lot of times, there is data that supports [choosing] the tactics or parts of the process that aren't working, [identifying] what your top rep is doing, and [asking] whether we can use that process. How is that different? It's really the discovery process for your processes, [to find out] what everyone should be doing.

It is very difficult, as you mentioned.

Trygve talked about how everybody needs to do it because if you all are rowing the boat [in different directions], then that's the first step to messiness. Understanding that we all need to be doing it a certain way. And if we're going to change that process, great. But let's have a universal adoption. If not, then the issue is not with vendors or revenue because all of this is leading to giving somebody a really good [customer] experience. And if we don't have that down, then what do we really do? What do we really have? 

Dave agreed and said, as we're talking, it occurred to him that the whole idea of aligning all the things that generate or contribute to revenue in a business in RevOps means that HubSpot is uniquely positioned for that. He asked if there are common tools for getting started in HubSpot that we recommend through classes, so they can get those fixed or figured out first.

I think that's going to be a classic consulting answer of it depends on the company. We don't actually teach HubSpot in this bootcamp because there are other bootcamps for that purpose. But one of the things I think we discuss, or at least we should, I might have to add it in, is about a data dictionary. So at least the teams agree [terms like] what is a lead? That's a good place to start because that is also something that is input into the system, as well as what people have to think about.

What was your first exposure to revenue operations? What drew it to you and said, "Hey, I want to build this out"?

That's a great question. When I was pivoting my career into marketing and business, I got a job with Nicole Pereira at her previous HubSpot agency. I started as one of the first employees, mostly doing marketing and marketing tech work at the beginning. And it was originally branded or positioned as a Martech agency. That was the closest common word to describe what we did at that time. But we started seeing the term RevOps (revenue operations) in 2019 and 2020. It seemed to more accurately explain what we did to help not just marketing teams, but also sales,  customer success, customer service, and all related teams. It wasn't just marketing.

So, that RevOps term seemed more accurate to describe what we were helping clients with. And I started researching it more because the information online about RevOps was contradictory... which it still is today. There was no consistency in how RevOps was defined. Software companies were creating content to make RevOps sound like it is all about software, so they could sell their software. Or the sales-related people were louder than the rest, trying to make sales ops the main part of RevOps to help themselves more.

I thought, what if I find people in different areas of RevOps, from different locations, different companies, and with different backgrounds, and ask them the same set of questions, then compare and contrast the answers to try to make sense of RevOps?  I also thought that sounded like it could be a book, that kind of research. And writing a book was also another life goal of mine. So I did that research back in 2020; it seems like forever ago. And I used that book research to help shape the RevOps bootcamp.

I published most of that research on my blog over the past year, but hopefully 2026 is the year it all gets compiled into a book. You wouldn't think ‘what is RevOps?’ would still be a question 5 years later, but it is (fortunately for me, but unfortunately for the profession). And I think we'll talk about those misconceptions later on.

Trygve talked about how Charles Dickens, in A Christmas Carol, says that the word ‘enough’ is the most enigmatic in the English language because it means different things to different people. But as everybody's working on trying to grow their money, everybody's coming at it from their own way. It all means something different to them. And so it's not necessarily surprising that everybody has a different concept of what RevOps is, what it should be, and how to do it effectively, he said.

How did you get asked to do the RevOps bootcamp class?

I had previously volunteered to be a producer for one of the sales bootcamps. And then I saw a call or request from HubSpot for someone to make new classes, one of which was RevOps. And I'm like, ‘hey, I have all this RevOps research. Why don't I use it and make a class?’ I was interested in making classes at that point, which is why I was working as a producer. I had developed a comprehensive employee onboarding program for the agency, which piqued my interest in instructional design, training, and creating classes. It all fell together about a couple of years ago.

Trygve said he got asked to do it, probably bribed with a breakfast sandwich from Dan Tyre… for those who haven’t yet watched the Dan Tyre episode, Dan was famous for saying, "If you do something for me, I'll give you a breakfast sandwich." And then it became a thing. And now it's in the HubSpot community, especially. It's like a John Wick currency that people say, "Hey, if you do something for me, I'll send you a breakfast sandwich," Trygve said.

I asked Trygve and Dave about when, where, or how they first heard about RevOps.

Dave said it was probably around the same time I did, right around 2019-2020, when they started talking about how all of these things needed to work together. It was called revenue operations then, before it got even shorter, and their internal teams were like, "Ooh, we don't want to get into operations." So that was the scary part, because they like being tactical, connecting, helping figure out things, and delivering, but not necessarily doing the deep work or the naval gazing,  which leads to all the things that go into RevOps. Dave said it was nebulous and really interesting to watch it continue to grow. He was excited to see the bootcamp start, because it seemed like we were finally going to get some structure around this from the teams that really know what they're doing. 

Trygve said his story is about the same.  He heard the concept like it was an engineering term, understanding all the words in the sequence, just not the order in which they were used.  He took the RevOps bootcamp to audit it. "I think I treated it like a party school. So I listened intently, and I don't know that I put in all the work or did the workbook, which is funny because I tell people to do that all the time," he said. He remembers another instructor (Connor) had a Lego AT-AT next to his desk, which Tryvve liked. He thinks it's so important, and he's glad we're taking the time to talk about it because he sees this all the time. As the tail-end vendor or the tail-end company that's coming in, people are almost always universally mad. ‘Oh, we're not making enough money. We just need more. The last guy screwed it up. The last guy didn't do this. The last guy didn't do that. Can you guys do it differently?’ And sometimes that's true, but a lot of times, if there aren't established universal processes driving revenue, you're nowhere. It's just chaos. So, you can't predict anything or forecast anything, Trygve said.

Trygve also talked about a reality show about repairing bars and basic bar-making. Bars are more of a revenue driver, and the host says that service-based businesses don't actually have a product. What they do have is purview over their people, their systems, and their standards. And those three things need to work together in order to create an experience in the customer's mind. And that experience in the customer's mind, which you really have provenance over, that's your actual product. And the only way you can control that is by universal adoption of the right kind of people, the right kind of systems, and the right kind of standards. And so when he read that, it lined up with that concept of RevOps, Trygve said.

What's the endpoint to it? If a company really does work on their revenue operations standards, what can they hope to get from it, and what's the outcome that you see a lot of companies do this? What do they realize?

I think one outcome could be better company communication, which would lead to a better culture. This is one outcome that's not often discussed. With more communication, you get greater transparency and visibility when you have a strong RevOps team. It's often described as solving the problem of silos, as we talked about earlier. Silos are when one department is not talking to another department. There's no awareness or insight about what other people are doing. So having a team like RevOps as the connector or the glue holding the teams together, someone that spans more of the business than one department, is helpful because that usual/common lack of communication, the lack of transparency and visibility that leads to people recreating the wheel, redoing projects other people in the company have already done and didn't know they were done, spending time solving problems that have already been solved but you didn't know were solved, or not realizing the full scope or consequences of decisions that could hurt other teams.

And all of that also creates a bad customer experience, because all those disconnected teams we talked about earlier are interacting with customers.

But I think this communication skill is probably one of the most important for RevOps people, helping the business and translating across different departments. And helping people get alignment, which is also getting along, making it a better place to work, and making people more successful in their jobs. For example, [RevOps] is making quotas and forecasts more accurate so people can actually meet them. And that makes people happier in their jobs and makes it a better place to work, for example.

I asked to hear from Trygve and Dave on this question.

Trygve said that we're all knowledgeable about the flywheel idea: if you put the customer in the middle and all your systems work correctly, it spins faster.

He thinks it's a little bit more basic than that. If you think about the concept of what McDonald's is, it's the same experience no matter where you go. It's pretty much the same food. And it's wildly successful. You can comment on whether it's healthy, but I think you have to respect the system and the success it brings.  And the system is built on delivering the same customer experience every single time. And that can be replicated, learned, and adapted by many businesses. It's often hard because you have to do the deep naval gazing. You have to figure out where we are falling down. What could we do better? You have to put the defensiveness aside. And you have to create a swear jar anytime you say, ‘this is how we've always done it,’ you have to put five bucks in the jar, Trygve said.

Dave agreed and said part of the structure of RevOps and the idea of how you put this together is that it's really about forging the connections between all of the teams so that everyone is pulling in the same direction. 

Is there an ideal structure for a team that's trying to enact RevOps or get serious about RevOps? 

Trygve said he assumes the leaders of all the different revenue-generating or revenue-impacting groups are in it. But is there usually a good or best role to lead that? Is it best to have an outside organization or helper to go through these, or should the director of operations always handle this, or is there someone else?

For the question of who should lead RevOps or who RevOps should report to, many people say a CRO... but that's only if the CRO is actually knowledgeable and paying attention to all the revenue teams. Not a CRO who's only focused on sales. That is a common issue in many companies.

Some people like RevOps to report to the CEO or COO because that's more impartial.

As far as team structure, I've seen two common ways. One way is to combine the marketing operations, sales operations, and customer success operations teams into a single unified team. Having those three types of roles can be a good way to start RevOps, because that's the way a lot of ops are traditionally set up. So that helps to bring them all together into one team.

And then you might want to upskill and cross-skill each RevOps person, structuring roles and responsibilities such as insights, with the role spanning across sales, marketing, and customer success. And maybe another person is working on better reporting across sales, marketing, and customer success. So it's more of a horizontal span.

Trygve asked about what to do if they don't have a CRO, he hears that it is a sticking point sometimes to starting RevOps, but it's not the title that is important. Everyone's got to start somewhere.

What are some small things that leaders can take tomorrow to dip their toe in aligning their teams better?

I'm going to bring it back to process documentation, but I know people get scared of it. You don't have to do it all at once. Maybe start with one [process]. Maybe there's an issue you're working on right now that's super relevant. That might be a good place to start.

I know it's difficult because it's not like a shiny new tool that promises to solve all the problems with no work involved. It takes effort and maintenance, but documenting one process can be helpful just to start conversations among all these teams and get people talking about what's working and what's not. Identifying those friction points that we talk about in the bootcamp class.

And again, documentation is not super exciting. There's no marketing team trying to sell documentation as the next big shiny thing. No one’s hyping it up with a million-dollar marketing budget like a software company does [with their products], but documentation is a foundation to what we talked about earlier, about better culture, visibility, transparency, learning, training, and improvement, all those things that RevOps helps with.

What are some misconceptions that people have about revenue operations?

Trygve said that one of them is probably that people think, "Oh, process documentation is like pulling teeth." 

I'm not sure that's a misconception because it can indeed be like pulling teeth to get people involved. I think the most common misconception is that RevOps people are just software admins or tool-and-technology people. That it's not strategic or they’re not leaders. So, in my book research, this was a common theme in answers about problems in RevOps: it wasn't seen as strategic; it's only seen as hands-on tactical support or a cleanup crew.

I try to help solve this in the RevOps bootcamp, where we cover frameworks, project management, goal setting, prioritization, overcoming objections, and the big-picture factors that can lead to success. Topics that aren't taught much and aren't put into place at many companies. Because, as we mentioned earlier, RevOps people are hit with a barrage of requests from all these different departments, of things they want fixed and new ideas, right when they start their jobs. But these human-centered types of skills, like communication, which documentation falls under, can be harder to find information about and harder to learn about, compared with software skills. That could be another reason for the misconception. But I'm trying to help solve that problem.

What misconception have you seen, Trygve?

Trygve said, if the last 35 minutes have taught us anything, it's that there's no one way to do it, but at the end of the day, the ice cream you get for going to the dentist is that your job's going to be easier. And the customers will be happy. What do you do with that? And how can you guarantee that? He said if your process is the absolute best it possibly could be, you should feel comfortable in that and not just say ‘that's how we do it.’ There are always better, newer ways, and any good process should be able to be examined and analyzed in different ways to figure out how we do things differently. As Trygve has led the sales process at Bizzyweb for 10 years, he's taken a certain amount of pride in it. But he's also always said to the team that if there are other ways we can do things, he absolutely wants to hear them, because the goal is not to do it his way. The goal is the bottom-line revenue.

Dave agreed and said another misconception is that RevOps can be a little daunting to think about. People sometimes undercomplicate it, but a lot more often overcomplicate it, where they say ‘we need to do all of these things’ and look too far ahead in the project or in the idea of fixing it. And they say, "Okay, there's a chasm here because we don't have these four things figured out, and we need to have all of that fixed by next quarter.” No, you do need to start moving the needle, but the point of RevOps is improvement. Especially for smaller teams, you just have to pick something and start moving it forward.

Trygve also mentioned that some roles are not customer-facing; that is a misconception. In 2026, that is just not true. Everyone is customer-facing at some point. If you're the guy driving the truck, you're the one who's seeing the customer. If you're the one billing the customer, how you choose how you interact with them is important. The customer calls in, complaining. How you make them feel, that's important. It's not just sales. It's not just marketing. Even if you're somebody building a product on a bench grinder somewhere, putting parts together, if you're not doing your job right, then everybody else’s job becomes harder. So this idea that I don't talk to the customers on a daily basis, so that shouldn't apply to me, that's not true anymore. Really successful businesses understand that everybody has a role to play and a job to deliver an experience.

Where do you see RevOps headed in 2026? 

I've seen a hopeful trend of more education being available and more of it being easily discoverable for operations people. There are some certifications either in progress or recently released for revenue operations, and hopefully, more university-level education is coming soon. I just finished my master's degree in instructional design to have more credentials to help create operations topics at a university level. Hopefully. That's the goal. 2026 might be a little soon for that one, but there are other certifications people can pursue in the meantime.

My Substack newsletter

Trygve said that I have a popular Substack that he follows on a regular basis, and joked that one of the reasons why I was invited to the podcast is so that he could make the list for a third time (as I'm doing my research to prep for the podcast, and listening to the podcast and adding it to newsletter for that week). 

Every week I go through my email inbox, where I sign up for way too many email newsletters, and I go through all my saved posts on LinkedIn and I pick out the most interesting things. There isn't really a theme other than operations, which is pretty much everything, or education. There are links to what people are talking about, writing about, and doing podcasts on across a range of topics related to business, leadership, operations, education, training, and learning. I send that out every week, post it on LinkedIn, and call out some of the people in the newsletter because I think it's helpful to share learnings. It doesn't have to be my learnings or my content specifically. Just giving people amplification, I think, is helpful.

Trygve said he finds it to be endlessly helpful, especially when trying to educate himself on LinkedIn, where it's ard to keep track of posts you want to learn from and spend a bit more time reading. So having it all in in an old-fashioned email that you can click on is so unbelievably helpful and supportive, to cut through the noise of content that gets put out on a regular basis. On behalf of your readers, I want to say thank you.

 I said the algorithm changes all the time. So you can't really depend on that to serve you.

Trygve asked Dave about what we learned here today, other than that we need to be writing more stuff down?

Dave said that RevOps is one of those things everybody talks about as a buzzword, but there are tactics and a real process to it. And you can't say that you're working on RevOps unless you're actually paying attention to the process. And I think the key thing where most people get stuck is documentation, as Jen said.

So, everyone who's embarking on this method … just make sure you document your processes and get started. You do need to improve these things to grow your business and scale. And it's not witchcraft. It's not crazy, but it does involve some work. And so just start digging in, and it gets better the more you do it.

Additional questions from our preparation

How does RevOps impact the customer journey in ways most leaders don’t expect?

This is a helpful reminder for any revenue team that the leads, prospects, and customers are people, not just companies or numbered, faceless accounts. Since RevOps spans the entire customer journey and customer experience, they are in a crucial position to remind other teams and themselves of the human aspects of marketing, sales, and customer success.
 

How do you build buy-in internally, especially when teams are used to working in silos?

• • Putting yourself in that person’s shoes and thinking about: What's in it for them? Tailoring communication to what that person cares about
  • Explaining the benefits of your change, you prroject, to them specifically
  • Realizing people are different, not everyone is curious like ops people tend to be (ops people often want to know and see how everything works and all the puzzle pieces that fit together in a business, many other roles are content to focus only on their role, one piece of the puzzle)
  • Not everyone likes learning new software every day, as many ops people do. Some people get super annoyed when they have to learn a new tool, so it’s important to remember that not everyone is you, not everyone is me, when you're trying to get people to agree on, adopt, and change their behavior. Change management is one of those skills not taught or talked about often enough.
  • One more point about buy-in is about many people may not know what good looks like, they don't know there is a better way to work, since most companies are not doing well in transparency, communication, documentation, all those topics that give context to people's jobs and help them see the meaning and purpose of how their work contributes to the bigger goals of the business

Thank you, Trygve and Dave!