Having been a RevOps manager for over a year now, I’ve been doing my best to engage with relevant content from various sources. One perspective I often come across from RevOps thought leaders is related to Reactive vs Proactive practices. To summarize:
With the Reactive approach, various departments need help and they come straight to you for it. Some examples include:
- Request to change sales proposal templates
- A department needs a report or a dashboard
- C-level needs a change in process
The Proactive regards the initiatives you want to implement to help the company grow revenue, which could be approached in different ways:
- Initiatives that can support company OKRs to hit their goals
- Areas you have uncovered that can be improved (based on data)
- Your own approach (idea/resource given later in the article)
Not having a process is fine and dandy for a while in a start-up. However, at some point, this is impractical because as you grow the company, more and more departments will ask for your help, and suddenly you are stuck with your reactive tasks and with no time to do your own initiatives that should be the main driver for revenue growth.
Suddenly you are stuck with your reactive tasks and with no time to do your own initiatives that should be the main driver for revenue growth.
So how did I solve it? As with any other challenges and opportunities, I made an effective process!
Here is what I created in Miro:
Reactive requests:
My biggest challenge was to prioritize and categorize all the requests I would receive. For example, with one company, we used Slack and Notion. I decided to let those be the channels for submitting requests and dealing with all reactive requests.
Then once you start getting the requests, it's time to start prioritizing and categorizing them. Since this was with a growing start-up with a relatively small team, I didn't want to overcomplicate things and so based it on the following factors:
- Feasibility (low, medium, high)
- impact (low, medium, high)
- Dependency (whom will I be collaborating with?)
Furthermore, I categorized them by topics and had an initial idea of when I’d like to work on these initiatives.
- Topic (Amazing customer experience, Frictionless sales experience, automation and insights, revenue forecasting,)
- Roadmap/timing (now, next later)
Based on the above, I then categorized them as either low, medium or high priority. In my case so far, anything below high priority won't be considered in the near future. I think as with any Revops department, no one has unlimited capacity.
I think as with any Revops department, no one has unlimited capacity.
Proactive requests:
Planning the proactive request and the most important initiatives might be based on how the company generally plans its initiatives. In my example company, we had an OKR model which we used to plan most of the RevOps initiatives. Should your company not use an OKR approach, I recommend using the flywheel motion to plan your initiatives.
Once you have a plan of the initiates you'd like to work on, it's time to work with your stakeholders to collect feedback and confirm. Once that is done, it's time for the hardest part: the execution.
The Benefits of this process:
- You’ll be on top of the things you need to work on, and you’ll also have something concrete to show your stakeholders when discussing RevOps work. It will also help you zoom out from time to time and evaluate if there are any initiatives missing that you think would be more beneficial for the company.
- ‘Trade offs’ is a big topic within RevOps. As mentioned earlier, no Revops department has unlimited capacity. So when your stakeholders bring you a new “very important, very urgent” thing (and trust me, they will come with a new one every month at a minimum!), you now have some leverage in that conversation to say, “I understand this is important but looking at my roadmap, I’m at maximum capacity. What current initiative would you like to postpone to make time for this one?”. This will change the conversation to be focused on prioritization and ultimately make sure that you work on the right initiatives for your current and future customers.
When to expand your team:
When getting the idea for this article, I realized there is a logical conclusion (for me at least). Once you experience a quarter where you aren't able to keep up with high priority reactive requests, and the main proactive requests are struggling to be finalized in a given quarter, it's time to expand the team to make sure you are on top of all the initiatives.
What do you think?
If you read this far, thank you very much for your time. I’ll be very curious to hear your thoughts and if you have any additional info you think I missed in this article?
Comments