HubSpot Academy's RevOps certification features so many amazing experts that I was honored to be included in the systems management lesson of the final product. Thanks so much to Kyle Jepson and Mary Barba for making this useful revenue operations certification and for including me! This is a free certification, which is great to make learning about the topic of RevOps more accessible to more people. The lack of official RevOps training and certifications is a topic that many people mentioned in the RevOps book interviews I conducted, so I was very glad to see HubSpot working on a solution around the same time.
Shameless plug -- if you've already taken this certification, the next step is to enroll in HubSpot Academy's free RevOps bootcamp. This is a 6-week live course to learn how to succeed in revenue operations, which I co-created and co-teach.
If you read my previous blog, you know that in order to speak on a webinar, podcast, or other type of interview, I have to prepare extensive notes and practice them. Today, I'm sharing the notes from this interview with Kyle. I did edit these notes for grammar, but the answers are more rambling and not as clearly constructed as a normal blog. And because this interview happened a while ago, some of my answers may be different now in the present day. I hope it is still helpful information to get you thinking about the topics.
Questions:
-
What’s the relationship between RevOps and marketing/sales/CS ops? (Both ideally and in reality)
-
What are the top 5-10 things a RevOps team should tackle first?
-
When is it time for a sales ops person to become a RevOps team? How should the team be structured?
-
What roles should you create and how do you fill them? Any advice for finding people to fill them?
How did you come to be in ops?
Like many people, I fell into it, or discovered it, during my third career which was in marketing and marketing technology.
When I first read or heard about this thing called Operations, I was relieved to have finally found a name for how I was working, my method of working, in all my previous jobs and careers.
You can read about my career journey in this article.
Learning about RevOps:
Remotish transitioned from calling ourselves a Martech agency to a RevOps agency last year [at the time of this interview] when we discovered that RevOps was actually what we were providing clients with, helping them across all their revenue teams. When I was researching RevOps during this transition, I realized there was very little consistent information online about RevOps. There have been a growing number of events/webinars/podcasts/social posts but not a lot of consistent, searchable or findable text content. I decided since I was doing all this research anyway, I should combine it with another life goal: writing a book!
While doing this research, I discovered the wider world of Ops as well. I realized that operations was actually what I had been best at in my past careers in design, photography, as a business owner, and more. So we recently transitioned my role to officially be Ops, most of which I was already doing. Since reading and writing are my other top interests, the book fulfills those needs.
How would you define revenue operations?
What is RevOps?
That is the big question I'm trying to help answer in my book, tentatively titled, What is RevOps? I interviewed about 35 RevOps, ops, or revenue experts in the second half of 2020.
Without any alignment within our own industry or profession about what RevOps is, there is not a lot of hope for elevating ops, for shining a light on the value of ops. There is not much hope for recognition for these behind-the-scenes rockstars, hope for getting more career-building resources like this certification, hope of creating clear career paths…
There is irony in having an industry/function that is focused on aligning teams, yet we are unaligned in what this ‘thing’ called RevOps actually is.
Not only can we not agree on what RevOps is, there is even debate about what to call it: RevOps, Growth ops, GTM (go-to-market) ops, operational excellence…. We could probably name a few more choices!
Related book research
I can give you some data from the about 35 people I asked about their definition of RevOps.
The top words or phrases used when responding to the question, What is RevOps:
- 16 people said processes as part of their definition
- 12 people said GTM, go to market, commercial function
- 11 said alignment
- 10 said sales ops and marketing ops and CS ops (customer service/success/support -- I don't like acronyms but since the 'S' can mean several relevant departments, I will be using it in this article)
- 8 said full/entire customer lifecycle/journey
- 8 mentioned efficiency or operational efficiencies
- 7 said data was part of the definition
- 7 included something about optimizing for revenue growth/engine, or operations as the engine
While we're noting what was mentioned the most, we should also note what was mentioned the least, the word 'people.'
Though later on, this subject was mentioned a lot in the revenue operations discussions, it was not specifically called out in the definitions.
The missing human element, or people element, was also a trend I saw in the RevOps content online in 2020, which was heavy on tech and tools questions and advice.
A lot of my interview questions were focused on what I called the human side of RevOps, to try to learn the information from experts that wasn’t making its way into written, searchable content.
And for a sneak peek at a work in progress, I tried to create a definition that is broad and more strategic, it is not an in-the-weeds tactical definition, it’s more overarching like a mindset. (I don't like the term philosophy since it sounds like you’re not doing any work.) And remember the goal of having a common definition across companies and industries: If everyone uses the same definition then it achieves what is best for the revenue operations professional---alignment, understanding, and respect.
Are you ready?
The rough version of the definition of RevOps I’ve tried to distill from all this research is:
The people, processes, and tools used to strategically manage the full customer lifecycle and experience, which optimize the revenue engine through operational efficiency and alignment across leadership, departments, industries and more.
It combines traditional sales ops, marketing ops, and customer ops, breaking down silos to ensure teams are working toward shared goals.
That is still rough.
I also like how you’ve [HubSpot has] been including the ability to scale and the customer experience as parts of the definition.
Different sizes and stages of companies may need to interpret this overall definition slightly differently.
But what about data, you may ask?
Data is mentioned in 7/35 definitions, about 20%,
Data drives most of RevOps, such as data unification through all tools.
Aligning data and the trustworthiness of data are a goal of RevOps, to have the right data as a single source of truth which is used for all actions and decisions.
The deep diving into data is starting to be known as an ‘offspring’ of RevOps called revenue intelligence.
Bringing it back to the people element of RevOps:
So people... aligning, training, managing, leading, persuading, influencing... are a big part of RevOps.
And unaligned people are also a big reason why RevOps is not understood, recognized, or valued as much as it should be.
What’s the relationship between RevOps and marketing/sales/CS ops? (Both ideally and in reality)
Ideally, all these ops activities exist inside RevOps; they are all united. All these previously siloed depts and roles should be combined under RevOps.
Another way to put it is if those ops activities are happening in a company that practices RevOps, they should be included in RevOps.
Otherwise, it is not truly RevOps if you’re not including all three or more areas of work, if you’re not including the full customer journey, end-to-end revenue cycle, all the way around the flywheel.
I am not saying every RevOps team or person needs to do every sales ops activity that exists, every marketing ops activity possible, or every customer ops that exists.
That's quite frankly not possible.
But there should be a mix of all those types of ops happening inside of RevOps departments or roles.
In reality, one mistake I heard about in my research was about companies only doing sales ops activities, not involving marketing or CS at all, and calling it revenue ops since it sounds cooler or trendier. But they are not inviting marketing ops, customer ops, or any other ops to the party. Which is not good.
Related book research
From my book research, 10 people out of 35 mentioned “Sales ops and marketing ops and CS/customer ops“ in their definition of RevOps. Even more people spoke about those areas when discussing different questions.
Another relevant part of my research was this question: What functions are considered part of the RevOps team at your company or in your opinion? For example, is enablement part of RevOps?
How many people included each phrase in their response;
- Sales Ops: 14
- Marketing Ops: 13
- CS ops: 11
- Enablement: 11
- Product Insights, Data Analysis, or BI (business intelligence): 4
- Partner program or partner ops: 3
- Sales solution engineering or CRM tool development: 3
- Channel ops: 3
- Lead Optimization or business deelopment operations: 2
- Data infrastructure: 2
- GTM Strategy, Strategic Growth: 2
That doesn’t exactly answer your question about the relationship between those three areas, but it does point to a conclusion that all three should be included in RevOps.
At what stage in a company’s growth do they need RevOps? How can a company know when they’re ready to invest in RevOps? Can it ever be too early?
Can it be too early to hire someone whose only job duties and title are in RevOps? Yes.
But there is a semantics difference between hiring someone with an ops title dedicated to only ops every day vs. having many people on your team with an operational mindset who are doing ops work as part of their everyday jobs.
There is an argument that you might not be able to grow your company big enough to be able to afford a person dedicated solely to ops, or especially dedicate even more specialized as RevOps... unless there are already people at the company doing the ops work as part of their job, building the foundation of ops.
I saw you [Kyle] have a blog that says, yes, it can be too early, when the founder needs to go through a messy linear growth stage first.
I would say yes but only if the founder has an operational mindset or hires a few people good at project management, documentation, training/enablement, creating/following processes, etc. So they can still build the foundation of general ops (maybe not specifically “rev” ops) by doing the things you mentioned the founder was doing in the article:
- Taking notes and updating your hypothesis
- The team or founder could also be documenting their experiments and the outcomes so people remembered what they already tried and why not try them again
- Developing a set of best practices that you circulate with the members of your sales team
- This is documenting that sales process and enabling the team to easily follow it -- ops work
So even if you don’t have or hire an official ops person, there is still ops work being done.
It may be invisible behind-the-scenes ops work, or fragmented ops work.
If you are organized and you recognize that invisible ops work is happening, you could start doing the work in a way that an eventual ops-dedicated person can take over, to easily hand it off to them.
If you hired ops-minded people to do the sales, marketing, or customer roles, you can transition or hand off those ops parts of their roles to an official ops person when the company is a bit bigger.
For hiring people dedicated to only doing RevOps specifically, its too early if the company doesn’t even have people or teams who are dedicated to sales, marketing, or CS yet.
I can give some examples from our own agency which is in its third year and we have 10 people so it may be relevant.
When our agency evolved to calling ourselves a RevOps agency last year when we realize we weren’t just helping marketing teams but also sales, services, and success teams, I started doing all this research on RevOps which is what led to the book idea. My CEO and I actually thought my next title would be a RevOps title this year.
But we didn’t hire our first person dedicated to sales until earlier this year and we still don’t have anyone dedicated to marketing. So my title is operations in general, since it wouldn’t be true RevOps...and also I wanted all the ops! They are all mine, give me all the ops! :)
From personal experience with our agency, I can say that hiring operational-minded people is important if you’re hiring for the company’s start and growth, to help set up ops from the start. Even if the people don’t have official ops titles.
This is what led to our agency's success since my CEO understood the importance of ops-related work. Emphasizing ops is my natural way of working, so I am grateful to have found her. We make a great team.
I started in the company’s second month in business early 2019, and I was documenting and creating processes and organizing, building the operational foundation that's baked into company policies and processes now, while I moved up into management, and as we hired people to fill my past roles.
We’re small and still a new company, but we’ve been able to earn the HubSpot partner agency diamond tier already, which is the second highest ranking possible, because we devoted time to ops since the beginning.
We didn’t have a person dedicated to ops, but we did dedicate time to it.
There is also a case to be made that building ops, and building in general, is easier than cleaning up and untangling messes. For example, if the messes are from a company that is 5 years old, it seems like it would be very hard for an ops person to be successful if they are a new hire to the company who has no idea about the history or internal evolution of the company and its processes. It would be especially difficult if they are a team of one, and expected to take support requests from every department instead of building their own roadmap for strategic work, which is a common case I’ve heard about. That seems like a no-win situation.
If you’re at that point of having a mess, then hiring a RevOps team of one is not going to solve all the problems, because that is an impossible task for one person. You would need several people and a strong leader to strategize and align everyone to get the “revenue engine” running efficiently to scale.
When a company changes from startup to scale up, what does ops need to do to make that transition successful? What steps are involved?
Bringing it back to the people, process, and tools categories of work, take care of those areas in that order of importance.
People first.
Focus on your current team members and current customers.
Retaining them, making them more efficient, making them happier.
Aligning people, training people, enabling people...this could even involve internal reporting structure changes. Aligning people with same job titles to do the same things, aligning promotion and hiring criteria and processes. You can hire the right people faster when you have clear job descriptions, and then train them to ramp up faster.
For this people side of scaling, documenting what every person is doing is an important step.
If someone wrote down everything they did and how to do it, they could easily take vacation stess-free, and also get promoted since it is easy to hire someone to take over for them if everything is docmented. We created a template for what we call a backup plan, we have all team members create and maintain one, and have specific backup people they trained on filling in for them when they are out of 'office.' This also allows us to have 30-hour workweeks as a benefit, after people earn the qualification for the benefit.
Accomplishing this could involve making sure your team does not having the scarcity mindset, like 'I'm going to keep all the knowledge in my head so they can’t fire and replace me." In reality, that is not going to prevent you from getting fired from any job, but it may stop you from getting promoted if the company can't fill your current role!
That mindset is also not going to help the company scale!
So concentrate on people first.
Process would be the next step to concentrate on -- making plans, documenting current processes, making current processes more efficient. There is some overlap with the people focus, of course, since you will return to the people step and align on the refined processes, train on new processes, enable people with documentation, practice change management...
Then it's time for the subject that always gets the most attention, tools.
What tools will make the processes easier for people to follow?
What tools will make the processes more accurate, efficient, and automated?
What tools will help align people,?
What tools will let you see the end-to-end revenue stream and all the steps in a customer journey?
Concentrate on using the current tools most efficiently and streamlining the tech stack, then create a process for adding new tools to your stack if needed.
Then it's time to return to the people focus again!
Train the current teams on using the tools correctly so the data is entered cleanly and/or automatically, explaning why that is important for their own success. Make the importance of all of the ops-related work part of onboarding new employees, to ramp up new employees faster.
What are the top 5-10 things a RevOps team should tackle first?
Before you jump into working on projects, especially if they are projects non-RevOps people requested, make sure your company first has alignment about what RevOps should be doing, what it should be in charge of, and the measures for success.
After that, here are a few ideas of first projects:
- Documentation of current processes. This is rarely done, and it is very hard to improve anything if you don't know where you are starting from.
- Putting a change log and change process in place, then educating everyone on it so they follow it. Make sure they know what’s in it for them: to gain visibility of the experiments and changes going on, so there aren't unintended downstream effects.
- Making other people aware of ops responsibilities and why the ops projects will help the company and coworkers.
- Creating ways to report on your ops team’s success, so you can gain visibility and gain headcount/resources/budget. This involves influencing people and may be more of a leadership or aspiring leader project.
- Data cleanup and achieving end-to-end visibility of the customer journey, which probably involves minimizing/optimizing the tech stack and integrations. The people side of that is focusing on customers, and also enabling internal teams with this data visibility, usability, and knowledge sharing.
If a company has separate marketing/sales/CS ops, how do they unify them into RevOps? What problems and pitfalls will need to be overcome--and how do you overcome them?
Similar to the top things a RevOps department should do at first, I would also say your company needs to gain alignment first on what RevOps should be doing, what it should be in charge of, and measures for success. This may be a chicken or egg question, if you centralize first and then rally the company to align what the now-centralized team should do, or align first to make sure everyone sees the benefit of centralizing to a RevOps deparment and what they would be responsible for.
That probably needs to come from leadership to bring them together under one leader, for alignment.
The dotted line reporting structure, where the ops teams still report to siloed leaders, could be difficult since there are competing priorities and competing leaders, instead of one unified leader and unified KPIs for success for all the ops team members.
I’ve heard it can work if the CEO or another top leader aligns the whole company around the same values and goals, and the 3 teams already have good relationships, they're communicating, they've connected their tools, they're reporting using the same data sources not with competing data from different tools, and so on.
What advice do you have for someone who has just become their company’s first RevOps professional? Where do they start? What skills do they need?
Start with making sure there are shared goals and metrics between departments, though that could be difficult if the RevOps person isn’t in leadership. If they are an individual contributor and a new person to the company, it would be hard to convince people to align their goals across departments for the first time. That's a challenge leadership would need to be involved in.
For an individual contributor, my advice would be to make sure your boss knows that you will not be able to do every activity that is involved in RevOps by yourself. Especially at the beginning, and especially right now when the word RevOps can mean just about anything, until the industry has some alignment itself.
And I think there would be major differences in my advice to new ops professionals depending on company culture and leadership. For example, does the company value the ops work or not? That would make being the first hire tougher if the company thinks of ops as just a support desk.
Who the first RevOps professional reports to is also crucial. If they report to the sales leader, their job is going to lean heavily into the sales ops work, so marketing and customer processes may not get as much attention. if the leader doesn’t value ops, the leader won’t help the new hire to align all the departments, or to get the new hire the answers they need to complete their projects, for another example.
To this first ops professional at a company, i would say you will need to have a focused mix of tactical and strategic work. If you operate only as a support desk doing tactical work, then you won't have time to complete every request by all the departments you work with. And if you don't address some of the requests in some way, no one will want to work with you to complete your strategic projects, either.
Make a roadmap for the quarter, for the year, whatever amount of time you can manage. Get it approved by your manager, and stick to it for your most important quarterly projects. Leave around 25% of your time for putting out fires, the truly urgent things requested from you.
Mapping out the end-to-end process of the customer journey may be a good starting project to get teams aligned and help them see your value. Getting many cross-departmental people’s input and agreement on that, to add in the more detailed parts of the processes, can help speed up the improvements, and reduce internal friction, focusing on the customer journey and experience across all teams to help unite them. It will involve asking a lot of questions to understand individuals' jobs and understand the customer. It will help you build relationships with all teams.
In short, don’t become just a support desk or you will likely not have the time to gain or use the strategic skills to advance in the company. Make sure you make time for, and stress the importance of, bigger projects.
What skills does the first ops professional in a company need?
I would say mostly people skills for influencing management, gracefully pushing back about being a support desk or about being only a tool admin. The ability to build relationships and eventually help align different departments is a necessary skill, to be able to get the info you need to complete your projects, too.
Being able to say no in an understanding way will be exceptionally helpful to ward off the numerous requests from numerous departments you'll receive.
These people skills are more important in a generalist RevOps role than knowing certain tools at an expert level, or knowing how to do crazy deep data analysis in Tableau, or knowing how to custom code an integration by yourself. If you’re a team of one, you can’t just be an admin or analyst. If you’re the de facto leader in RevOps as well as the only worker, make time to be more strategic.
Related book research
Speaking of skills, I did have one related question from my book research.
"In your opinion, what training or background makes someone successful in RevOps? Is it more successful if someone comes from ops or if they come from the sales, or marketing, or customer team? (Or other?)"
Some of the common overall responses to these questions were:
- Data/Financial Analyst background, being data literate: 13 people
- Ops background or mindset, organized and process-driven: 10 people
- Project management or program management experience: 6
- Problem-solving, breaking it into digestible pieces: 6
- Consulting background: 5
- SDR or BDR (sales reps) at some point, understanding sales: 5
- Empathy (usually related to being in those roles yourself before): 5
- Mediation/negotiation/influence, gathering consensus, managing multiple stakeholders: 5
- Motivated by making things better, a fixer: 5
- Proactively finding what is wrong and fixing it (identifying areas of opportunity and take action): 5
- Tinkering/building/experimenting (could also translate to being a developer/engineer): 4
- Curiosity and willingness to learn about sales, marketing, CS, your product, and industry: 4
- A good mix of experience: 3
- Having a customer lens, passion for the customer (internal or external customers): 3
- Communication: 3
- Technical ability with a willingness to learn business: 3
- Systems admin or database manager background (if the role calls for it): 3
- Business background, able to understand the business: 3
- Being a master generalist or T-shaped: 2
- Customer service background: 2
Though being data literate was #1, most of the rest of the top answers are that hidden part of RevOps we’ve mentioned: people skills, such as empathy for the teams and the customers.
"It’s hard to [work with] someone in those roles if you haven’t done it yourself, if you haven’t been on all of the teams, sales, marketing, CS. If you haven’t been in those roles, you don’t know what to look for, what to fix or improve," said Nicole Pereira, CEO of Remotish.
What does a RevOps role entail? What’s the day-to-day like?
So my role isn’t technically RevOps, though since I do all the ops, there is some RevOps work I am doing.
Every day may be different, with so many areas to tackle, switching from strategic work to tactical work and back again… there are a lot of unique answers to this question.
Related book research
I had two book research questions related to this topic.
- In your RevOps role, what do you spend the most time doing?
- What RevOps project are you working on right now that excites you?
In your RevOps role, what do you spend the most time doing?
- CRM and or revenue teams' main tool improvement and integrations: 13 people
- Data analytics or analysis, forecasting: 10 people
- Air traffic control between the 3 groups, alignment, collecting and sharing information, guiding people to the right solution, communicating to leadership: 8
- Process audit/development/improvement: 7
- Data consistency and availability, full-funnel end-to-end visibility: 7
- Finding stories/challenges that matter across all teams, problems to solve, gaps: 5
- Making sure customers are getting a good time to value and customer experience in the product: 4
- Managing their ops team, coaching (people management): 3
- Auditing systems and processes (non-tool related): 2
- Productivity of customer-facing teams: 2
- Sales or marketing or overall GTM strategy/planning: 2
- Documentation (communication): 2
- Problem-solving: 2
- Handoff between sales and customer success: 1
- Sales process: 1
- Aligning sales and service for renewals: 1
- ABM (account-based marketing): 1
- Budgeting: 1
- Prioritizing projects: 1
- Analyzing time spent of teams: 1
- Enablement: 1
- Developing goals and roadmap for them: 1
- Creating the team structure, roles: 1
- Talking to prospects and customers, understanding customer needs: 1
- Marrying tech with process: 1
What RevOps project are you working on right now that excites you?
There was not a lot of overlap here. All are unique answers except for the first bullet.
- Yearly planning including budgets for headcount (most interviews were in October and November): 2 people
- Handoff between sales and service so customers get the most from the product right away
- Driving sales playbook to ensure disciplined execution of the process
- Hosting a CS RevOps meetup
- Helping create education on RevOps and general ops
- Improving ops community
- ABM projects for clients
- Choosing a CPQ (configure price quote) vendor
- Problem-solving for clients to get the right data at the right time and trust it
- Product qualified lead model, account hierarchy, giving the right lead at the right time when the decision-maker is ready (similar to ABM answer but the tech side)
- Scaling business using trustworthy/sound analytics, GTM strategy and structure
- Tech stack evaluation and optimization
- Integrating customer journey and tech touchpoints
- Analyzing customer movement through segments
- Building strategy for RevOps
- Re-architecting CRM, hierarchy, compliance for scaling to enterprise, so you can follow the same customer throughout the journey
- Integration of software
- Leveraging data more nimbly
- Getting end-to-end visibility on the funnel
- CRM cleanup
- Starting to use a new BI (business intelligence) tool
- Tracking customer retention correctly in CRM
- Forecasting
- Building the department, processes, strategy
- Getting rid of tech debt from building so quickly (a common theme)
- improving/fixing deal management, reducing complexity
- Improving customer experience
- Improving data hygiene, so you can look at it once and say, 'yes it’s clean and sustainable for business'
- Lead scoring and lead routing improvement
- Exploring low-touch/no-touch business models
- Operationalizing marketing plans like ABM
- Building a system/integration to increase efficiency and reduce redundancy between two tools
- Building operating system for GTM teams
- Starting a RevOps department
When is it time for a sales op person to become a RevOps team? How should the team be structured?
So I would argue with that phrasing since not all RevOps people were sales ops first, and not all companies have sales ops first, some may have general ops, some may be marketing ops…That is a trend, though, for the companies we work with and in the SaaS world. To have a big sales team and smaller CS/customer and marketing teams, at least until they get to the enterprise level, so only the sales team has ops. But the companies would want to avoid the mistake of simply calling their sales ops team 'RevOps' if they are not actually including marketing ops or CS ops activities.
When there are CS ops and marketing ops people hired, or a need to hire them, that's a good point to merge them into RevOps, before all the silos begin. I’ve noticed sales ops usually gets hired first for those 3 departments, as mentioned above. If you see that point where you have a one or a few sales ops people, but it is not enough people to keep up with demand, and they are being tasked to do things they can’t be successful at without someone on the marketing and CS side helping out, (related to renewals, demand gen, end-to-end reporting reaching into those areas...). That's a good time for starting RevOps.
Team structuring is something else the industry isn’t aligned on. It depends on the size of company, the stage of company, the product, the GTM strategy...
If you have enough people (it's not a team of one), have all these revenue-related team’s ops people report to one person who is not merely in charge of one revenue team, so possibly the COO or CEO. A CRO is a popular choice, but if your CRO is only in charge of sales, and that CRO doesn’t also lead marketing and CS teams or teams, that is not the best choice to lead RevOps since the work and goals will be biased towards the sales team's goals.
RevOps also needs to have a good relationship with accounting/finance. At some point, RevOps can cross the line into revenue intelligence, not ops (deep data dives and financial work such as compensation). This is all another debate, of course, about how much of finance and how much of data science belongs in RevOps.
What roles should you create and how do you fill them? Any advice for finding people to fill them?
For deciding on roles and hiring, a lot on depends on the size of company, stage of company, the product, the GTM strategy... What I can advise is: don’t hire just tool admins and no one else. It would be a mistake to hire people whose only role or skill is being your CRM admin, and not hire anyone else for your RevOps department. You'll need people with skills in strategy, you'll need process people, you'll need people who can align teams for leadership roles, and more. It's possible to find people with all these skills combined, but they are rare and likely to be expensive hires.
This is a tough question. It may be a million-dollar answer if you can find a solution of how to know someone you’re bringing in from outside the company would be the right kind of ops person for the role...if you've set up the right role for the work you need to be done.
Because ops and even RevOps is a very broad category, especially right now when no one can agree on what RevOps is. Figuring out how to test that someone has an ops mindset would be valuable when hiring. People can learn tools fairly easily, because there are a lot of resources for learning tools, but all the other part of ops are harder to learn and prove.
I’ve been involved in hiring ops-minded people for an ops agency and it is tough. Operations is still not a clear career path. Often no one knows they are an operations person until they've had business experience or exposure first in other roles. It's not offered at many business schools aside from supply chainmanagement. For hiring managers, it is tough to identify who is and is not an ops person by looking at a resume or talking to someone in an interview.
This certification you're making will help identify people with a willingness to learn more than just tool admin skills, which is great. Certifications or classes in project management and change management may be good indicators of a good ops hire, as well. I look forward to reading other respondents' answers for this question.
When a company is in startup mode, it will usually keep up with the growth of its customer base by increasing investments in staff. When that company is ready to scale, how can it support a growing customer base without simply hiring more employees and without letting the quality of the customer experience drop?
Don't just hire more sales reps making cold calls. Hiring or transitioning current staff to ops roles can make your current team more efficient and effective, so you won't need as many team members in order to bring in equal or more revenue as now, or to be able to manage more customers with your current team size. The revenue team you currently have will see better results if you add more operations roles.
That is, of course, if the RevOps person or team has the people skills, the human skills, needed to inspire change and make change happen all the way through the revenue teams, end-to-end,
You should also be investing in customer teams instead of hiring more salespeople at this point, to retain and upsell your current customers.
Why don't we hear more about customer service/success/support enablement? Enabling people to delight and retain customers? Why is most of the enablement focus for sales teams?
Giving customer teams more chances of being successful, training, having their processes documented and easy to find, making sure the tools are integrated, are all things that help teams to focus on the customer experience, which the customer teams probably have the most insight on.
One example of the benefit of using ops to help focus on the customer experience: Having every customer interaction documented in real time, where anyone on the team who interacts with the customer knows the history, so the customer doesn't need to repeat themselves or go through any steps they already took... using a CRM that gathers all the info that everyone can easily access.
Another example is making sure any automations that have been set up to deliver content, ads, etc. are all talking to each other so only relevant info is served to the customer. For example, so the website knows what steps the customer took previously, such as what form fields they already filled out.
If all teams are working out of the same main tool, that is also the tool where the website is built and hosted, where everything is integrated, it makes it simple to keep that customer experience at a high level across all teams.
As a possible interim step between startup and scaling, they could hire a RevOps agency to help get all systems and processes started, or documented or untangled. The agency could help get the current revenue teams accustomed to working together, which would make it easier to hire internal employees in RevOps.
As we discussed before, hiring a new employee in a new RevOps department sounds like an impossible weight for them to carry. They would be learning about the company while also learning about all the messes they need to solve, how everything connects, before they can even start making an action plan. An agency can help make an easier and faster path to hiring internal RevOps, then the agency can hand the new hires the map and the keys to the 'car' or revenue engine.
As a company grows, its tech stack tends to grow, too, with different teams adopting different tools. How can an ops professional manage that?
[This section was used in the final certification.]
As much as I say that in RevOps or ops, we talk or hear too much about tools and tech stack, that is actually my big project this month in my own roadmap. Finding and documenting all the tools everyone is using, or at least the ones we’re paying for. I've been diving into accounting to figure out historical costs and help set budgets per department, knowing which tools are annual contracts, which are monthly, which may we not want to renew, and more. I may set up a separate section of the document for the free tools people use. Discovering all those tools may be tricky, but looking at the company password manager could help.
HubSpot has a good platform audit worksheet that I started with, thanks, Kyle!
Besides the budgeting side of this, I'm creating visibility for the team so they know what tools they have access to. I'm creating an improved tool request process where the person requesting has to do the research and preset it to leadership since even our tiny ten-person company was getting a bit out-of-control with tools requests. Researching tools would be my full-time job if the people requesting tools didn't do the research themselves, and there is a lot of other work I do that helps the company and team in bigger and better ways (than tool research).
My first response to requests is always, if HubSpot or our project management system (our most important two tools) can already do what this new tool can do, it's going to be a tough negotiation to get that new tool approved. In addition, I've been creating a subscription canceling process when someone no longer needs a tool, and thinking about a quarterly review process to audit what we’re not using anymore.
That's a lot of rambling about what's I'm working on, but the short answer is:
Be good at saying no. Ops should be in charge of tool approval, if not also in charge of tool budgets, They should align with team leaders, finance, and IT on tech budgets. (At a small company, these may all be one leader such as the CEO.)
Do not let each team, 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 approval process.
Be good at referring people to your budgets, to your tech request/trial process, and to your roadmap for future tech improvements. Keep going back to that,
Having the tools documented, knowing what you have access to, can help you respond to a tools request like, 'Hey, the sales team is trialing a similar tool, why don’t you ask them how it’s going and let me know if you want to be added into that trial.'
For example, in the third quarter, we're going to look into a tool to improve sales enablement, but in the meantime we'll better use the tools we have already have, which team members may not have known can serve the same purpose.
For bigger companies, I have seen a few tools that help manage subscriptions, but it is not in the budget range for a company our size. It probably doesn’t make sense to pay for a tool that manages tools subscriptions, for a small company. I can see how it would be useful in a bigger company, though, judging by the amount of manual digging I’ve had to do into the accounting so far.
Related book research
Switching over to my research, one of the factors leading to the rise of RevOps is the explosion of technology that companies are using, and how easily accessible it is for different teams to purchase different applications that potentially overlap, conflict, and make a mess.
Tools are definitely NOT the most important part of RevOps, though. A lot of people interviewed agree that having specific software isn’t as important as your people and processes.
I did ask the question:
Do you think RevOps owns the tech stack?
Responses:
Yes: 22 people
No: 1 person
It depends: 11 people
A few of the responses talked about it being dependent on company size and stage, sometimes partnering with IT or engineering, budget considerations, time for fixing tech considerations, and more,
When a company is getting off the ground, it will tend to focus on a small number of high-impact channels. As that company seeks to scale, however, it will add new channels to its marketing mix and offer its customers more ways to get in touch. How can RevOps help manage those?
The short answer is to use a comprehensive tool like HubSpot for as much as possible, instead of a bunch of separate tools in silos that each do one thing, that don’t integrate or talk to each other. With Ops Hub, the integrations should be easier now when you do need to occasionally use a specialized tool for one department.
This isn’t a question I’ve personally had to solve or one I've phrased exactly this way in my research. A high-level answer would be to make sure all the tools talk to each other so the customer gets the best experience and also to make it easier for a small team to manage more channels from one platform.
The question sounds like it is related to some common RevOps projects of gaining end-to-end process visibility, data visibility for the whole customer journey.
When a company is small, it can move quickly. As it gets bigger, decision making slows down. Can RevOps help with that? How?
Yes, having one department instead of 3 departments in charge of making certain decisions could help make decisions faster, BUT you have to give RevOps decision-making power and respect their decisions or you won't receive this benefit. This is similar to the above answer about tools...having one department in charge of tools budgets makes approvals faster than approvals involving many departments,
The people side of RevOps includes building relationships with the teams needed to make decisions, which could include the revenue teams, leadership, finance, and IT. Decision making will be faster and have less friction if the relationships are well-maintained.
RevOps can help create, document, and streamline an approval process or decision-making process. The process can include certain tiers of urgency, so urgent decisions can be made faster, like a prioritization matrix or choose your own adventure style of conditional paths. This will ensure everyone knows their part to play, knows the urgency level of the decision, and knows the clear process of what happens next for any decision. This should speed things up when needed, or help people realize the times when speed isn’t needed.
RevOps can help decipher when a fast decision is actually needed and when it would be better to take the time to gather research, consult with the other teams in the company, and consult with other ops professionals on how they’ve solved the problem. Taking a week instead of a day to decide probably won’t make a difference for medium-sized decisions.
RevOps can help with those beginning change management steps, letting teams know you're considering a change, why, and when to possible expect the change. This will ensure the change is not a surprise, giving visibility to the factors involved, using the people side of RevOps.
Another part of RevOps is discipline, which could include the disclpline to not make decisions quickly when it is not needed. Sometimes seeing the biger picture first would be a better route to take, avoiding the shiny object syndrome of chasing after each new thing ('Let's buy a new tool right now! Our competition uses it so we need it today!' This is not a decision that needs to be decided in a day.)
I would also argue that slower decision making isn’t always bad, unless it a rare situation like a pandemic hits and we need to make a fast decision to pivot in the nest few days, or the company may not exist next week. That would be a good reason to make a fast decision, depending on your definition of fast.
Something else to consider is that in a small company, a founder CEO is probably making most of the decisions themselves and announcing the changes very quickly for the first year. Since no one else is in leadership, so no one else has visibility to the decision-making process and factors before the announcement, that constant abrupt change could cause a lot of chaos and stress for the team. It could cause the team to experience a lot of anxiety when huge changes are happening every month to team structure, who they’re hiring, what they’re selling, and so on. So 'moving quickly' isn't always a good thing and it can have negative long-term consequences on your team.
When a company is small, experimentation is constant. As you grow, how do you balance experimentation with standardization? What’s RevOps’s role in that?
Balancing experimentation and standardization once again is using the people side of RevOps such as change management.
It incldes creating processes for testing, standardizing the experimentation itself. Creating a way to track those experiments so you're not repeating the same mistakes, and you have documentation about why the experiment suceeded so you can replicate it in the future. At small companies you may have a completely different team next year, and if you don't document those experiments, then they may repeat the same mistakes or failed experiments simple since they didn't know what was already tested.
Creating some kind of change log and change process for starting experiments is also important. The key thing to do while experimenting is knowing when someone else is testing something, putting that info somewhere anyone can see it easily, such as a specific Slack channel where all teams can view it. This way, if another team member notices something strange going on, they can refer to this channel to see if it is a current experiment, or if something else is going wrong in their company.
This company-wide visiblity to anything currently in experimentation will help prevent or quickly fix uninteded upstream or downstream effects in other departments, when someone is testing something in a single department which they were unaware affected another department. The is another reason RevOps should be involved in experiments since their visibility and involvement spans multiple teams.
Once an experiment is successful and documented, RevOps should be creating criteria for it to move from a test to being adopted. The change process should extend all the way through change management, including implementing training on it or assisting training.
A good way to keep a small company aware of what's going on with other teams or team members is to use a shared project management system, where each team can view each other's current projects. I would say this may be even more important than a CRM to keep visiblity about what is happening in your company. The current tests would also be tasks or projects in the project management system and viewable across teams, to prevent duplication of efforts on different teams.
RevOps can help create a good experiment process that is not burdensome, to enable the teams to experiment in a controlled and easily documented way.
There is a similar balancing of continuous improvement with protecting the longevity or continued operations of company. You can’t change or improve something if you don't know where you are starting from, if the original state was never documented.
For another example, our agency has a “be prepared” motto, including creating backup plans for every employee where they create detailed instructions of every part of doing their job. Then anyone can jump in and take over if needed.
Related book research
From my book research, there is one related question:
In your opinion, do you consider change management as a responsibility of RevOps?
Responses:
Yes: about 26 people
No one said no, but there were these caveats:
- Depends on the organization, big organizations may have huge change initiatives instead
- Everyone should be doing it, not just RevOps
- For processes (bite-sized change) but systems should be IT or another department
- For certain things, but mostly for communicating insights to leaders and then leaders make the teams change
- Good for enablement and RevOps to partner on (when enablement doesn’t sit in RevOps)
- For GTM (go-to-market) things only
- Yes, but they need to partner with other leaders to make it happen
Thank you Kyle, Mary, and HubSpot Academy for creating this certification and including my thoughts!
Get the HubSpot Revenue Operations certification!
Enroll in the RevOps bootcamp from HubSpot Academy!
Learn more about my book and sign up for updates here.
Read an interview with Kyle about the making of the certification