Fireside Chat
//
May 5, 2020

Fireside Chat: The end to end Go-to-market Ops Framework

Dharmesh Sigh

Founder

Sales Strategy, Operations, and Enablement are too often viewed in silos.  Teams need to think in terms of capabilities that the go-to-market organization needs and be able to invest in capabilities based on the go-to-market strategy.

In this chat, we will share with you how we have created a framework for thinking holistically and how we would recommend teams to use this framework to build and evaluate their maturity across all capabilities.

Our hope is that having this framework will enable teams to prioritize investment areas after identifying the capabilities they need to invest in.

The End to end GTM ops Framework


Dharmesh: Hello everybody. Good morning from Seattle. Welcome Bala.

Bala: Thank you. Thank you again, it's a good thing that we like talking to each other other.

[1:08] How are end-to-end frameworks for sales being built?

Dharmesh: Last week we talked about the entire plan to execution, what it takes to close the plan-to-execution loop. Something you said that stuck with me was, generally, sales operations teams are drinking from a fire hose, right? They're always being reactive to the clear and present danger at that point in time. And we’ve seen this when we talk to people about stuff holistically and they say, “Yeah, all that sounds good, but really right now I have this problem I need to solve.” 

It's interesting to see how they think about these problems in silos and without seeing the connections. So it’d be good for us to talk about every aspect of building an end to end framework for sales operations. 

So little bit of a background for people who are new here: Please join us here every Tuesday if you want to talk to like-minded people. At Fullcast we have a platform that essentially is focused on closing out the plan-to-execution loop and really shortening it to make it Agile. 

[2:48] What is the capability model and why is it important?

Darmesh: Let's start with the capability model and why it is important. Do you want to share some thoughts on that?

Bala:  As you pointed out, when we approach these things in a siloed manner or when we approach them in a way that you're solving point problems -- clear and present danger, the next thing, the hottest thing in your email inbox for the day -- we tend to miss out on thinking about problems holistically. We mentioned this last week, but we left it hanging in terms of: what does it mean to think about it holistically? What is a good reference model that I can use to think about sales operations as a whole?

That's where the capability model comes in. I'm sure most people are familiar with capability models and capability maturity models. But the idea is to really focus on the reference model to look at to see how I am doing in relation to the capabilities that I should have and the things that I should be thinking about holistically. And how do I assess myself or my organization against that reference model, against that end-state view.

Dharmesh: I want us to define what the capability model is and its advantages. For example, when I walked into Salesforce we were building this entire capability model for all things that need to happen across our team, right? So, why did we take that approach? 


Bala: The capability model is a list, a structure, or a framework of capabilities, meaning abilities that you as an organization are going to need in order to be successful. If we were to have an ideal list of capabilities that a sales operations or revenue operations team would have, what would those things be? What are the areas that they need to be responsible for? What are the capabilities or abilities that that organization should have? How to assess how good you are with those abilities? 

So that's really what the capability model is there to do. Now, the assessment obviously has a framework around how to think about assessing yourself against an ability. Sometimes it's speed, sometimes it's agility, sometimes it's flexibility, right? There are various dimensions for assessing that ability, but the idea is to start with a holistic view -- all these things are interconnected. When you execute on a particular ability that's going to impact something else, you have to think how each of these capabilities impacts other abilities of your sales organization, as well as the operations team in a micro-sense. But in a broader sense, looking at the entire sales organization. 

[7:19] What are the core pillars of the capability model?

Dharmesh: Yeah, and my guidance is always that you’ve got to look at all things as being mutually exclusive, but collectively exhaustive. Looking at how the entire thing functions is a good lens. 

The core pillars of the capability model for a sales organization are design, rhythm, motion and enablement. Do you want to shed some light on this thinking?

Bala: Broadly, if we were to take all of the abilities that a sales operations team needs to have, we would break them down into these four buckets from a revenue ops or sales ops perspective. Those buckets are groupings of abilities that you need to have in an organization. So, clearly planning and building a plan, being able to put together a go-to-market plan is one set of capabilities that you would have. Tracking your performance to that plan, whether that be performance measurement of your sales cycles, the efficiency of your sales cycles, or your efficiency of your sales motion, you're constantly looking at how to reduce the effort to revenue. How much effort is being put to gain that dollar in revenue?  It encompasses the kinds of capabilities that an ops team needs to have. 

The other one is the day-to-day operational aspects of keeping your execution environment aligned to the plan. And what this means is all the moves -- there are changes that occur, territories, reorganizations, readjustments, re-carving of territories, people changing roles, new people coming into the business, people getting promoted -- all these things that you do in managing a sales team that has an impact on plan. The idea is that you're trying to keep all of these things in line with what you have laid out in terms of the execution plan. 

And the last bit is enablement, which really focuses on training productivity. How do you get people ramping up fast and knowing what to do in this complex, or both systems, as well as the sales motion itself or the revenue motion itself? How do you get people trained? How do you give them the right content at the right time in their job roles? Where do they find the process documents? Where do they find the collateral that they need to do their jobs? 

That's really the enablement infrastructure helping the sales teams and the revenue teams really achieve their maximum potential.  When we look broadly at sales operations, revenue operations teams, these are the four big buckets of capabilities that I think that each organization needs to have.


[10:22] Why are these pillars seen as distinct functions?

Dharmesh:  Typically, sales strategy in an organization is focused on the go-to-market planning side. And then tracking the performance and alignment to plan is all over the place in an organization. Enablement is always seen as the front end team. But they don't seem to be thought of as an integrated organism. Is that a trend? Why do we have those distinct functions?

Bala: Ultimately, there are two factors that drive this. One is the size of the organization, or scale, and the other factor is the skillset that's required. The skill sets needed for strategy are different than those needed for operational considerations, and it is a different skill set than enablement. As organizations scale, these functions tend to break off into sub teams within the rev ops teams to deal with that specialized topic. You also see that there are components that fall naturally into each of these teams. The trick is that they're all interconnected, which means that if you don't make sure that your revenue team understands what the strategy is, you're going to break down when you're executing. Even though they're all related, these are specialized skills. As the organization gets bigger you're going to see multiple people or even teams take on different pillars.

Dharmesh: I think for that very reason, with a capability lens, end-to-end is super important because as organizations grow larger the reporting structures change. The operations team could be reporting into IT, finance, or sales. Enablement generally is reporting to sales. Because organizational dynamics move in different directions we sometimes miss seeing all the trees in the forest.

Bala: That's right. Since these teams grow organically into these separate silos, the organization and reporting structures don't necessarily help in aligning them to think about revenue operations as a holistic problem. But I think more and more when you get to the idea of a revenue operations team, or a chief revenue officer that's in charge of all of your revenue motions, we're starting to see all of those things come together under a common leadership around revenue ops. I think that's a good thing in terms of aligning these various functions that may have grown apart to come back together. 

In my experience, an operational challenge is that there are a lot of practical decisions made in the field. For instance, a manager may agree to postdate a particular engagement with a sales rep and that information doesn't get communicated back to the sales ops teams. So there's discrepancies and commissions that are issued. And all these kinds of breakdowns are likely to happen if you don't have that common thinking process around looking at this holistically. So as organizations scale, we've also found that the majority of the problems occur when these things break off into their own buckets, if you will.

[15:19] Capabilities Model

Dharmesh: So, walk us through this colorful model.

Bala: We wanted to make this exciting, so we put it into a board game. If you want to get off to a good start at the beginning of the year, that all depends on your planning abilities. We cover a number of topics related to planning and all of these need to be an integrated, common plan. Whether you're thinking about your business unit, the go-to-market goals of your product teams, sales teams, and your channel, how do these things align to match up to your company goal? And how do you put that together? 

So all of these things have to interconnect with each other. The idea of integrated planning is that you get a go-to-market plan that you can start teams on at the beginning of the year in a transparent way, and in a way that can be deployed into the day-to-day systems that our salespeople, our customer success people are using right now, if we don't do this right, you end up in jail as a sales job. This is a sales strategy jail. 

Dharmesh: You get caught up in sales ops hell.

Bala: That's right, when you get off to your start and you have a bad plan you're going to find out very quickly, as soon as you release the plan to your revenue teams, they're going to be coming at you going, “Hey, this doesn't make sense.” All the way down to practical issues like, “hey, this account is no longer here”, or, “the industry on this account is incorrect because they don’t do this”. There are all kinds of things that come at you when you deploy a plan because everyone's getting in there and taking their first look at what you came up with. Being responsive to that is important as a sales organization and your ability to adjust and address those immediate problems out of the gate is also a key capability. I remember we used to specifically staff up for the initial three months after a new plan goes live because there's all this stuff that comes up and you cannot avoid it; everything from data quality to transparency of the plan. 

[18:21] Figuring out what is (and isn’t) working and responding to changes

 Bala: And then the next step in the process is figuring out how you're going to measure when all the things that you've done are working well or not. You want to build a very tight feedback loop to be constantly comparing against. A simple thing is one of the biggest reasons why sales teams don't meet their sales goals is they don't hire in time. You wouldn't think that would be the problem. Usually, people are quick to blame it on the salespeople themselves -- they don't know what they're selling, or they're not working hard or whatever -- but usually the biggest factor that influences whether you are going to meet your number is whether you are hiring in time to put people in roles that can be productive. That is the number one thing that you would start to look at when you put the new goal in place. For example, we said we were going to hire 10 reps in the first quarter. Did we do that right? And if we didn't do that, then there will be a knock-down effect in the subsequent quarters.

Or the assumptions that you made in plan, like your ramp assumptions, are they holding up? You may have put in certain deal size assumptions and certain churn assumptions that may or may not be holding. And if they're not holding, what does that mean to the plan? What does that mean to our ability to make the numbers? So that feedback loop, establishing that upfront and doing that in a consistent way, year after year, is the most important thing. Otherwise, what I've seen very often across revenue teams is that they would look at the plan at the beginning of the quarter and then they get buried in day-to-day operational problems. Then a QBR comes along and the sales manager wants to know how they are doing against the plan and then somebody has to go look at all the metrics and it's this weeks-long process of pulling data and massaging it. Well, that's not very productive and it doesn't give you a tighter feedback loop. Establishing the capability to be able to measure your plan quickly is key. 

You’ll see that it's not just about hiring people. It's also making them productive. Being able to measure performance is a key aspect of making a plan go live and be able to know that you're succeeding.

And the third aspect of this is your moves and changes, or all the things that impact the sales organization at runtime. Things that you do and don’t plan for, reorganizations, figuring out that a particular experiment that you worked on is not working… those are changes that you want to make to your plan to make sure that you stay on target. Having the ability to respond to those changes is an integral part of making sure that you have an agile sales revenue operations team.


[22:05] Enablement: Creating and measuring a productive team

Enablement really focuses on getting people productive, making sure that they're ramped up quickly and that they have tools at their disposal so they're not wasting time looking for materials or searching for things. You would set up things like a deal desk and RFP teams, things that speed up the sales motion so that people are not wasting time trying to wrangle resources internally. You want to make sure that those resources are given to them at the opportune time so that they can be focused on the selling process rather than searching for a case study or things like that.

Training people on the go-to-market model and on the strategy is another key aspect of any enablement. When you deploy a plan, transparency of that plan in terms of what everybody is going after is super important to make sure that's communicated to the rest of the organization. There's the enablement function is the one that does that and the capabilities there are an important aspect of making sure that the resources are being productive. These are the four pillars, as we talked about earlier. Sometimes these things are run by different organizations within the revenue ops team. Sometimes they report up into different hierarchies in the sales versus finance versus sales ops reporting structure, but ultimately these are what we believe are the four big buckets of capabilities that are important to make sure you have a successful revenue ops team.

Dharmesh: Have you seen a lot of times a sales operations team that is driving the pipeline analysis? Is there a hardline or is it the best practice?

 Bala: The way I would think about it is all of these are interconnected, which means that you can't really have an effective enablement plan if you can't measure performance and where things are working. In organizations where you have a person in charge of enablement and a person in charge of ops, these two folks would have to work very closely with each other to measure how the sales reps or the customer success reps are doing in terms of the efficiency of that motion. Where things are working, where things are failing, which deals are we winning, which deals are we losing, which competitors are we winning against, which competitors are we consistently losing against? 

That becomes a self-improvement plan in terms of enablement to be constantly looking at metrics that are supported by the set of capabilities opposite to that. But really driving the behavior of the sales organization and micro-changes in the sales motion to be successful in what feedback you're getting from the market.

That's why the win-loss analysis pipeline forecasting, these are things that you’ve got to pay attention to and train the sales and revenue teams on to have a focus on how to do it better. How much time should I spend prospecting versus working on late-stage deals? That's an important aspect of the strategy, but it's also a very important aspect of managing the behavior of the salespeople.

Dharmesh: We've seen people resort to industry benchmarks without actually taking a hard look at their own data. Win-loss analysis is really important because I think most companies end up doing a loss analysis, but not a win analysis. That directly contributes to what happens in enablement and what's done in boot camps and sales as collateral. 

Bala: The whole mantra of sales enablement is do what you're doing well. Do more of it. And do less of what you're not doing well at. Being able to understand that from measurements and typically you work with the team to establish the key set of KPIs you're looking for and driving the training, the enablement of the organization is to follow.

[27:29] What are good candidates for automation?

Dharmesh: So let me ask you this-- and this is not tied to the capability lens-- what are the aspects that you think are good candidates for automation versus where we really need human intelligence?

Bala:  What we have to look at with automation is the agility that's needed by the operations team. If it is a particular ability that doesn't require agility, then you probably wouldn't spend too much time automating it. As an organization scales, really you're asking how can I be agile? How can I be responsive to what the market conditions look like? I think that's the lens to look at from an investment standpoint. Really, you want to drive towards agility. I believe that for each of the buckets that we have listed, there is possible automation to make you more agile. 

The flip side of the coin is that if you automate point solution by point solution, if you try to tackle this in a silo, what you end up with is a whole bunch of tools that don't work with each other, which is counterproductive to being agile. It's important to think about it that way; automation, purely from an automation perspective, is going to drive a lot of ROI for you in terms of capability. You have to look at where you need agility and how to invest in it? When I'm investing in it, I have to look at the problem holistically.

Point solutioning will kill you in terms of agility. I remember talking to one of our prospects who said they are currently going through a three-month process to change a field in Salesforce because they have this reporting solution that depends on it. And to make updates to all these systems to take on a new field now means that it takes about three months for IT to go and configure all this. So what was a simple request just snowballs into this massive IT effort and that’s what ruins agility.

What I've noticed with sales operations is that nobody likes CRM. If the CRM is a burden to sales guys, they're going to shove some data in there for you. It's not going to be useful, but the reality is not going to be in your CRM. People are going to keep separate spreadsheets and they're going to manage their business. They're not going to stop making money just because IT hasn't given you the changes that you need. They're going to find alternatives and the data in your CRM will be bad. When you use that for planning, you make bad decisions, so it's important to make sure that the cycle works. And if you're not agile enough, people will go outside of all the areas where you're collecting data to make decisions, and they'll drive their own business

These are people's livelihoods at risk-- they are not going to wait for IT teams. So they're going to focus on what they can do to get the job done. That is the risk that you run of an organization that's not agile: people are going to go outside the system to do what they do and the reality of your sales organization will not be in your system. And what you're having is basically all the deals stuck at $999,000, because 1 million triggers a big deal review. So  that's the key, when the sales teams don't see the ops teams as a competitive advantage to them and if they see that as a stumbling block to get to what they need, they're going to simply go around it and that doesn't help anybody at the end of the day. 


[32:42] Prioritizing which capabilities to improve

Dharmesh: Every organization is different, so it's not that you can take this entire thing and use it to do everything because you really can't. So how do you prioritize which capabilities to work on? Do you want to walk us through this framework?


Bala: It's a maturity process. You cannot automate something that you cannot repeat. If your process or your decision-making is chaotic or ad hoc, if you haven't established a repeatable approach or strategy around it, then you can’t automate it.  It's important that before you get to the point of automating something that you think through the way you can systematize this? What is the way in which we can repeat something over and over? Then comes the aspect of understanding the impact of that on your organization. For instance, if you have a task that doesn't take a lot of time for somebody to do but you have a lot of those activities that you're doing all the time, the aggregate is keeping you away from high value work.

These may be simple things that slowly add up and you look at your organization and you go, well, where would I like to focus my energy versus what am I spending most of my time on. And that's going to give you a good sense of what are the opportunities for automation and things you can systematize? More often than not, everybody's starting from a blank sheet of paper and there is a lot of commonality in a lot of these tasks. 

One of the key things that we learned in sales operations through many years is that there are two aspects to any sort of repeatable tasks that a sales ops team is doing. One is the workflow itself, what you do first, next, and after that. That  workflow and then there is a whole series of things that feed into that workflow based on your go-to-market strategy. What I mean by that is the workflow around issuing a holdout is fairly similar, but what amount you apply to the holdout or how many days you apply to the holdout may be based on your go-to-market model, on the industry, on some aspect of your go-to-market model. Routing a particular lead to somebody, the workflow is the same, but who you route it to, what process you use to route it… all of that will depend on your go-to-market model.

What tends to happen is when you think about automation, you clump these two together, and you write some Apex code that contains all of this, both the go-to-market aspects of parameters. And the actual workflow merged in together into one piece of code that you deploy, which means every time you change your go-to-market model, you've got to go and rewrite the code. This relation between the parameters that come from your go-to-market model and the actual automation needs to be made. When we think about automation, that's also one of the other key lenses to look at is can we repeat the workflow as many times as we want, but the go-to-market model may change or may vary based on what our strategy is this year versus next year.  Then how do you implement with this scale to happen.


[37:02] GrowthOps Maturity Model

Dharmesh: The outcome of all this will be a GrowthOps Maturity Model which companies can then benchmark themselves and should give you a lens for how to think about your desired end state. Most of the time, we've seen people either in the chaotic or defined state. Very few are heading towards being optimized and agile. Any thoughts on this?

Bala: Yes, the key idea behind this maturity model is that you have to define something as being repeatable before you can optimize it and then drive agility in that process. Let's assume you have a holdout process, which is the time given to a rep moving off of an account to close the open deals that they have before the deal is transitioned to a new person. For example, if I'm working a territory and I'm getting re-orged into a different territory then do I get to close the deals that I was working on? How many deals do I get to close out on and how long do I have to close them? That’s the concept of holdout.  

Let’s say, today, if I don't issue holdouts at all and I'm making ad hoc decisions at the field level where the manager says you can hold onto this one deal but give the others to somebody else. And if arbitrarily you're making those decisions, you don't have a repeatable process. You don't have something that can be automated. 

Most organizations start there when they're growing, and then you get to a state where now you have a defined process for how to issue holdouts, for example: mid-market gets this much, in SMB gets this much, and enterprise gets this much. You start to establish policies.

The first step in establishing policies is to write it down and send it to everybody, saying “make sure you follow this”.  More often than not, those documents never get read, so you have to institutionalize that in your systems because that becomes easier for people to follow. When you write a policy, you're helping define the processes into something that's repeatable. When it's repeatable, you can look at how fast or quick or agile or whatever and say, what does it take for it to be optimized? Then you would think about how fast you are doing something and how efficient it is from start to finish.

You look at your operational motions and say when you need to go check the ramp and find it's a six week process. And that's too much time; we can't afford to take that much time. So you would analyze it from those angles to define what optimized means. It varies by the area of topic you're looking at, but ultimately what we're all driving towards is the holy grail of being agile. And what this means is if I get a request in, I can deliver that with the least amount of resource implications and on time so that they can make decisions out in the field. So that's the agility that you're driving towards and the agility of the operational process.

For example, it takes so long to get a discounting process approved. The discounting process is ad hoc. What do we need to do to make sure that it's repeatable? Your split policies are ad hoc. How do we turn that into a policy so that it can be repeated and automated? From the maturity model standpoint we will take each capability and then ask: 

  • Are my processes chaotic? 
  • Can they be defined and optimized? 
  • What is the angle that I'm going to look at to be optimized? 
  • What does it take for this capability to be agile? 


[42:19] How to get an organization to adopt a capability lens approach

Dharmesh: How do you sell the lens of taking a capability lens approach internally to an organization?

Bala:  As a team, you're always justifying the automation that you want. It's important whether you have prebuilt software out there that can drive that agility for you, or it's custom coding that you have to do, bringing in a bunch of consultants and building something. Whatever your approach is to automation, you are looking at the total cost of ownership of the solution. More often than not, we are very simply driven by finding a product in the market that says it can fix it. I'm just going to go buy that product and use it. What you're not considering is the total cost of ownership in terms of maintenance; in terms of its impact for you to be agile. How much time effort does it take to administer it, to manage it, and who’s going to manage it. Who's going to maintain the data in these systems?

So that total cost lens has to be applied and to justify it, you can look at how much time and effort and the opportunity cost of not delivering that capability on time is. What does it mean when a sales rep joins the organization and they don't have their territory for two months?

Dharmesh: That’s huge. In lot of companies out there where quotas start or a rep comes in and they're still waiting to give them quotas and territories.

Bala: That's the opportunity cost of not getting that person off the ground is 45 days of selling. And ultimately you want to say, how does this capability that I'm requesting to be automated actually impact our selling efficiency, our top line number. In most cases you want to find that direct link between what you're doing and that top line number. Otherwise I would question why you're automating it because sometimes we can just automate for the sake of automating. It makes the process easy on the ops side, but it doesn't necessarily help the sales team achieve more efficiency. As ops teams, it's always very easy for us to optimize for our efficiency and not the effectiveness of the sales team.

If you optimize for your efficiency, you cut down all possible ways in which changes can happen. You would say, here's the streamlined process. Know you're not allowed to make this change, Mr. Manager in the field, because that adds more work for us. If you take the lens of optimizing the process for the ops organization, you end up impacting the agility of the sales organization to respond to field conditions. That is something as ops people, we have to keep in mind; automation shouldn't be about making ourselves more effective as an ops team. It should be about making the sales team more effective to deliver. That angle is always super important because I've seen so many ops teams basically say that once a territory is given to you, you can't make any changes. It doesn't matter that you have bad data in there, you can't make any changes to territory. That flexibility in the field, you have to look at it as a competitive advantage to your team, an important tool to consider.

Dharmesh: Thank you; we are at time. Hopefully this was a valuable conversation. 

Next week I have Raj from the Alexander Group coming on and they will be talking about what it takes to optimize a go-to-market strategy in the current environment. Well, thank you everybody. We will end the broadcast from here and if there's any questions or feedback or topics that you need please shoot them our way. 



Is your RevOps team using Salesforce to its fullest potential? 

Download the exclusive ebook to learn actionable Salesforce best practices through the entire customer pipeline.

Get Your Free eBook
Salesforce best practices ebook image

Related resources

View More

Keep Your Room Clean

As a father of two teenage kids, I could not help but compare the average teenager to a fast-growing company’s CRM...

View More

eBook: Salesforce Best Practices Through the Customer Pipeline

We know Salesforce inside and out (better than some of their own team, so we've been told...)

View More

Growth Ops Summit: Breaking the 24 Month VP of Sales Lifecycle , Ted Wang

Many organizations are caught in an endless cycle of sales leadership churn that results from unrealistic sales plan sett...

View More