<img src="https://ws.zoominfo.com/pixel/Nfk5wflCTIIE2iSoYxah" width="1" height="1" style="display: none;">

Why You Don’t Need Technology to Be Successful at RevOps

by Drew Davidoff | Aug 31, 2023 9:30:00 AM

 

Social Templates - Blog (1)The other day, I was having a pleasant discussion about RevOps with someone who used to sell RevOps solutions for a living. He asked me for my definition of RevOps, so I threw out something like, “It orchestrates go-to-market vectors to achieve strategic objectives”  I asked him for his definition—and it was very much centered around managing technology. 

I threw down the metaphorical gauntlet and said that you don’t need digital technology for RevOps. 

A spirited debate ensued. (Yeah, I’m fun at parties.)

Now, I’m not saying this person’s definition was wrong, per se. I’m just saying that the focus was in the wrong place. RevOps existed before technology and can still exist without it.

Obviously, as Lift’s director of product and development, I’m not against technology. In fact, I’m all in—as long as the tech facilitates your goals instead of working against them. RevOps’ “job to be done” is to enable execution to achieve transformational strategic goals. 

And I believe that thinking of RevOps purely in terms of technology can actually hobble companies.  

Here’s an example of why:

Companies have an average of 89 apps in their tech stack, a staggering increase of 24% since 2016.

Yes, you read that right. That means half have more than 89 apps in their tech stack. 

That’s a staggering number with room for quite a few inferences.

That stat indicates to me that most tech stacks are “Frankensteined” together. No one’s thinking about the jobs to be done, let alone checking whether their existing tech could facilitate some of those jobs. 

Many people think that more technology equals more RevOps success. That’s simply untrue.

Why People Equate RevOps with Tech

Unlike Sales Ops, Marketing Ops, and Go-to-Market (GTM), RevOps was “created” and popularized after the advent of the digital age. While there’s definitely an argument that tech facilitated the creation of RevOps, as well as making it easier, you still don’t need tech to run a RevOps program. People used to do it just fine 40 years ago, using a Rolodex and a file cabinet. 

But that aside, I think the biggest reason for the conflation of RevOps and technology is because RevOps is an efficiency and optimization discipline.

There’s a general misconception that technology equals efficiency. If a RevOps department wants to make your GTM process more efficient, they often implement technology. 

There are two ways I think that goes awry:

  • Efficiency is great, but it’s the wrong thing to prioritize. Effectiveness should always trump efficiency—and they aren’t the same thing.
  • If you haven’t optimized your business processes, the implementation of technology will magnify any issues. The result? Chaos.

To wit: 89 apps in the average tech stack. 

While I absolutely believe in the premise of this piece—that you don’t need technology for RevOps—the reality is that almost every company is going to use tech. 

So, what advice do I have to avoid being one of the companies using way, way too many apps in their tech stack?

Here are my 5 tips to help your tech help you:

1. Start with the process - Before you buy one more piece of tech, you must deeply understand your problem, your business need, and your processes. Chances are, your processes are what’s actually off. 

At Lift, during the sales process, we always do a deep dive into process to ensure we deeply understand it. We’re driven by the Lift prime directive: The business process MUST drive the technology, not vice versa.

2. Determine whether tech is one of your GTM vectors - By that, I mean the purpose of RevOps is maximizing the potential of go-to-market vectors. If technology is not an integral part of your processes, it’s not one of your vectors. And if it’s creating drag, then it’s a detractor vector. Be very clear about what part technology plays in your processes. 

3. Determine technology’s “job to be done” - In terms of the Three Performance Zones, RevOps exists in the enablement zone, translating transformation to execution. That means RevOps’ job to be done—aka, the job you’re hiring it to do—is enabling execution so transformational strategic goals can be achieved. Tech can be a part of that. That said, technology can help with jobs to be done on the execution side or in the transformation zone.

4. Everyone impacted by the technology should be involved in the selection process - This is the key to success. Almost inevitably, a combination of people own different pieces of the process you’re trying to replicate. Without their input, it’s likely you’ll be missing something vital. 

For example, every Rev ops team needs an IT expert, but they shouldn't be buying technology they’ll never use without input from the process owners. IT managers understand the tech, but they don't know enough about how it's used by the end users. 

5. Don’t build stone ships - Don’t over- or under-buy technology or go in thinking you know what you need (at least, not without breaking down the process). If you do, you’ll be asking for a stone ship—something counterproductive, unwieldy, and which will sink immediately. Once you know the job to be done, figure out what tech will facilitate that and purchase appropriately.

In fact, I wrote an entire blog on this topic: 7 Questions You Need to Answer Before Buying Technology

If you’re one of the companies with 89 apps in your tech stack—or even if you have fewer but more than you truly need, it’s time to reassess. Outline your business processes and perfect them on paper first. Then, make sure you’re focusing on the jobs that need to be done.

It’s not a fast process, but I guarantee it will help you rein in the chaos that’s probably swirling around you as tech magnifies the flaws in your processes. And if you want to chat about how to do it, drop me a line. There’s nothing I love more than geeking out about RevOps and technology.

New Call-to-action