Peter McCoy, Co-founder at Baton, an automated solution to manage software implementation processes, talks about how he views RevOps, how it fits into the company and his journey from finance to software and the lessons learned from both worlds.
Pressed to describe RevOps using a metaphor, Peter McCoy, Co-founder at Baton, which manages software implementation processes, likens it to plumbing.
“You’ve got to move stuff from here to there,” he says. “What kind of system are you setting up? What are you moving and how do you want to move it? It’s basically just the movement of how can we create demand and can we turn demand into revenue? Then how does that revenue move through the organization?”
Peter thinks of RevOps through the lens of demand, revenue and customers and considers what that requires. It’s all about making things efficient internally and giving customers the best value (and experience) possible.
It’s an interesting take from a guy who started his career in finance and found his way to software.
“I’ve been an entrepreneur, investor and now an entrepreneur again,” he explains. “I started off in finance. I was with a hedge fund out of school for a couple of years.”
Then he founded a startup with a friend, and that journey had him evaluating and working through software, e-commerce, data and the mess of ‘back-in-the-day’ operations. Software implementations and similar projects would get booked, but issue after issue would arise and delivery would stall with the outcome being work that was always late and often poorly done.
“I kept seeing this problem that led me to Baton, which was on the revenue side,” he says. “Over and over, it was a poor process and no way to collaborate with the customer. I just kept hearing the same story over and over and over. Baton was really just a culmination of me trying to find a better way to scale this function of delivery or implementation.”
Through all of his experience, he feels that what serves him well is drilling down to a grain of truth (a bit like what RevOps does, actually). From that truth, assumptions can be made.
“Whenever you’re problem solving, which is 95% of the time at a start-up, something’s always on fire,” Peter says. “From the outside, everyone’s all smiles and handshakes. But probably behind me, there’s 10 things blowing up and I’ve got 10 Slacks about some customer that’s mad at us.”
He finds that starting with the grain of truth helps with problem solving and moving forward. Whether it’s about the product, customer, market or a process, this spec of truth allows for a framework to be built to test what else is true.
It’s almost worth a giggle when Peter says RevOps doesn’t exist at Baton. But it does, just not in name. This sounds familiar to us. We’re sure that very many companies out there have implemented practices that from our perspective would be titled “RevOps”.
“We think of it as sitting inside of both sales and customer success,” he says. “RevOps, for us, spans a very wide spectrum of everywhere the customer touches that we want to collect data or revenue from.”
Operations falls under what Baton calls the customer banner. They make sure great data is collected all the way across the customer journey so that the profiles of these individuals and their associated accounts are rich and usable by everyone in the company that’s in charge of converting them. Riley Bowden, Growth & Marketing at Baton, essentially owns the customer records to keep them centralized while he works with a range of teams. He’s pretty much RevOps in a nutshell.
Peter expects that area to grow by a couple of positions by the end of this year.
“What comes to mind with this function is what I call operational debt,” he explains. “If you’re not building a strong structural platform for the collection of this data, the movement, the interaction with these customers and just the interaction with that data, you’re going to have a frickin’ mess.”
His advice is to invest in RevOps early and to know customers well. That’s advice that can be used by anyone.
He called this opinion out as controversial, but he believes the formal origin of the RevOps function came from companies being overfunded and having inefficient sales processes that stagnated their growth while raising their costs. Sales people not hitting quota didn’t really matter to certain leaders who thought they could always raise the next round of funding by throwing more bodies or technologies at the problem.
“I think that also caused a lot of bad cultural citizens in the sales department,” he says. “They didn’t put anything good into Salesforce. They didn’t want to manage their outreach campaigns and they’re fighting with marketing.”
He thought a buffer was needed (spoiler, it’s RevOps) to go between the different functions and educate them showing that good data in means good data out. At the same time there were a lot of people in larger companies in fields like marketing, revenue enablement, sales, onboarding and so on. Someone needed to bring their work under one banner.
“I think some of the CEOs and CFOs started looking at what all these people are actually doing?” He says. “They wondered, can we house this in one department? And that was the start of RevOps. I started seeing these big, bloated organizations that had this need and I think it’s become much more valuable as the role matured.”
Now, he’s pleased that others are seeing the value RevOps provides. It’s much better than his statement that the original task of the role was “to fill in for lazy salespeople.”
Alright, alright, Peter doesn’t see RevOps as taking over the world. However, he does see it as the source of the customer journey.
“I think you’re going to see a lot of RevOps enablement, customer operations and a lot of these teams kind of morph into one more strategic customer team,” he says. “I think you’re going to start to see that as customer journey mapping. I think RevOps will start to own the plumbing and tools that connect the journey.”
He sees it as a strategy and operations group to improve outcomes that help other teams integrate into what exists.
“Investing early in RevOps and having someone that literally is thinking about the architecture of our data and not just our people updating Salesforce is a huge luxury,” he says.
Looking for more great content? Check out our blog and join the community.