WHAT IN THE ACTUAL F*$% IS REVOPS?
We’ve seen a number of posts on LinkedIn lately about the growth in RevOps positions. According to one post, it is the fastest growing position over the last five years (take this for what it's worth because we are doing the classic Millennial thing by reading one headline and then quoting it as fact). Regardless of the exact numbers, there is significant demand for RevOps. However, now comes the fun part, is there supply to fulfill this demand?
No… at least not enough people who actually know WTF RevOps is.
To be clear, we are not dissing (wow, can you tell I grew up in the 90’s) other RevOps professionals. Instead, what has created this misalignment is companies don’t know what great RevOps looks like. So let’s break it down (another good 90’s reference):
What RevOps is not:
The SFDC or CRM Admin aka “I know your role says ‘operations’ but can you spend 90% of your time doing CRM or other tool administration?”
The SalesOps 2.0 aka “please focus all of your time on the Sales team and occasionally help out with the BDR team”
The Data Analyst aka “hey can you build another SFDC report for me”
What RevOps is:
RevOps is across the ENTIRE customer journey which means RevOps it is not just Sales, but it includes Product, Marketing, Business Development, Sales, PS, & CS while in alignment with Finance. This means, when RevOps is done well, it prioritizes the departments or initiatives in the business that have the biggest impact to the customer journey.
We believe there are five work streams across the customer journey (and the order is important):
Planning/Strategy - A clearly documented (ie written down) GTM strategy so that even the 22 year old BDR, who only cares about how many Keystone 30 racks their commission checks will buy, clearly understands it
Process - Standardized activities (ie “how to have a discovery call” or “how to create an Account or Opportunity in your CRM”) from your GTM strategy so that you can hire and scale across the entire GTM team, even the Keystone-loving BDRs
Tools - All of the systems that touch the customer journey set up and optimized based on your Strategy and Process (we have seen lots of companies who intentionally do things less efficiently because that is how their systems are set up)
Data - Data is an output of the tools and should:
Only measure what a decision can be made around (500,000 SFDC dashboards does not make you data driven)
Fly at the right altitude (ie executive summaries for executives and per person reports for ICs)
Be presented in a way where the end user understands the insights from the data, and can make a decision (without having the RevOps team walk them through it)
Enablement - Data helps to highlight the challenges across the customer journey and should work to improve the following:
Skills - how the team gets better at their jobs (ie how to conduct a executive business review, how to leverage MEDDPICC, etc)
Tools - how to use the tools to be more efficient
Market - how to understand the industry, market, competitors, etc
Where should RevOps report?
Most companies believe it is the CRO because they both have “Revenue” in their titles, however, we fundamentally disagree. If RevOps is truly going to work across the entire customer journey, then in a perfect world, it needs to be Switzerland and would have a seat at the table (ie an executive). We recognize most companies are not perfect so they need to be agile and in these scenarios we recommend:
If not at a seat at the table, reporting to a COO
If not a COO, then a CRO (with the understanding that they need work with other departments that may not report up to the CRO)
If not a CRO, then whatever department has the best HHs
It’s exciting to see both the growth in the demand for RevOps as well as the number of talented RevOps professionals. However, with this growth, it is the responsibility of RevOps professionals to communicate WTF good RevOps is internally (please spend less time posting on LinkedIn and more time communicating to Joe in Customer Success) to drive greater alignment because it does everyone no good to continue having the “hey can you build another SFDC report for me” person.
