At first, I was very excited to see a concept I thought may take several years to enter mainstream business conversations appear to become commonplace.
LeanData and Sales Hacker released The State of Revenue Operation 2019, with 2,462 people participating in the survey.
Pardon this interruption for a brief rant: How does RevOps have a “State of …” report already, and where did 2,462 people come from to credibly complete a survey on a topic that was barely talked about just one year ago? Can anyone say “reaching the peak of the hype cycle?” Unfortunately, it likely still has more room to go before peak hype is reached.
Anyway, the report suggests that from 2018 to 2019 there were:
If this report is accurate, this means that 58% of companies either have or are actively building a revenue operations function. I see this data point and must admit that I am highly, highly skeptical. We’ve been talking about and moving our company towards revenue operations for more than two years. I don’t know what the demographics of the report’s participants are (I do have a hunch), but unless I’ve been spending all my time in a metaphorical Siberia, there’s simply no way this number is accurate for the business world at large. I’d be willing to make a big bet that the real number is comfortably under 10% and if you caught me on a good day I might be willing to put the over/under at 5%.
The more I read the content coming from martech companies about revenue operations…
Pardon this interruption for a brief rant: And would you believe it, just about all of the martech companies creating content focused on RevOps have a product that promises to make RevOps easy?
…the more I can’t help but think of a blog post that HubSpot’s CMO, Kipp Bodnar, wrote in 2017, Marketers: This Is Why We Can’t Have Nice Things.
You may be thinking, “Doug, what’s got you in such a salty mood? Who cares if people are hyping RevOps? After all, it might be good. You’re a big fan of RevOps, and the more people know about it (even if it’s a little hyped), the better, right?”
Here’s why I’m salty. Hype is dangerous - really dangerous. It’s why everyone should be sure they have a knowledgeable, credible skeptic in their corner. Hype creates fear - the fear of missing out. It lures many, many unsuspecting victims to make a bad bet. They (greatly) underestimate what’s required for success, thereby underinvesting resources in the effort, and as a result, overestimate the impact. It ends up costing them a lot and builds institutional tech debt, making future efforts harder.
And this is precisely what I see, nearly every day. For example, I often see some RevOps evangelist respond to someone’s problem with something like, “Yeah, that’s why you need a RevOps function (or that’s why you need to move that to RevOps). People with RevOps see greater blah, blah, blah..” They make it sound like all you have to do is announce “Ladies and gentlemen, let me introduce you to our RevOps department,” and profitable revenue growth follows and everyone gets an extra day off each week.
Before we get too far ahead of ourselves and RevOps becomes just another buzzword fad left on the ash heap of magic pills and silver bullets that just make everything slower and harder, let me share where I see things going wrong, and more importantly what to do about it.
So, in no particular order, and with no promise I won’t be adding to this list in the (near) future, here’s where the RevOps movement is going off the rails:
Don’t get me started on how PLG (that’s product-led growth) is typically bad for buyers. The goal of PLG is to make the product “the salesperson.” Make the product really easy, give it some good sizzle, create a freemium option, and then peddle the problem that your “free” product solves. Be sure to throw in some buzz - a whole lot of buzz - get some PR going and focus on a tight market so that you can create an echo-chamber effect: everyone I know is talking about it, so everyone must be doing it, I better move quickly or I’ll fall behind. Hype cycles existed long before PLG, but PLG strategies have multiplied the cycles and aim to exploit them.
This is primarily how RevOps has amplified the conversation and movement for RevOps - don’t fall for it. RevOps HAS NOTHING TO DO WITH PRODUCTS. Note: this is not to say that managing products is not an important part of the RevOps function.
I’m constantly seeing RevOps used as the career path for a Salesforce (or similar) administrator. Far too often, it’s implemented almost as the equivalent of an IT department for sales and marketing. I’m not saying that a tech admin can’t lead RevOps, but the reason they can is not based on their technical acumen.
Make no mistake, enabling the tech stack is a core part of the RevOps function -- but it is only a part of the process. For far too many companies, the “tech stack tail” is wagging the “business performance dog.” A strong RevOps team prevents that from happening.
The purpose of the function is to solve for revenue, not for operations. Enough said.
This is quickly becoming the most common issue I’ve seen recently. As more people are advocating RevOps, they’re struggling to define its role, impact, and justification. Rather than doing the hard work of defining the need, they look at all the areas that need improvement or additional focus and say, “That’s why you need RevOps.”
RevOps is quickly becoming a hornet’s nest of fluff, filled with words like alignment, data-driven, and enablement that sound good but don’t mean anything.
A close cousin to the “utility drawer” is the magic elixir. RevOps is not an easy fix and it shouldn’t be used as a reaction to the symptoms. Simply turning over the management of your marketing automation platform, CRM, territory management, etc. to a “dedicated revenue operations function” isn’t going to solve or improve anything. The truth no one wants to share is that if you do that, and don’t do it right, it’s far more likely that it will make things worse.
There’s nothing magical about revenue operations. The magic exists in the structure, strategy, and disciplines that RevOps can enable.
There are only two activities that can strengthen your flywheel momentum. They are to increase force or reduce friction. Increasing force (doing more) quickly hits points of diminishing returns. When the focus is on “more,” costs go up, as does the complexity. When you’re focused on force, the increased friction eliminates much of the value you seek to create. (I wrote about effectively balancing force -- doing more -- with reducing friction in a recent blog post, Sisyphus vs. The Flywheel: 5 Tips to Eliminate Friction.)
The danger of the approach I’m seeing is that revenue operations are being implemented through the prism of “doing one more thing.” RevOps should be focused on reducing friction (specifically negative friction), but if it’s not understood and implemented correctly it will create friction rather than eliminate it.
The goal of reducing friction is to increase the velocity of your revenue teams (marketing, sales, customer success, etc.) by making their experience as effortless as possible. To do that effectively, you must understand what we’ve labeled The Inverse Friction Principle. This states the ease/effortlessness of a user's experience in doing something has an inverse relationship to the complexity involved in designing the system that makes the experience so easy/effortless.
Getting RevOps right can be one of the most powerful things a company can do to accelerate revenue & profitability. Our research supports the finding that most companies are paying a 15% - 50% friction tax; RevOps is crucial to dramatically reducing that, so you can get more for less. The potential gains in productivity & impact are huge, and the ROI is in the multiple millions of dollars. (We’ve built a calculator so you can determine the economic impact/ROI of RevOps are your business here).
Getting it right means understanding and accepting these five factors:
RevOps is far more than putting an admin on a function or simply coordinating activities. It’s a commitment to change the way you do business. Please (please, please, please) realize that the RevOps function isn’t what makes the difference in business performance. How you change the way you do business is what creates improvement.
This type of decision is the ultimate strategic decision. As I shared in Strategy Kills, a strong strategy has three elements:
For this reason, implementing a RevOps function requires a commitment from the senior team. The fastest way to destroy the investment and make things worse occurs when RevOps pushes another group (typically sales) out of the comfort zone, the group resists, and the senior exec for the group uses their authority to override RevOps.
I often see questions about who RevOps should report to. I firmly believe that if RevOps reports to the head of sales, then you’re not implementing RevOps, you're implementing sales operations. The same goes for marketing.
For RevOps to fully unlock the latent potential and power within an organization, it must not be subordinated to sales or marketing. Of course, neither sales nor marketing should be subordinate RevOps.
The process should be collaborative with its fair share of constructive conflict. A strong RevOps leader has a different mindset than the leader of sales, marketing, or customer success.
The reason it shouldn’t be subordinate to another discipline is that friction is effectively eliminated by successfully managing a series of trade-offs where there is no right or wrong way. The job is to manage & mitigate complexity.
Here’s my promise about a successful RevOps implementation (and the primary reason why one fails). Anything RevOps touches will be made more difficult in the short term. By the time a company needs a RevOps function, it means that there’s a critical mass of complexity, conflict, and friction. What’s more, revenue acquisition operates in what’s often referred to as a VUCA environment (volatile, uncertain, complex, ambitious) so there are rarely easy answers. The decisions and actions RevOps take impact all facets of the customer acquisition and success process. The reward is effortless execution (or at least something close to that), but as the saying goes: “If it were easy everybody would already be doing it.”
The opportunity for the big payoff that RevOps can provide exists because of the difficulty that’s present. So if you subordinate the RevOps role you’ll end up experiencing most of the pain with only some (or none) of the reward.
If I were to define RevOps in the simplest manner possible it would be the discipline responsible for designing and optimizing the dynamic and repeatable system that enables a business to acquire and retain customers profitably.
This means that RevOps must be viewed through the lens of systems design. The sales, marketing, and success teams own what gets done (the more side of the equation) and RevOps owns how it gets done (the reduce friction side). This means the RevOps lead must understand the entire process at a deep level and must mix that knowledge with the disciplines of change management, statistics, technology, and constraints.
Yes, it’s a BIG job and that’s why it needs to be a senior position, but what would you expect from a role that has the potential to increase the value created by your revenue teams by 20-50%?
This last point is what I like to call the RevOps trap. Successful RevOps teams must be clear about two key elements:
When you add RevOps you’ll gain more data points, and just about every data point will have room for improvement. A key element of realizing the impacts that I’ve written about here is remembering that just because something can be improved doesn’t mean it should be improved. (This, in many ways, is the #1 strategic trade-off that business leaders must make every day). Your business has limited resources and you maximize your success by how well you allocate those resources towards your key objectives. RevOps should be instrumental in making this a reality.
There’s only one reason to implement RevOps in your organization and that’s to reduce negative friction. Anything that interferes with that is a mistake.