0% found this document useful (0 votes)
17 views7 pages

Transcript Systems Management For RevOps

The document discusses the importance of defining data processes and establishing data governance in small to mid-size companies to enable data-driven decision-making. It emphasizes the need for a clear data model, process definition, and a data governance framework to ensure data integrity and usability. Additionally, it highlights the significance of understanding the story behind the data and maintaining simplicity in tech stack management to avoid unnecessary complexity.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views7 pages

Transcript Systems Management For RevOps

The document discusses the importance of defining data processes and establishing data governance in small to mid-size companies to enable data-driven decision-making. It emphasizes the need for a clear data model, process definition, and a data governance framework to ensure data integrity and usability. Additionally, it highlights the significance of understanding the story behind the data and maintaining simplicity in tech stack management to avoid unnecessary complexity.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Systems Management for RevOps

Defining Data Processes

You've probably heard it said a million times that data-driven decisions are the best decisions. But, if you're at a
small or mid-size company, it isn't always that easy.

Dwamian Mcleish: The world has been beating companies over the head with the fact that they need to be data-
driven for the last decade. And so, everybody's hearing, "You gotta make data-driven decisions. You gotta put in
data infrastructure so that you can collect your data, so that you can report on it and understand it over time, and
you can use it to do machine learning." So, they've been beaten over the head with this whole concept of data for
a long time now. The challenge, especially with small to medium businesses, is, when you're talking to a larger
company, they have a data engineering team and data analysts in place to do stuff — well, a small, medium
company, they're not going to be able to bring in a data analyst, bring in a data engineering team to do all the
things that the world is telling them that they need to do in order to be a competitive company.

So, how do you get there? Make sure your company is collecting the data it needs. You might have fantastic data
analysis skills, but they won't support your cause if your data structures aren't set up properly.

Bryan Semple: Understand your data model, protect it religiously, and don't let people muck it up. Don't let
people modify it unless you approve it. So, if I was a COO or VP of Sales or VP of Marketing — sales and marketing
have got to get together and agree on — and service — have got to agree on the data model. And, they've got to
agree on some type of governance process where people do not change it willy-nilly by doing things like that,
because I've lived through some of that stuff. And, you can change the data model, and one group wants to go
change it, and suddenly all the reporting is broken, and it's what used to be end to end.

Bryan Semple: If that data model is not right, you can't tell who your customers are. You can't tell within an
account, who are your customers and who are the prospects in there. You can't properly go allocate accounts and
customers out to the sales team. You have a hard time inviting people to your user conferences. Right? So, there's
all this stuff that fundamentally impacts the company's operations that making decisions about, say, custom
objects and stuff are very, very critical to the overall go-to-market operations. And so, they shouldn't be made
lightly.

There are three main areas you need to invest in if you're going to have good data: process definition, data
governance, and tech stack management. This video will focus on the first step — process definition.

Sandy Robinson: If there's one thing that I would tell any ops leader it would be, just think process first, then how
do you enable that process?

Gregory Keshian: Don't make the mistake of trying to set up all these systems and things first, before you think
about the overall broad goal that you have and the overall process that you want to put into place to achieve
whatever the mission is that you're trying to achieve.

Asia Corbett: What are the processes in the go-to-market teams that support the buyer journey at the very basic
level? So that's, what is our lead routing process? What is our lead scoring process, starting at the top of the
funnel? Are we doing any kind of ABM, and what is that? What is our segmentation? What is our account scoring?
How are we approaching buyer intent data? And, my process is literally, what do we do? Step 1, 2, 3, 4. Do we all
agree on that? Great. Now, what systems do we have and how can those systems support this process?

Dwamian Mcleish: Think of it as your whole company moving towards agreeing on how to measure your success
and manage your customers and your revenue across all of the stages that they need to go through. And, once

Copyright © 2022 HubSpot 1


you start doing that, then I believe that you at least are now in the mindset of practicing revenue operations.

Many companies try to jump straight to implementing tools without having their processes well defined. There are
a lot of reasons why that's a mistake, but the main thing you should keep in mind as a RevOps leader is that, tools
typically accelerate whatever processes you have in place. If your processes aren't well defined, that can mean
accelerating in the wrong direction.

Daniel Remedios: There's some wonderful, wonderful, shiny tools, but they are a force multiplier. And, if you bring
them in too soon, you're in danger of slowing yourself down almost to the point of stopping because you
probably don't have clarity on exactly what tool you need and why and what role it has to play.

So, define your processes first. You're off to a good start if you've already mapped out a buyer-centric sales
process. But as a RevOps leader, you need to extend that process map in multiple directions: Where do the leads
come from before they enter your sales pipeline, and what happens to customers after sales closes a deal with
them? You'll get a sense of the journey your customers go through by mapping that out. As you do that, pay
attention to handoffs between internal teams and anywhere you should measure a conversion rate. Those will be
areas where you have to make sure everyone in your organization agrees on how things are defined.

Asia Corbett: Part of that is making sure everyone has the same definition for like KPIs. Do we all agree on what the
definition of an MQL is? An SQL? We were just going through this exercise with the SQL. Finance and marketing
were using different definitions. So, they came to me and said, "Why is this report different than this one? One of
them is wrong!" And, technically, they weren't wrong. They weren't incorrect reports. They just were using different
definitions for what an SQL is.

Take your time defining your processes. Get them well documented, and get a solid understanding of how each
team views them. The effort you put in now will save you from making mistakes in the future.

Establishing a Data Governance Framework

Let's talk about data governance. Data governance is an internal framework that manages the availability, usability,
integrity, and security of data and that establishes data standards and policies that control access to data. This is
something every organization needs to establish for itself, and you, as the RevOps leader, should lead the charge
on this.

Asia Corbett: I went through an exercise of creating a data governance framework, and part of that is which way
our systems sync, cataloging all of the data points. So, I have a data dictionary, so, if I need to make a change
somewhere, if someone asks for a new field or a new piece of automation, I go into the dictionary and am like,
"Okay, what is there?

A data dictionary documents all the fields in your various systems and how they relate to each other. In many
cases, it'll be a spreadsheet that has columns for each of your major systems and rows for the fields that sync
between them. Many times, different systems will have different names for the same field. For example, one
system says "postal code" while another says "zip." One system says "state" while another says "region." One
system has first and last name as separate fields, and another has a single field for full name. The list of possible
discrepancies is nearly endless, and it only gets longer when you add custom fields into the mix. A good data
dictionary has the following elements: A list of your most important data points, the names of the fields that hold
this data in each of your major systems, how these fields are integrated across systems, what direction the data
flows between systems, and which tool is the system of record for each field. It'll be helpful having this
documented in a single place when you need to track down inconsistencies in your data.

Asia Corbett: Data governance to me means, what kind of framework are we going to put in place to make sure

Copyright © 2022 HubSpot 2


that our data is clean and trusted at the end of the day? Because people rely on those data to make decisions. So,
you want to make sure the data is accurate, that it's correct, and you believe the data. And so, what you do to get
there is you put some best practices in place, and maybe it's a little bit of a PR thing of how you frame why we
need to do it, but you have to have some controls also. Not everybody can delete things. Not everybody can
create things. Certain fields need to be filled out at a minimum before they get entered into the system. We sync
things in a certain direction and somebody is managing that. And, the data dictionary is actually part of the
framework because, when somebody asks for something new, a new field, which is a data point, you think, "Okay,
yeah. Why not? I'll just capture that data point." But, we'll accrue tech debt so much quicker, so much faster if you
do that. You don't need every single field that somebody asks for. Maybe you can accomplish it with what you
have.

People will always want to add customizations to your systems, but oftentimes, simpler is better. We have a saying
here at HubSpot: You can't add simplicity in. You must take complexity out. Part of your job as a RevOps leader is
to keep your company's data structures as simple and clear as possible.

Bryan Semple: The easiest way to be super nimble is to do everything vanilla and out of the box. Right. There's a
limit to what you can go do on that, but absolutely every single customization that you want to go do, you really
need to think through, "Do I really, really need to do this?"

Bryan Semple: You can come up with a business case or a use case that would necessitate customization. What
you've got to balance that against is, is that customization going to (a) literally move the needle on the results for
you, and (b) are you willing to take on the downstream maintenance and complexity that customization drives?

Asia Corbett: I walked into a ten-year-old Salesforce. Highly, highly custom, lots of custom objects, lots of custom
fields, page layouts, workloads, all of this. And so, the challenge is, what do you want to do? We would have to do
audits every so often. And it's like, okay, do we want to unravel everything and start from scratch? Because
everything is built on top of each other, and you pull out, it's like a Jenga tower. You pull out one thing, you don't
know if the whole thing's going to come crashing down.

This isn't to say you shouldn't ever customize your systems. You want to configure them to match the processes
you're trying to enable. That might happen through customization, and it might also happen by adding more tools
to your stack. The goal is to stay within your data governance framework and remove friction from your flywheel.
The main goal of data governance is to make sure your data is pulled together in a way that makes it usable.

Gregory Keshian: A lot of my background personally has been in companies trying to help the business grow
better by using data. And so, taking data from all the different systems that we use and trying to make sense of it,
to look at different places that we could grow revenues or places where we could become more efficient. And,
what I've always found is that it's really hard to get all of that data into one place and make sense of it, and provide
recommendations to people on an ongoing basis that can help drive the business forward.

As you establish data governance rules for your company, you might find there are certain people in your
company who want exceptions to those rules. Insist that everybody works together to preserve the integrity of
your data model.

Bryan Semple: Someone would say, “We want to go add a field to track X.” Right? And so, I'd say, “Okay, you really
want it?” “Yeah, we’ve absolutely got to go do that.” I'm like, “Okay, great. So your requirement now is — when I run
organizations, I have weekly metrics, right? So, your requirement is you've now got to track that weekly metric for
me. That weekly metric every week. You got to track it for me. I want to see the number." So, if you want them to
report on, I don't know, give me something — the source of a lead code or some lead code. "If you want to report
on a lead code, great. I want you, that's asking me for that data, to report on the lead codes, by week." And, if you
do that, what you find is that there may be this big, "Oh, we got to track lead codes!" And it sticks for a couple of

Copyright © 2022 HubSpot 3


weeks, right, but then after like five, six months, no one's tracking it anymore. So, you go back to the metrics and
you say, "Well, wait a second. Why aren't you tracking this anymore?" Right? So, I understand people want to track
information and get data, but then make them record it and then prove to them that they're going to go take
action on it. And, as soon as you see that they're not, then you gotta go back and say, "You're not using it
anymore, clean it up, delete it."

Linking data governance to reporting is a smart choice because the data your tools provide you with will be
useless if you can't use it to generate insights for your company.

Devyn Bellamy: You have to work through that data. And, what helps is basically knowing what to look for,
knowing what people want. Wonderful reports don't come out of thin air. I've tried. I've sprinkled; nothing
happens. What works for me is — and this is going to blow your mind — what works for me is asking people what
they want to know, and then, finding the data to answer that question. And so, I won't go to our head of
operations and ask them, "So, what reports do you want to see?" I'll ask them, "What do you want to know?"

Your company's leaders want to know how revenue is doing, but you can dig a layer deeper to uncover the factors
affecting revenue generation.

Dwamian Mcleish: Revenues is what people term as a lagging indicator. So, I would always encourage people to
figure out what the leading indicators are because, if you're doing true fast feedback loops and continuous
optimization, the only way to practice that is to find all of your leading indicators that turn into lagging indicators in
your organization and watch them closely, and culturally be willing to make adjustments to achieve what you're
trying to achieve in revenue. So, with that said, it's always nice to pick a tool that surfaces a lot of those indicators,
things that people might not even think about. Like, you know, the number of tickets that we have in our customer
service department might be a leading indicator of customer churn. But, if you can't see those two things or
multiple things together, then, it becomes very difficult for you to understand what levers are being pulled in your
organization in order to have a specific outcome, or what levers you can pull in order to have a specific outcome.

When you examine the data available to you, you should always dig into the story behind the numbers.

Devyn Bellamy: Well, when you're looking at your data, you don't want to think of your data as numbers. You want
to think of it as a story. So, if you are looking at your numbers, and we'll just use something generic, like analytics.
if I see that I have 100,000 views when I normally get a thousand views, and I have a 99% bounce rate, and it's
from a country that we don't do anything with that is — surprise — known for bots, then maybe we're getting a lot
of bot traffic. We should do that. And so, I'm not thinking it's like, "Yeah! A hundred thousand views out of
nowhere! Win!" No, you gotta be able to interpret that data and tell a story with it. And, that's the secret to being
an analytics professional.

You can only generate useful insights if you have good data to work with. That's why data governance is so
important. Document the connections between the various tools your company is using, and establish rules for
adding and removing tools and fields in the system. Then, commit to updating that documentation and enforcing
those rules. In the end, these steps will save you time and effort in the future.

Managing Your Tech Stack

Once you have processes and data governance in place, then it's time to move on to tools.

Matt Bolian: Every business that makes revenue has some way of tracking leads and opportunities. So, to say,
there's not a CRM, it's just like, they can't exist without one, because that process has happened. It might be an
Excel document. It might be your brain, but a CRM exists.

If your sales team isn't yet using a CRM software platform, it's time to discuss how implementing a software

Copyright © 2022 HubSpot 4


platform will help improve your company's processes and customer experience. Then, you'll probably get tasked
with implementing that system. This is an ideal situation because you'll be able to ensure that the tools get
implemented in a way that supports your processes and follows your data governance rules. It's much more likely,
though, that you'll inherit a messy tech stack that resulted from every department obtaining different tools, without
thinking about the impacts to the larger organization.

Bryan Semple: Sales wants one chat, marketing wants the other chat, and support wants the other chat, because
they're all on different systems. And, without a strong CFO to say, "Look, we're not doing this," you end up with
multiple systems and not integrated. It becomes a mess.

Devyn Bellamy: More things are on the internet. More tools are on the internet. More people are working with
more tools on the internet. You look at any category, you look at any vertical, and then, you look at the ecosystem
for that. Oh my goodness. There is something for everybody. And then, there's some things that are like three
things for eight different people. Just getting all that to tie in becomes daunting. And, it becomes overwhelming
for the person who has to sit through those financials meetings, and wondering, I've literally sat through those
where you go through every single charge on the card and it's like, "Okay, why are we paying for this? What does
this do? And, does it work?" And, that's the bottom line. That's just the bare minimum. It's like, "Do I really need to
be paying for this?" But, even to take it a step further to talk about the functionality of these things and whether or
not we can make them better, and work even more for us and solve even more problems. That's, I think, what's
making RevOps really hit: When it's not just about doing the job; it's about managing the tools that it's taking to
get the job done and writing all of that data and being able to make a cohesive decision or coherent decisions
using that data.

Matthew Volm: As an ops team of one, the main thing that you're lacking is you always need more time. You never
have enough time to do all of the things that you want. And so, it can be very tempting to immediately start with
thinking that you need to solve all of your problems through automation or technology. But, I think, in reality, when
you approach a problem that you have, and you're trying to think about a solution, a lot of times, the first thing you
need to do is just figure out manually, how would I get this done?

Matthew Volm: You don't want to spend 10 hours trying to figure out how to automate something that would
otherwise only take you 30 minutes to do.

Regardless of whether your company needs to implement a tech stack or has a full tech stack already, you might
find that they look to you as an IT specialist or systems admin. To clarify, RevOps and IT do have some overlap
when it comes to managing the tech stack, but, they're jobs and priorities are different.

Devyn Bellamy: IT and system admins make things work and a lot of times even make things work efficiently. But,
very rarely do they get into the why behind whatever it is that's being used. And so, you can have a systems admin
set up your CRM, but if they don't understand the why behind why you're using your CRM, then what's going to
happen is that it's going to grow out of control in the direction that you don't need it to.

Devyn Bellamy: When I'm working in operations, and I'm assessing an existing build, or an existing workflow, or an
existing playbook within the company, I start looking at what's not working, and then, basically looking at just
removing processes until we get to a point where things work. And sometimes, that means just nuking the whole
thing and starting over, because it's just so bad. It started out with being the best of intentions, but turned into this
unwieldy Cthulhu of a system. And so, the idea is with systems admins and IT, they'll fix things, but RevOps is
about revenue efficiency. It's about data transparency, and it's about making sure that the company is behaving
responsibly with tools and with data and leveraging the tools and the data for success.

Keep in mind that sometimes you'll be required to have tough conversations about tools the company is paying
for but doesn't need. This is why it's important to define your processes and data model first.

Copyright © 2022 HubSpot 5


Dwamian Mcleish: This is like the fight, the big fight in companies where you're having the conversation about
which tools are actually relevant, what data is relevant, whose process is relevant. I've heard and seen that fight
many, many times. I believe one of the big functions of revenue operations is to create visibility into how data
moves and revenue moves throughout the organization. And, when I say "visibility," not just saying how data
moves through, but actually creating some visibility and some kind of value stream map or process map across the
organization that shows people how revenue is being connected throughout the different systems, people, and
departments. And, once you create that, then I believe that the conversation about which tools support this
movement, or support the optimal movement, becomes a little bit easier, because that's really what people are
questioning here — which tools are relevant? And, if you say that this tool is relevant to you, can we show that it
actually is relevant to the entire system? And, if you can actually visualize that, I think the conversation becomes a
little bit easier in terms of either what tools you used, which I personally don't believe it matters what the tool is
that you use. I think it more matters the type of data that the tool is going to support in making the decisions that
you're trying to ultimately make. And so, for me, it's always about creating that visibility for everyone in some kind
of value stream map, and then justifying how it moves through the organization because, ultimately, once you
make the case, like, “Look, we're moving a customer through seven different systems and there's really no benefit
of going through those systems,” and you can visually represent that and make a case for it, then, it becomes an
easier conversation than just, say, “Hey, I'm going to remove four of those systems.” Right? It's different. And so,
you want to bring visibility by creating visuals and visibility and in almost every way that you can.

Recognize, too, that if there are systems you need to remove, the teams using those systems might not want to
give them up. You'll need to help the affected teams navigate that change.

Asia Corbett: It's a challenge, I think, to come in and thin your stack because, if it's already built and see at some
level people are using it, so they're used to what they're doing. So, you got to take them out of it, and that's a
change, and you may or may not give them a new system. And then, I think another consideration is what kind of
data are you going to miss out on? Because we actually are gathering a lot of data. But, it's in a silo that's living in
different systems, and it's very hard to connect all of it and build a full picture.

The takeaway here isn't to keep your tech stack small, since that might not be possible; it's to make sure that as a
RevOps leader, you have a say in what tools get added to the stack and why these specific tools are vital to the
business.

Jen Bergren: Ops should be in charge of tool approval if not in charge of tool budgets. They should align with the
team leaders and finance and IT if those departments exist. Don't let each team and the company, especially each
team member in each team, be able to just put a subscription to a new tool on a company credit card without any
kind of approval process. That's setting you up for the opposite of success.

As teams request new tools, keep an eye on what adding those tools will do to the customer experience. The path
should feel as linear as possible for the customer.

Dwamian Mcleish: I mean, if you encompass just the concept of, if they're a lead, a prospect, or they're in the sales
funnel, and they're maybe in the customer success lifecycle, and then they're in some kind of offboarding lifecycle
— that seems linear. But, once you start overlapping the operations perspective of managing that revenue/
customer, then you'll see, maybe the customer might be getting several marketing communications from the
marketing team out of this tool that might be generating this data or using this data in order to send that. And, if
you kind of overlay a lot of those things, you'll see that the data actually is tentacled out into the entire
organization to different systems. And, some of those systems are connected. Most of them are not. And, it
depends on, when you get the data and when you try to use it, the data may or may not be accurate. And so, you
want to try to figure out how far away from accurate that data gets when you're using it in order to support what
you're trying to do in terms of your revenue mission.

Copyright © 2022 HubSpot 6


Something to consider is that some of your foundational tools might already have capabilities that make other
tools unnecessary. For example, your CRM might have sales enablement tools built into it. They might not be as
feature rich as dedicated point solutions, but if they're fully integrated into the CRM platform, the savings in
complexity and cost will be worth it.

Jen Bergren: My first response for when people request tools is, "If HubSpot or our project management system,
which are our two most important tools, if they can already do what this supposedly new tool can do, it's going to
be a tough negotiation to get that approved.

Dwamian Mcleish: I would always encourage, especially smaller, medium size companies — you are already using
the tools, try to get the data out of those to surface those leading indicators in a way that the organization can
consume, and then use that to pull on levers to make those fine adjustments that you need to optimize for your
revenue.

Many point solutions will have deeper feature sets than a full platform will, but the more point solutions you adopt,
the more complicated your tech stack will become. It's vital that you lean into your data governance rules to help
your company navigate the tradeoff between depth and complexity.

Bryan Semple: I've always weighed in the back of my head, is it worth — is all this theoretical best-of-class
integration of the best-of-class sales system, or the best-of-class marketing system, or the best-of-class CMS
system — is it worth it? And, do you actually get competitive benefit out of it? Or, a couple of years down the road,
you just end up with a spaghetti system that you can't manage or deal with? Versus just kind of saying I'm going to
go with a fully integrated stack, and I'm not going to give into the pressure of, "Well, you know, if we could just
have this one widget and this way, this thing doesn't happen, let's go to that widget." You say, "No, we're going to
a fully integrated stack because we think we're going to maximize value that way and stay focused on what
matters," which, depending on the organization, is generating revenue and customers.

Daniel Remedios: Sometimes these wonderful, wonderful market leaders are enterprise tools. And, they're
incredibly complex, and they require a lot of attention, configuration, and before you know it, I am burrowing my
head down into this particular tool, and we all suffer as human beings of having an inflated view of tools or
anything that we've invested a lot of time into. It's just an attachment, almost a romance, around the whole thing.
And so, the problem is this whole thing compounds.

It's easy to add tools you don't need and to hold on to tools you should get rid of. But, if you stay focused on the
high-value, low-friction experience you're trying to give your customers, you'll be able to establish data
governance rules that will guide you toward creating the best possible tech stack for your business.

Copyright © 2022 HubSpot 7

You might also like