I remember when I started my career.
We were managing complex business processes and reporting in spreadsheets and email - Email!
I know, wild.
Today, there are hundreds of tools you can incorporate into your go-to-market tech stack to support your teams. For those of us in revenue operations, we might be saying FINALLY, the market cares about us.
Because with all of these cool new sales, marketing, and customer success tools, there is a revenue operations practitioner who has identified a new tool that fills a gap in a process.
We can't deny the importance of a well-designed technology ecosystem. The core systems CRMs, MAPs, and SEPs can be augmented with other tools available on the market to enable the revenue-generating GTM teams to do what they do best -- bring in more revenue!
But with so many choices, what is the best way to choose?
Did you know there are over 150 (yes, 150) sales tools in existence today? Developing a framework for evaluating new tools is the key to implementing a technology ecosystem that is scalable, sustainable, and supports your revenue teams and their processes.
It's also the key to keeping your sanity as an operations professional.
So how exactly are you going to know when, if, and should you bring a new tool to your organization?
You need a framework as part of your revenue operations practice for evaluating existing technology in your organization and how any new technologies you are considering will fit into your stack.
Whatever the case is, the first step to tool evaluation is a business process evaluation. This means, if you don't have your buyer/customer journey mapped in a flowchart format, do that.
You can start with a Google Sheet or Doc and list all of the processes in your GTM organization.
As an overly simplified example you can use a written sheet as a starting point, then move to a diagram with swimlanes.
The way I describe this exercise to others is by designing your revenue operations as a cake. The first layer is the customer journey, the second layer is your business process, the third layer is the systems/tools in place to support the first two layers.
And the icing on the top is the training and enablement.
You can't put a third layer on (aka the systems layer) without the first two layers for support or you'd have a really sad dessert.
Processology describes, "a business process is defined as a collection of business tasks and activities that when performed by people or systems in a structured course, produce an outcome that contributes to the business goals."
Anything that can be defined as a collection of tasks for your GTM team should be documented and defined.
An example of a GTM business process would be lead routing and assignment.
Another example of a process would be your sales motion; what are the steps for inbound sales versus outbound sales?To shake things up even more, there are external GTM processes and internal GTM processes, and both are important when deciding on tools.
This mapping process may feel painful if you aren't used to the exercise. However, it is critical to tool evaluation. You may be lucky and choose a tool first and it might happen to support your processes. But more often than not, you're stuck trying to make your process fit the tool and not the other way around.
Documentation is key to the process whether we like it or not.
Download the 50+ Lessons From Today's Revenue Leaders to learn from amazing Revenue rockstars like Asia.
Brought to you by RevOps and HubSpot.
The second step in the framework is to do a little research!
There is a reason it's called market research lite. The purpose of research is not to write a dissertation. It's to gather a bit more knowledge about the tool or potential tools you may bring into your organization.
If you already follow the market, this part should be significantly more fun and quick.
Online communities have their own slack channels dedicated to tools and software questions, these can be some of the best places to ask questions about use cases and experiences with the product.
Sites like G2 and Capterra - the Yelp of the software world - also provide information to help you in your decision.
The third step in the framework is a cost-benefit analysis. Yawn - boring, I know.
But this part is necessary if you want (or need) buy-in from others, particularly executive teams.
Harvard school of business cost-benefit analysis as, "the process of comparing the projected or estimated costs and benefits (or opportunities) associated with a project decision to determine whether it makes sense from a business perspective."
It makes sense, right? But what does that mean for your organization?
Remember the exercise you did in step one? It will come in handy here, especially as you start to present your benefits or opportunities for this analysis. There are plenty of places to actually document this analysis, but to be tool-agnostic, you've got to get the components down.
First, identify the current state vs. the future state. This should include the particular business processes, tools, number of people using the tool, integrations, and cost.
You'll want to add your costs side by side for each tool, so it's easy for others to see at a glance how it will stack up.
Other things to consider at this point are: Is this a new tool or a replacement? Is there a cost associated with the implementation of the tool? How long will it take to implement the tool? How will the tool positively or negatively impact the downstream or upstream teams?
The fun part is here!
You finally get to make your recommendation. You'll know now if the tool is worth the investment (whether it's time or money or both), and you'll have a framework and process to use when you evaluate future tech stack changes.
The amount of technology available to go-to-market teams is unbelievable.
It seems like there is a tool for everything; nearly all promise to increase the capacity of your GTM teams to bring in more revenue.
But it's important to remember that the core and foundation of your GTM operation are the processes these tools are supposed to support.
You have to walk through your evaluation framework, starting with a business process evaluation, market research, cost-benefit analysis, and your recommendation.
You may save your organization some money, but most importantly, you'll save your organization from headaches because your systems will be built to support your business processes, not the other way around.
