Fireside Chat
//
June 13, 2022

Fireside Chat: Is RevOps the Steward of Data?

Fullcast

The Fullcast team

Is RevOps the Steward of Data?

Overview

Introductions

Tyler

Hello, everybody. Welcome to another episode of our Fullcast Fireside Chat. I'm your host, Tyler Simons. I head up customer success here at Fullcast, and we are a go-to-market planning and execution execution platform. Our goal today is to find out if Rev Ops really is the steward of data. I think we're going to get into some meaty data topics, which may be fun. May not be fun. I don't know. We've got Ryan Milligan here today and Liz Christo. Ryan, why don't you go ahead and give us a brief introduction?

How has data integration changed over the last ten years? (Ryan’s Perspective) [1:58]

Ryan

Great. Thanks for having me, everyone. My name is Ryan Milligan, senior director of Revenue Operations at QuotaPath. QuotaPath is a commission tracking software that allows Rev Ops and finance teams to build comp plans and share them with their sales teams and enable sales teams to actually forecast what they're going to earn and have more visibility into their commissions, which is great. I'm a bit of a data junkie myself, SQL writer, dashboard builder. So I'm excited about this topic for sure.

Tyler

And Liz.

How has data integration changed over the last ten years? (Liz’s Perspective) [3:42]

Liz

Absolutely. My name is Liz Christo. I'm a partner at Stage 2 Capital, where we invest in B2B software companies. Really from like the C to the A range. QuotaPath is in our portfolio. So when we were talking about doing this Fireside chat. I looked back at my history and thought, "Okay, you worked in sales operations for about one year, 15 years ago. So you are like the absolute expert." And then I thought, maybe there's somebody else to bring in who might have a more current view of the function. So I'm happy to speak to the high level and across our portfolio and Ryan very much lives in this day to day, which is awesome.

Tyler

Well, let's get started. Ryan, you and I were chatting before this call, and you're going to have very interesting context in terms of this first T up question, because you've had some different roles there. But how has data integration actually changed over our last, let's say ten years?

Ryan

So I think the biggest change has been how easy it is to connect all your data sources and pull your data into one place, but then also how disparate the sources of data have become. On the easy side, we were talking before, after undergrad, I went to work at wayfair.com, and I remember we had a 15 person at the time, now 50 or 60 person BI data architecture data processing team that wrote these crazy SQL scripts and had these dags with these FTP server uploads to pull all the different data together. Now you look at all of these ETL. This is pre a lot of the ETL players and a lot of pulling from sources.

So it's really easy to get how much has changed. It's really easy to get all of your data from all of your different sources into one place using the five trans or the various ETL tools in the space. With that easiness does come a broader set of sources of data. And those sources, especially in your sales tech stack—sales tech tools aren't necessarily known for their reporting. It's not a thing that I've ever seen them investing as much of their time in.

So what a lot of teams are doing is pulling from your email cadence platform for your CRM, from your product, from your demo booking tool. You have all these disparate sources of data. And the challenge is how do you pull those all into one place and then drive actual insights from all of those different sources of data?

Tyler

Interesting. Now we'll get into that, I think we're going to talk more about exactly how we're going to do that. But I would be interested to hear from Liz and what her perspective is on how things have changed and maybe even touch on—and this may be for later or not—but I think it would be interesting to just hear how that affects. Because you're the portfolio level. You're trying to think about metrics and KPIs, and there might be some difficulty and just trying to aggregate all that and measure that.

Liz

So I guess just trend wise, I think one of the core things I'm seeing, and I'm really intrigued to see what you both think is the shift actually away from the CRM as the system of record. So for a long time it was like how do I get all my stuff into either, like HubSpot or Salesforce and I think there's a number of reasons why and I can happily enumerate on those. But we are seeing a shift where everything's getting pulled somewhere else that's centralized and CRM is one data input. It's no longer like we're trying to retrofit everything into Salesforce, which I think is a real win to be clear.

That was really tough and really slow, but it is a really big shift, and I think it's only happening recently. Like in the last few years, I've really seen it take off. And I think in my mind there's a couple of different reasons why that's happening. And Ryan spoke to one of them already, which is just there is a lot more sales tech, so we have a lot more data and we're just creating a proliferation of data points.

The second thing I'm seeing is like product led growth and the rise of bottoms up and all of the requests for usage based data. And integrating product data with sales data has created yet another layer of both complexity and data points to deal with.

Then the third is I blame BCs like myself. We are creating much bigger asks for teams way earlier in the lifecycle of a company than I think we ever have in the past. Those three things together are creating this massive need and also repository of a lot of data way earlier in the lifecycle of a company.

Tyler

So I want to touch on the Salesforce thing. I'm so glad that you brought that up because a lot of people will still think this way and I do see it changing where everybody wants to put everything in Salesforce. There are some instances that I've seen where they build custom object upon custom object upon custom object to measure historical data of whatever it is. Not just thinking about opportunities.

So that's for one, and two, there's the product problem where everyone wants the product usage data and they think about Salesforce as the source of truth for that. They're going to put it into Salesforce and then run into so many problems with like, "Oh, now we've got all this product data being piped in so we can't touch our customer accounts and then you build inflexibility with making changes to Salesforce. So then the sales reps are dealing with this whole complex product and have problems and so on and so forth from there."

Where does RevOps fit into the data world/What role can they play to stand up a data practice and then manage that data ongoing? [6:42]

Tyler

So I'm curious to hear a little bit about where RevOps actually starts to fit into this whole data world and what role they can play to stand up a data practice and then manage that data ongoing.

Ryan

Yeah, I think it really depends on the stage of the company. I think that's the first caveat you're going to have. My personal experience coming into QuotaPath, Series A business. We were pulling all of our different data sources on CSVs from Salesforce, from Stripe, from our web application, and then running Vlookups and Google Sheets to build reports for the board. So we had no central data warehouse, we had no data visualization tool. And those were, as a SQL junkie, like priority number one for me. I care very deeply about data transparency. 

Liz

That's where also probably multi-hour minimum commitments to answer like simple questions. Right?

Ryan

Yeah, 100%. How many customers ran payouts in their 1st 90 days or something would take weeks to get together. Yeah, exactly.

Tyler

This is why people end up doing anecdotal stuff because it's too difficult. It's too much work. It's not too difficult, it's just so much work to do that you're just like, "I think 30% of our customers are doing this."

Ryan

Yeah, exactly. I think where RevOps plays a really big role is RevOps is typically the one owning the sales tech stack. So one of the big things you have in your sales tech stack is a desire to pull all the corresponding data about how things are going and when you've seen the proliferation of basically a lot of point solutions in your sales tech stack, they don't talk to each other really well from a data perspective.

So you're sending emails and enrolling people in these cadences with one tool and then they're booking a demo with another tool and then they're using your web application and then you have some customer health data in another tool. If those things aren't all talking together, there's a problem. RevOps is who stood all those up and so there's a natural linking into RevOps, kind of owning the data side of the data aggregation of those tools.

I think what I'm seeing a lot in the market is RevOps is now evolving from just Ops. Wrapped Sales Ops and Marketing Ops combined into this new term of RevOps to actually RevOps and analytics. And when I think about the future of my team, I actually think about the operators and the analytics people in two pillars of the team that I'm building over the next six to twelve months.

So one of the things that's been really interesting for me to watch is how do you shift that thinking within your organization where people who were in Sales Ops or Marketing Ops roles, who historically might not have been as analytically focused or quantitatively driven, who are real connect the pipes operators, are they growing into an analytical capacity or are you hiring other people in an analytics function and bringing them into your RevOps Department? So those two sides of the coin work side by side.

Liz

I'm going to add a third leg to your stool so it becomes a stool instead of a coin. But I do agree with the Ops and analytics and I think the third one is planning. I think more and more, RevOps is going to play a really critical role in forward-looking planning. I already see that happening in your business, like where you're connecting with finance on a very regular basis early in the life cycle of a company. Finance is taking a lead on building the multi year model. But very quickly removal is playing a really critical role in doing the bottoms up planning and actually being like the person who holds all the informing data to that plan.

Tyler

We have customers already in meetings, working with finance, discussing what next year is going to look like. It is a mutual role now that you sit down and figure that out. It's not just like finance handing over a number anymore and saying go hit this and figure it out. Yeah, I think RevOps and sales everyone's happy about that. We are at least starting to see that being brought earlier and earlier and it's bigger.

What does being analytical mean to you? [11:11]

Tyler

I want to ask a dumb, dumb question. In your world when you say analytics, what does that mean to you? We have everybody that's used to doing the traditional SalesOps role or the Marketing Ops role and you want to see them become more analytical. What does that mean to you? What's your goal for them?

Ryan

Yeah, a lot of it is data storytelling. Liz is on our board so we have a biweekly check in with our board where I put together my team, and put together 15-20 slides that tell the narrative of the business. That is, here are the targets that we set for Ops. We created demo occur, qualified in close one. Here's the ASP targets we had for those. Here are the conversion rates that we were looking at. Here's the mix of pipeline. Then here's marketing and marketing qualified leads. And here's product adoption. And all these different data .

Analytics to me is like, how do you tell the overarching story of the business? We hit our target and here's why. We missed our target and here's why. Here are the three drivers we need to change, the three things we tactically need to change in order to hit our target for next quarter. Here's the amount of volume we need to build from an outbound perspective, it's more data storytelling.

I think that a lot of times from what I've seen from former Ops roles or people in RevOps roles more traditionally, if they ask us, "Hey, can you go build a dashboard with X, Y, and Z?" More and more, you're seeing the need for RevOps to move from dashboard builders and pipe connectors to actual data storytellers who are giving the broad, both qualitative and quantitative view of the business to just decide what to do next and how to move forward.

Liz

I totally agree with that. The one other thing and I don't know if you think you're doing this, but I look at the role right now as answering the questions we're not asking. And I think often Rev Ops is closer to the data and therefore asks better questions and tries to serve up insights that no one was necessarily looking for. And I mean that in a good way. Not like you're answering extraneous questions. You're thinking two steps ahead of everyone else and saying like, "Hey, you're asking this question, but really like two levels down is this third problem and this is really what we need to be working on."

Ryan

And I think that's a really good point. I think one of the things that I've seen as I coach people in our org and other orgs that I mentor is a lot of the traditional path to RevOps has been either an individual rep who wants to move to a more operational side of the business or a Salesforce admin who wants to continue operationally. Those two backgrounds are not SQL writing, data analytics, storytelling backgrounds historically.

So what I think is really interesting from an evolution perspective is those people are going to be asked more and more, "Hey, how do you take all this data and actually analyze it and tell a story? Or do you bring people to support or what does that look like?" And I think more and more there's a mental bifurcation of Ops as pure Ops analytics as pure analytics, or whether one person serves both those functions and develops a secondary skill set, or you have two really different profiles in your Rev Ops team.

Liz

I'm also wondering if it's like a shift as you think about coaching those people up from like, order taking and, "Hey, I need X" to "Let me anticipate and think through what I would want to see," as you think about trying to teach that storytelling skill.

Ryan

Oh, definitely. Time and time again, I think SQL is one of the best things you can learn for your analytical career. It's a great way to get access to data really early, and being able to tell that story for sure is something that I care a lot about for sure.

How can those who are new to operations better prepare themselves for analytics? [15:07]

Tyler

One final touch here, because I think it'll be really helpful for people that are listening to this that are maybe just getting into the operations world. Are there some things that they should be doing to better prepare themselves for this? To be a better storyteller?

Liz

I think you heard it here first. SQL.

Tyler

SQL. I picked that one up. I guess that's what I have to go learn next. Okay.

Ryan

Yeah, I'm just a SQL fan. That's just what I talk about a lot. I think one of the big things that I was talking to somebody about last week was if you are not going to be the person who is driving all of the analytics, like building the dashboards and building the reporting or someone else in your org is doing that, you at least have to fundamentally understand your data architecture. You have to know, "Okay, here are the tables and how they're laid out. This is at the opportunity level. This is at the contact level." You need to know your data model and be able to draw it on a piece of paper.

This one account can lead to many contacts, and each opportunity has one primary contact. You need to really be able to understand at least your data model, so you can structure requests from an analytics perspective in a way that you can avoid those "gotchas" of duplicate data or double counting or what have you. So if you're not going to be the person running all of the analytics itself and building all of that reporting, it's really understanding how the data is structured and where the sources are coming from and what level of data you can pull from your different sources.

ETL tools make this super easy. Take your cadencing tool. You can pull in cadence level information. You can pull in contact level information. You can pull in company level information about responses to cadences or what have you. So it's really understanding the data levels and the model and then how all the systems are connecting together. What is the key that gets you from Salesforce to sales law that gets you from Salesforce to Chili Piper, how is that data actually being joined together is a really good thing to understand.

Where does someone start for getting control of all the data coming from different tools? [17:38]

Tyler

Super helpful. So let's get to the nitty gritty here. We talked about this. We got all these spreadsheets. We're trying to do Vlookups, we're trying to build all this stuff up, and then we've got an ETL tool that's pulling all of our data into this perfect data warehouse. But there's probably like an in between state, a starting state. I was wondering if you could just shed some light on where does someone start to move towards getting control of all of this data that's coming from your different tools and maybe some of the things that they should be thinking about when they're starting to stand this up.

Liz

I'm happy to start and share what I see as sort of the normal journey. And then maybe you can jump in with really what people should be thinking about probably sooner. So what I tend to see is what you described. It starts with a lot of spreadsheets. There's generally one or two people in the business who have the insight that Ryan was just describing of how the data actually works, how it connects and can be like the "putter togetherers". That is probably founder, someone in finance, maybe like that jack of all trades early hire. And they are bogged down in this whenever there is either a board meeting, a fundraising situation, or some massive data request. This can be like a multi day project. At some point that pain becomes too great.

Then at that point, what I usually see happen is either they start to outsource and think about fractional RevOps resources that they can bring in either as a consultant. Maybe it's just a Salesforce admin that frees them up. There's lots of different ways to think about how to break this role up, but you get something off your plate.

Generally that process of making your CRM more of your system of record, and I'm speaking broadly in general terms here. Obviously, depending on the go to market motion, this looks different. But there's usually some tool that becomes a system of record for a period of time. Then I would say there is a maturity level you hit. We can talk about what that tipping point really looks like, where you start to think more about a data warehouse and actually aggregating data in a different way and bringing on full time resources to own it. So I usually see outsourcing and CRM system of record evolution to the data warehouse as sort of the natural stages in the early days. What do you think, Ryan?

Ryan

I completely agree. That's definitely the process I've seen. One of the parts of the question was where do you start and how do you think about it? I always start from the financial plan. You have a financial plan and you have variables in your financial plan, and if you don't, you should have a financial plan. But I assume that you all do. And if you have a financial plan, that financial plan has targets that you want to hit for certain things. It has the number of Ops you're looking to create every month, the number you're looking to demo, qualify, close, the ASP the expected churn downgrades. You have some sort of financial model.

The first question you should ask is, do I have an ability to easily pull all those numbers as they stand today versus the model? If not, that is like step one. It's just do I have an ability to report on the things that I'm driving and targeting towards.

The second piece from there to me—and this is what I've always done really early on—is lay out slides of the story that you want to tell even if you don't have the data. Lay out the slides like, "Here's what's going on with our new business. Here's ASP growth and cut by these different channels and sources." Like, what are the things you would want to see and then kind of work your way through that list sequentially? Because the biggest thing that I see people run into is they get a warehouse, they get an ETL tool, and they're like, great, let me just dump everything in here. Let's just pull every different source together and they don't have a plan for how to use it. Then you just have all these raw tables in your data warehouse and no idea what to do.

So be very intentional about, "Hey, here's the data that I want to pull because here are the questions that I'm looking to answer. And here's where I think the data lives to answer those questions. And then this is what I expect output to look like." And second to that, have some in your mind numbers that you think the data is going to pull. Because the worst thing to do is write a bunch of SQL and then be like 4x off where you thought you were going to be because data cleanliness issue or something. So that's the other piece I would say is super important as well.

What advice do you have for those who fear they won’t have the specific data they need in their data warehouse in the future? [21:44]

Tyler

I have this fear of the unknown. Because you had talked about like, you start dumping all this data into the data warehouse and you've got all these raw tables that exist, but you're not really doing anything with it. This fear of, I want to start small and I want to start to just track the specific KPIs that I know that matter to the business. But there's this unknown that six months from now, I'm going to want to know the answer to this question and I decided not to bring this data into the warehouse or didn't decide to track it or set up this structure. How can you help me work through this fear?

Ryan

I think if you know that it's something you might want to track in the future, there's no harm in pulling it down now. I would just say it's going to be snapshot and I'm not going to touch it for six months. And there's definitely some data sources that are in our warehouse that I haven't touched that I know Future Me is going to run some reporting on. So that would be how I'd think about it. But, Liz I don't know what your thoughts are there.

Liz

Yeah, I tend to agree with you. I think what you're basically saying is start with the plan of what you need to get out now. It's okay if you bring in a lot more data, but know what questions you're trying to answer. One of the things on the flip side of what you're saying, Tyler, is like, I worry about people pulling and working on and analyzing a ton of data that actually is never going to be used to make decisions.

I think more often than not, people ask for things that they find interesting, but actually that aren't actionable. And it's like, "Okay, cool.I got this deck. I read 15 things and I'm like, 'Yeah, this is all really interesting information,' but then we don't do anything different when we leave the meeting?" And how do we make sure that we're actually spending people's time analyzing and giving information on questions that are going to make us make decisions or make changes and then everything extraneous to that. It's okay to keep it out there in the ether. Just don't spend time on it when you have such short, limited resources.

Ryan

And if you're the person closest to the data, you're allowed to coach up and say, "Hey, I just don't think that's going to be very useful," or my other more politically sound approach. Is I ask, "if I pull this data, what are you going to do with it?"

Liz

What decision are you trying to make?

Ryan

Exactly? Then that allows you to push back. If someone's like, "I want to pull the number of onboardings that took more than 46 days." I could do that for you. But what are you going to do with that information? To Liz's point, that allows you to push back and be more pragmatic and judicious with your own time because you're always going to be underwater as an Ops analytics person.

Like, it's just you're never going to swim your way out of it because the more you show that you can do, the more work you're going to be given because people love access to this data. So you have to be very judicious with your own time and say, "Hey, what exactly are you going to do and how does this prioritize in the stack of 15 other things I could be doing now?"

The other thing I will say is, we've talked a lot about the data warehouse piece. There is no shame in my mind at all about the CSV, download, VLOOKUP. Like that is a very great place to start. The big thing there is you need to know that the systems that you have of record have the right joining primary keys. The right pieces.

So in Salesforce, for example, for us, we have our Stripe customer ID on the account in Salesforce so that I can map back to Stripe if I were to do two exports and do a Vlookup. We also have our workspace short name, which is like the web application of QuotaPath so I can map to the usage data. So if you're going to go that route, the first thing you want to do is just make sure that in each of the systems you have a way to speak to the other system so you don't have some silo tool you have no way of joining to, even if you're just doing some Vlookups, which is the best place to start.

Liz

Yeah, I'm glad you brought that up because in these early days where you're scrappy and you don't have the money to build out these systems, that is going to be where people start. The other piece of that that I think is really important is where and how you store that data so that there's a historical record. And too often I see it's literally stored on someone's desktop, which still baffles my mind that people are doing that.

But if someone leaves the company, is there a folder in drive that you can go to that shows you like every historical data poll going back however long so that you make sure you can actually tie out what ended up in that board slide in March. Being consistent with where data is stored, even if it's not going to be in a data warehouse, I think is really important.

Are there any signs we’re headed down the wrong direction with our data? [26:35]

Tyler

We're getting close here and I want to give some time for us to just give our final parting thoughts, but are there any signs that we're headed down the wrong direction with our data? Essentially like a data debacle if we want to call it that. Are there are things that we got to keep our eyes out for. Go ahead, Liz.

Liz

Ryan I'm sure you do too. But the two that come to mind for me are different answers to the same question, which I've had happen multiple times. It's going to be really obvious stuff. How many deals do we close last month? There should only be one answer to that question. Like why is Marketing giving me a different answer than Sales whose giving me a different answer than Finance? Like, uh oh. The second one is when people are asking questions of, "I want a slide that says this," instead of, "I want to know what the data says." So when we're trying to use data to justify a decision we've already made, that gives me uh oh's.

Ryan

Yeah, I mean, those are two massive ones. I think one that I would add is if you have data that you're just not telling any sort of story with. The person who comes in is just like, I just want to dump all the stuff in the data warehouse. That's priority one for me. That is a means to an end of telling the story of what's going on with your business.

The person in charge of your data, one, they should all be the same answers to Liz's point, but should know the fundamental answers to these questions about the financial plan and how you're moving against it. So I think the big data debacle is somebody who is pushing for just tooling before they can write on a piece of paper the five questions they want to answer and what they're going to do with those answers if they go one way or another.

Liz

Data for data sake.

Final Thoughts [28:29]

Tyler

Makes sense. All right Liz, why don't you go ahead and give us a little wrap up? Maybe there's like a tip or a trick here. Perhaps a silver bullet for just, solving all my data problems. Do you have anything?

Liz

The silver bullet that I'll add first. It's kind of twofold I think, is bring RevOps into a business sooner than you think, and it's okay for that to be an outsourced resource, but making sure that your data infrastructure and your tooling is set up well earlier in a business is a really important thing to do.

Then the secondary component of that is like, bring it in house and start thinking about what are the core resources and skills that you need. Knowing that you can always supplement with additional external resources or technology or contractors. Really prioritize what skill sets you think you need in house and bring those in as soon as you can.

Ryan

I agree with that 100%. One we didn't talk about was when you're in the buying process for a new tool, ask the rep to show you reporting. It's never in the demo. I feel like no rep ever wants to go to the reporting tab or whatever sales tech tool they're pitching you. But ask them, "Hey, where's reporting? How do I get data out of the system? Do you integrate with any data warehouse or Zapier? Can I even pull CSVs?" Whatever. Just know what the data is going to look like before you start the credit card for your big enablement tool or whatever tool you're trying to use?

Ryan

Then I would say the other big one for me is no matter where you are in your journey, I always think back to the titles of the slides. If you were able to show your board five slides, what would the titles of those be in a perfect world? Then from there you can build the architecture to get yourself there. But if you don't know what metrics you want to report on, pulling all the data into a warehouse, spinning your wheels, and writing some SQL or some no cool tool is a waste of your time.

Tyler

Great. Well, thank you both for joining us today. It's been real fun. Ryan, Liz, maybe we'll have you back on to continue this conversation at some point in the future. I don't know. We'll see. It'll probably change in like two years. We'll have different things going on. So it won't be SQL, it'll be something else out of there. I don't know.

Ryan

I'm game either way. This was fun. 

Tyler

Awesome.

Liz

Thank you for having us.

Tyler

Thank you. Have a good one.

Ryan

See ya.

Building a Stronger RevOps Foundation: Actionable Insights for True Go-to-Market Agility

Discover the importance of an integrated GTM strategy and learn how RevOps lets you thrive in this straightforward guide from Fullcast. Get your free RevOps whitepaper today.

Download Now

Related resources

View More

Webinar: Ten-Minute Territory Planning with SmartPlan

Watch this webinar to see how to save time and optimize productivity with Fullcast's powerful AI-driven territory planning engine, SmartPlan.

View More

fullcast.io GrowthOps Podcast

The world of Sales GrowthOps is ripe with innovation and ever-changing best practices. With your host, @Tyler Simons...

View More

Territory Management Software ROI Calculator

Use this ROI calculator to quantify the benefits of designing more effective territories with Territory Management Software.

View More

How are you integrating data at your company? Doing it the right way will set you up for success!

RETURN TO MORE VIDEOS  

Fireside Chat: Is RevOps the Steward of Data?

How are you integrating data at your company? Doing it the right way will set you up for success!

VIEW PDF NOW