RevOps has become one of those buzzwords that’s tossed around at SaaS companies like a foam football. It’s right up there with “growth” and “revenue-centric.”
But what does it actually mean?
On an episode of Demand Gen Chat, Brad Smith (of Sonar and WizOps fame) explains what it isn’t.
It’s not your salesforce admin. It’s not your systems administrator. And most importantly, it’s not a help desk.
“RevOps is the support of your go-to-market teams,” Brad said.
While it includes managing the tech stack that powers go-to-market teams, it’s more than just a systems role.
RevOps practitioners identify the operational gaps that stand in the way of revenue and work to eliminate them through process, technology, and enablement.
Because RevOps is a relatively new function, there isn’t exactly a playbook on how to build out a RevOps team.
Most companies have a single person tasked with RevOps, so their time and resources are spread thin.
This scenario was the case for a long time for us. Our Head of RevOps, Scott Haney, or “Scottbot” to those of us at Chili Piper who rely on him for everything shy of personal life coaching, was a one-person team for a long time.
We’ve learned a lot from Scott’s experience and from friends like Brad at Sonar.
The following is some RevOps advice we’re qualified to give because, well, we’ve been there.
One of the easiest ways to get time back in your day as a RevOps practitioner is to implement a proper intake system. This doesn’t have to be anything fancy. It could be as simple as a Google form.
It’s easy to turn into a McDonald’s drive-thru using Slack as your modus operandi. Implementing an intake system forces people to stop and think about their requests. It also helps you prioritize asks and politely push back when there’s a better way to do something.
Also, let’s face it, some asks are a heavy-lift with minimal business impact. The great thing about being a RevOps practitioner is the ability to decide which tasks will drive the business forward and which ones can wait.
If you are looking for a more sophisticated intake system, we recommend Asana forms or JIRA service management.
There’s a lot of debate out there about how much of a RevOps practitioner’s time should be spent on proactive vs. reactive work. In fact, it’s one of the biggest challenges RevOps practitioners face, according to research conducted by Sonar.
The reality of working for a growth stage company is that most of your time will be spent on reactive work.
But there’s a ton of value in taking a moment to pause and write things down. As the sole RevOps person, it’s easy to become the source of truth for all things operational in the business. In doing so, you become a barrier to getting things done. If you go on vacation, the world falls apart.
We recently started using Guru, a tool that helps you organize and update company information, to help transfer some of Scottbot’s brain into an internal knowledge base for the rest of the hive, and it’s going well.
While there’s no one-size-fits all answer for when to build a RevOps team, Sonar’s Brad has noticed most companies look to add the function somewhere around employee number 50.
This might be too late.
More often than not, the decision to hire a RevOps resource happens because something has broken, and the revenue teams need it fixed in order to scale their respective operations effectively.
If you’ve got a CRM, marketing automation platform, sales engagement platform, etc. that all need to be talking to each other, chances are good you need a RevOps person who can ensure they’re integrated properly.
Beyond system orchestration, you need a RevOps person to advise on how to best scale people and processes to meet a growing business’s needs.
Our advice? Hire that ops resource before you make your first big sales or marketing technology acquisition.
What do product and ops have in common?
Turns out, more than you think.
Product has been dealing with the McDonald’s conundrum for a long time. They’ve implemented some helpful processes to ensure they’re only building things that matter, instead of just churning out new features every time a single customer requests it.
According to Brad, the best thing you can do as a RevOps practitioner is to simply ask, “Why?”
Why do you need that? What is it that you’re trying to accomplish?
An intake process is the first step. The second is to dig in to better understand the subtext behind requests that come through.
More often than not, the solution to the problem lies outside of the specific request that’s being made. Or it already exists and the requester just doesn’t know about it.
Like this article? Follow our Demand Gen Chat podcast to listen to Brad’s full episode and to get more RevOps and demand-gen focused content.