Rethinking Sales Compensation for a Consumption-Based GTM with MongoDB

Just give a second to let people come in. Welcome, welcome to this week's iteration of Workshop Wednesday. Thank you all so much for joining us again. So welcome back, or welcome if this is your first time. Thrilled to have you back here for our Workshop Wednesday. We are here every Wednesday at 10:00 AM Pacific, week after week, to share detailed, interactive, and hands-on workshops with some of our favorite speakers. So we bring the SAS expert to walk us through some content. And then we love to kick it off with an interactive discussion and make sure that you get your questions answered. So you will have this, the opportunity to interact with our speaker today directly. So make sure to get your questions ready. This week we have Megan Gill. She's the SVP of Sales Ops and Sales Development at MongoDB. She did a super popular workshop for us at SaaStr Annual this year. So we're excited to have her back so we can leverage some of her sales ops expertise and bring it to our global community. So today Megan's gonna walk us through how to rethink sales comp For a consumption-based go-to-market, very timely as we wrap up the year, and I'm sure a lot of teams are looking at 2024 planning and kind of new structures, processes, and ideas. It's also great as you look at your onboarding, and I know Megan is hiring, so she's going to tell us a little bit more about that. Like I mentioned, we aim to keep these sessions as interactive as possible, so we want to make sure you get your questions answered. Feel free to come off mute to ask your questions yourselves or drop them into the chat, and I am happy to facilitate Q&A after Megan runs through her slides. So like I mentioned, if you are comfortable, come off video, we'd love to see you and make this a little bit more interactive. Megan, welcome. Thank you so much for joining us.

Thank you so much for having me.

All right, our little favorite, we'd love to get to know you a little bit more and ask you some questions before you're put in the hot seat. So just to get started, how would you define or just tell us a little bit more about your day-to-day role at Mongo?

Sure. I mean, I think my day-to-day is pretty simple running sales operations. My job is all about making sales more productive. And that might be through segmenting the sales force. It might be through territory management. It might be through the right incentives, which is what we're going to talk about today. But it's all about optimizing the sales force.

Great. And a big job. In the last 12 months, what's been the hardest thing you've worked on?

Well, we're going to talk a bit about it today. But you know, MongoDB, I've been at the company for a long time, coming up on 14 years. So as you can imagine, I joined when I was 9 years old. And when I was 9 years old, we weren't selling a SaaS product. We were actually selling an on-prem database product. And then in 2016, we introduced Atlas, which is our cloud-based product. And over the past few years, we've moved from selling sort of a— going with a traditional sort of SaaS model to a consumption all-in, a pure consumption model. And so that has been a really challenging but very, very fun transition to make because there aren't many companies who've done that sort of transition. Consumption is still relatively new. So for a sales ops person, you know, I found it really interesting to be sort of a bit of a pioneer in the space.

Great. And I think that rolls into our next question of just what project are you working on today that you're most excited about?

I think most of the projects we're working on now are all about how do we operationalize being a consumption and a, what we call a workload-oriented business. Meaning that the way we think about our business is if you have a customer who's consuming MongoDB, our cloud-based product, that we're trying to drive the sales reps to close what we call workloads that will uptick the consumption. So we've completely reoriented all of our tools and our systems to be this workload-centric, consumption-oriented approach. And I think the thing I'm most excited about is taking some of the things that we've built in spreadsheets and really implementing them in some of the SaaS tools that we're using. And like, for example, Clary, and operationalizing, for example, how we forecast. So those, those are the things I think I'm most excited about.

That's great. Kind of off that, sounds like you have a lot of tools that you're working on that have been helpful. But what's your current favorite SaaS tool or platform?

So I think the tools I'm most excited about are the ones we've actually built in-house. So we're a data company. So for example, we built a tool, an internal tool called Argos, which I've done some talks in the past about how we do territory planning. And so we've actually built an internal tool to bring together data points from our product, from external vendors, from LinkedIn, from marketing, and help the sales leaders prioritize accounts. So I think that that's probably my favorite SaaS tool since we went and built it. The other, my other favorite tool is a tool we just rolled out, which is a tool we call internally Coach GTM. It's sort of like a, it's basically a chatbot that using AI to answer sales reps' questions about our product, our policies. And that's been a way for us to get more productivity out of the reps, but also more productivity out of ops so that we're not answering the same questions. We're not enabling the team over and over again on the same topics. They can just ask Coach GTM. So those are, I think, the two very cool tools that we've built internally.

Awesome. And I'm sure we'll hear more tools that everyone else can leverage too throughout your presentation. So without further ado, take it away. Love to— can't wait to see what you have in store for us.

All right. Awesome. So I think I already introduced myself. So I've been at MongoDB for, it'll be 14 years in December. So again, joined when I was 9 years old. Most of that, the first half of that run was in marketing. And then the past 6 or 7 years has been in sales operations. I've also have sales development under my umbrella. On a personal level, I've got 3 little kids. They're all hyped up on candy from Halloween being yesterday. But it's a lot of fun. On being a sales leader and a mom. My two are two awesome jobs. But what I'm here to talk to you today about is consumption-based business. And I guess before I talk about, you know, what consumption means and start talking specifically about compensation plans and incentives, I like to start any conversation about comp with a little story. Which is the story of this village that had a problem with cobras. And they had too many cobras. They were a menace to all the folks in the village. And so the mayor said, look, you know, we need help getting this cobra issue contained. So we're going to pay a dollar for every person that brings me a dead cobra, every killed cobra. And so they put that in place. And What ended up happening is people started breeding cobras and killing them in order to earn their bounty for the cobras. So why do I tell this story? I just think it's a fun way to— obviously, it's a, you know, a fable, compensation fable, just to be thinking about, hey, whatever behavior you want to drive, compensation will drive that behavior. And it can often have unexpected results. So really, always when you're thinking about comp, I always come back over and over again What is the behavior we wanna drive? What is the behavior we wanna drive? So you'll hear that theme throughout that. So before we speak specifically about compensation and thinking about compensation, like what the heck do we mean by a consumption-based business? So this has sort of been the evolution of software over the past, you know, however many years. If you think back to the old days, you have company, a company like Oracle that really popularized the perpetual license. So that's where the customer really owns the software. And the vendor really owns the market. They have all the information. The, the pricing is complex. You're talking about doing large upfront deals where you're locking in a customer. Then we moved to a much more customer-friendly model with SaaS, which is subscription-based pricing that Salesforce really popularized. And the idea is here you're renting the software. You're doing an annual renewal. It's much more customer-friendly, customer-driven. But it's still— there is still some complexities around SaaS-based approaches. A lot of times the pricing is complex. And the customer really has to commit oftentimes many years in advance. What's evolved over the past several years and really being driven by the hyperscalers like Google, Azure, AWS, but as well as some of the more innovative companies like Twilio or Stripe, is this idea of a consumption-based model. And this is really a very customer-oriented approach where you're paying for what you use. You get billed in arrears for, for your consumption. And the closing of a deal is really just the start of the journey. So if you think about how we've reoriented our sales team, we actually don't— we actually have disincentivized reps from making commitments upfront because we found that that was creating friction in the sales cycle. And what we really wanted was for customers just to get up and running on our software, start to see value, and take that time back from negotiating to focus on getting them successful with that first workload so that we could then go upsell future workloads. So that's really the idea behind a consumption-based business. This is a quote from Ben Chambers. If you're thinking about consumption-based comp. He actually consults on consumption-based comp, so I recommend checking out his content. But, you know, for customers, the benefit of doing business with vendors that offer a usage-based pricing model are clear. Use the products what you want, when you want them, and be billed when you do. So very sort of straight, straightforward in terms of what the value is for the customer. Of course, that then puts more onus on us as the vendor to constantly be delivering value. It's It's not like in the old world where you can sell a big deal and walk away. You know, you're, you're, you always have to remain engaged with the customer. And this is why we're seeing usage-based companies everywhere. So I mentioned, this is actually, I, I snagged this from OpenView, which has, it's a VC firm and they have a pretty amazing set of content on usage-based companies. And you can see there's usage-based stuff everywhere. We talked about the hyperscalers. Obviously, MongoDB is in the infrastructure category. I mentioned Stripe and Twilio, but you've really got all, all different kinds of companies that are taking this usage-based approach. And taking a usage-based approach, it's more than just changing your compensation. It actually turns your whole go-to-market on its head. So this is a quote from the VP of sales strategy over at Snowflake, who has been, you know, very sort of well known for taking this approach. And this is not a secret. This comes from one of their public blog posts talking about the approach that they've taken, but they actually don't have a customer success org. They're saying that their sales reps are playing that role. So they've completely changed how they think about what the role of a sales rep is within a consumption-oriented company. Now, I will say MongoDB, we took a different approach. We do have a customer success organization. I can talk a little bit about maybe the, the differences that came up when I spoke at SaaStr. But again, going back to the original story, compensation drives behavior. So before you start saying, how should I incentivize the sales team? I think the first thing you need to think about is with a consumption-oriented approach, who's doing what? Are your sales reps actually playing the role of customer success? Is that your strategy? If so, that's gonna be a very different approach than say having a, taking the model that MongoDB does where we have a partnership between sales and CSM. The other thing before we go into all the different ways that you can incentivize is really thinking about being able to measure sales impact. And this is something we put a lot of work into internally at MongoDB. And we've actually built into the product. We really wanted to try to differentiate the organic consumption versus the growth being driven by sales. In other words, their customers may be growing because their application is growing. So for, for example, maybe a sales rep 2 years ago landed a workload or an application within the customer account, and that's happily growing, and that's great. But we don't necessarily want to focus the rep on maintaining that existing app. What we want them to do is go out and find new workloads, new app, work applications that are going to, you know, meaningfully uptick the consumption. So we built within our product a way for us to sort of separate out what's organic and what's new. And that's been a real partnership with the product team to get to that point. The other thing that we do, and this is more relevant for us given that we also have a self-serve channel, is we actually run a control group, which means we have a subset of accounts that no one touches. And that control group helps us understand what, what happens when we don't have anybody touching those accounts. What growth should we expect and what incremental uplift are we getting from having sales involved in these accounts? Now, of course, in that control group, you may have customers that hand raise and then you direct them to sales. That's normal. That's gonna happen. But the idea is to always have a way for us to compare and understand where are we getting the, the incremental value for sales so we can continue to make better investment decisions. So I mentioned, you know, comp drives behavior, obviously. And one of the other important philosophical, my important philosophical points of view on comp is that you really want to compensate reps on what they can control. It's very frustrating as a sales rep to be compensated on something where you don't feel like you, you can really move the needle. And that's one of the challenges when it comes to a consumption-oriented product, which is that customers can fluctuate. And sometimes that's because of the sales rep's involvement, and sometimes it's just because of the macroeconomic conditions. And I'll use an example. So this is the, the I mean, this is all like a, a made-up usage curve, but imagine that we have a large crypto company as a customer on MongoDB's platform. You can imagine that during the past several years, there was a huge uptick as the crypto market was booming. And everybody's high-fiving and everybody's like patting the rep on the back for having an amazing year. But then what happens is that, you know, crypto market's not doing as well and that consumption starts to, to tick down. And we're taking a lot of churn on that customer. And is that really the rep's fault, or is that more a function of what's going on in the macro environment? So it is one of the things that's quite challenging to think through when you move to a consumption, a consumption-based model. And I'll talk about a few different ways that you can potentially address that. So incentives drive behavior, start with the behavior. That's a mantra for my CEO, and I've already mentioned it 2 or 3 times. And so the way I would start thinking about how to design a com plan would be obviously with what are the behaviors you want to drive? And I came up with a few different flavors and different approaches, and I'll come into more, a little bit more detail on, in examples. So what behaviors do you want to drive? So first, maybe the behavior you want to drive is market acquisition. So you just want to get, land as many new logos as possible. And actually this is a, an approach that we've taken at the beginning of our fiscal year. We actually segmented between acquisition and growth. So we have a dedicated new logo team. That new logo team lands deals that they pass to an expansion team. And rather than compensating those reps on, on ARR, and we've iterated on this over time, we actually compensate them on a combination of a unit-based metric. So a volume-based metric, like the number of new logos that they're landing. As well as a, a quality metric, which is the ARR that they're driving. And so this is the, the basic example. So you could have a very dead simple comp plan, right? The target's the number of new logos. You get a flat bounty for every new logo you could acquire. And in fact, this is a model we've extended beyond our acquisition team into our growth, our expansion team. So I think somebody had asked about how do you incentivize this acquisition of new workloads. On our growth team, we have, they have two elements. One is the ARR, the overall ARR, and the other is the, on a unit basis, the number of new workloads that they're landing of a certain, a certain quality. So they have to get it to a certain run rate. And that basically says, hey, a certain part of your ARR target is gonna be coming from that organic growth that we know is coming anyway. But for, in order for you to really overachieve, you have to land a certain number of new workloads because a big chunk of your variable is tied to that. And also we have a gate on accelerators that says you can't hit your accelerators unless you're landing a certain number of new workloads. So unless you're constantly pipe generating, measuring on a unit basis has some really good pros and cons. So one is, is dead simple. It really focuses the reps and it will drive a lot of velocity and activity. The con is, is that it's always harder to overachieve on a unit-based plan, which is why it's potentially good to have a blend to mix the elements between ARR and something unit-based. And when you have a unit-based plan, you always run into the risk of driving a lot of low-quality stuff. So when we first introduced our new logo team, it was a pure unit volume game, and they just had to sign a contract. And we had a lot of reps that were overachieving, landing new logos that had signed a contract but never even actually consumed. So that's when we started introducing like, okay, we're now, in order for you to get your your unit-based payment, the customer has to consume at a certain level in order for you to get credit for that. And then later on, we then introduced ARR. So now they get a mix of ARR and this unit-based metric in their comp plan. So that's on the market acquisition behavior. So if you wanted to drive market acquisition, what if you really want to focus on nurturing and growing your customers? So driving product adoption, cross-selling, that might be a world where you would want to pay— measure the reps on the gross billing within the customer and maybe even SPIF on commitments or product-based, different product-based SPIFs. So an example might be just measuring our gross users. You just use a simple example. Let's say you have a customer that billed $500K, the territory billed $500K in the prior year. You have some measurement again of, of organic growth based on whatever analytics you have. Let's say you expect, hey, without us doing anything, we think that this patch is gonna grow 25%. So that would be $625K of billing. And then we're gonna give the wrap an uplift of say 20% beyond that. That gives them a quota of $725K. Again, these are all made up numbers. And this is not the approach Mongabaybee takes, but just to give you an example of how you could think about setting a quota there. And then the crediting is dead simple, which is the rep gets credited for every dollar that's billed. And a lot of the companies that I've interviewed about consumption-based pricing take this approach. The rep, the company, and the customer all very aligned. Every dollar the customer consumes is a dollar of revenue for the company, is a dollar of quota credit for the rep. So that's the major example, major benefit is it's dead simple aligning the company, the customer, and the rep. It's also very consistent for the rep. The crediting is simple to understand. It's, it's super straightforward. The drawback on this approach for gross usage, and I'll explain why in the next example, why we took a different approach at MongoDB, is getting quotas is really challenging. And it can be a bit of a black box. And most of the other companies, again, that I've interviewed in this space, they have a growth expectation for every customer. And That can be a bit, again, a bit of a black box and it can even feel punitive to the rep. So, hey, the growth expectation for this account is 30% and the rep may say, yeah, of course it's 30% because I've been doing an amazing job on the account and now you're punishing me by giving me a bigger quota. So that, that was something we had a tough time internally getting our, getting our heads around. The other thing that's tricky about this one is, and again, it goes back to how you're aligning your sales team. Is in that approach, you are paying a lot to the reps for retention. Because if you think about it, their quota is to get to $725K billed in this example, but the prior year they billed $500K. So you're essentially paying them for $500K of billing that already exists, right? So yeah, it's nice for the rep because they have a consistent payout, but, you know, you're, you're in a situation where you're, you're kind of paying them a lot on, on quote unquote renewal or retention. This is the approach which is slightly different than MongoDB took, which is to measure on incremental ARR. And this kind of came out of, I mentioned at the beginning of this conversation that we started on an NACV model selling on-prem software, selling commitments to our, our consumption-based product. And so when we came up with this idea of incremental ARR or what we called net ARR MongoDB, it's, it came out of how do we sort of neutralize whether a customer wants to pay as you go or they want to make a commitment. And so what we said to try to neutralize it because we wanted the reps to position pay as you go and we didn't want them to slow down the sales cycle by trying to force a commitment unnecessarily. We introduced this idea of, of net ARR where the rep gets paid at the end of the quarter for the incremental usage above a baseline. So if you take an example, if a customer is a new logo and they use 25 in Q1, the ARR using simple math is 100, which means the rep gets credit for 100. That then becomes their baseline heading into Q2 that they need to beat. And so if the customer uses 35 and their ARR is 140, the rep then gets 40 of credit. And obviously this can go both directions. If the, if the customer shrinks, then you're doing clawbacks because the net ARR actually can be negative. So there's pros and cons to this approach. The big pro is that you're only paying reps for growth. So it's laser focusing them on driving net new business. The reps are taking a lot more risk, but you can also give them a lot more upside, right? In the old, the model I showed you where you're just paying on gross billing, you know, you're paying them a lot of their variable for retention. In an incremental ARR model, you're paying them all for incremental growth, which means that you can be even more aggressive, I think, on things like accelerators. The challenges with it is that it can be very complicated to both explain and operationalize. For us, we came at it over the course of many years. Like I mentioned, we started out with— this was just a way for us to neutralize our commitments and pay as you go or consumption. And now it's our primary model. So it took us many steps to get there over the years. Crediting can also be negative. Reps hate that. So that's, you know, some people philosophically are not— are sort of just purely against anything that might be negative. So that's another drawback. The other thing that's tricky about going with an incremental model that we've observed is that especially in this macro environment, a lot of customers are focused on cost and cost optimization. So if you're, if you're measuring on incremental ARR, you do create a bit of a, an, a disincentive or a large disincentive for a rep to talk to the customer about optimizing their environment because that's gonna mean churn for them. In a gross billing model, it's a lot easier for the rep to go and say, hey, you should think about optimizing even though it's a little bit less commissions in the short term. We're not taking money out of their pocket and it sort of is, it's the right thing for the long-term health of the customer. So these are the pros and cons of, of these different approaches. And the last, you know, thing that you, behavior you might want to drive might be protecting or taking a longer-term view. And this would be, potentially you could be looking at paying customer, paying reps on commitment ACV. So sort of your typical new ACV approach. So you could think about introducing this and weighting and having it be part of the comp plan. So maybe part of the comp plan is usage and part of the comp plan is commitments. We've actually de-incentivized that at MongoDB because we feel like the the product is, is good and we want the reps just focusing on getting as many workloads as possible and getting them consuming rather than focusing on commitments. But again, that's our approach, that's our strategy. There might be other scenarios where maybe it's very competitive environment and you want to secure revenue longer term. There might be many reasons why you want to have that commitment element in the comp plan. This could also be something that you put on top in your, uh, compensation plan, right? So I've talked to many other companies where their prime mode of measuring the reps is gross billings, but then they have SPFs or incentives on top to get a customer to commit, particularly to commit multi-year. So measuring on commitments, as I said, the benefits are it's, you get predictable revenue, you're locking customers in. Obviously the customers have a lot of control, the reps have a lot of control, right, in a commitment world because, you know, they're getting the customer to agree to these terms. The drawback is that when you over-incentivize commits, you end up in a world where you're overselling the customer. It's less customer-friendly. You're asking the customer to predict what they're going to use. An analogy I like to use when we're talking about consumption is like consumption is like getting, you know, electricity is a classic, you know, consumption-based billing product that we're all used to, right? We all pay an electricity bill and we pay monthly in arrears. It would be very difficult for both the utility provider and for me if every year they came to me at the beginning of the year and said, so how much do you think you're going to spend on electricity? I'd be like, I don't know, is it going to be hot this summer? You know, am I buying any new appliances? It just creates a lot of friction versus just, and pushback with the customer versus just getting them to use the product. All right, key takeaways before we wrap, because I see there are a bunch of, of Q&A, and I, I hope I didn't talk too fast, knowing that I only had about 20 to 30 minutes to go through these slides. So key takeaways. First, consumption-based pricing means that you need to rethink your organization a bit. So what are the roles of all the different functions? Do you want to have sales and customer success? Like, what are the different roles and responsibilities? And you need to think about investing in product and tooling to support the go-to-market teams. Key principles for designing comp plans. This is for anything, whether it's consumption or not. Always start with the behaviors you want to drive and measure reps on what they can control. And then we talk through a few different examples, whether it's a unit-based comp plan, gross usage, incremental ARR, and commitments as different levers that you could have, and maybe in different combinations within your comp plan. So I will stop sharing and take a deep breath and let Caitlin maybe curate some of the questions that have come in. Yep.

Love it. Grab some water if you need it. Thanks so much, Megan. I know we've gotten this question a little bit in the chat, but I imagine a lot of people wanna refer back to some of these slides. So you can see some of the details that she's talked through and, and some of these ideas. So recording will be available on our YouTube. If you click on the live tab, you'll see it there just after we wrap. And then if you go to to slideshare.net/Saster, her slides will actually be available there later today. So be sure to check those out if you wanna refer back. But let's get to some questions. So first up, we got a few questions here. Like I mentioned, keep dropping them in the chat. I will ask you if you wanna come off mute and ask yourself, or I'm happy to facilitate the questions of Megan. So first question comes from Bill. How do you qualify new workloads? Is that a completely new app and database? These are a couple questions, so we'll do one at a time.

Sure. So within— so what we've done is we actually built a— this is getting a little bit in the weeds. We actually built a new opportunity type for new workloads that doesn't have SKUs. It doesn't have, you know, doesn't have finance approvals or anything along those lines. It's purely for us to track. We've got a customer, they already have a contract. This is a new workload that's going to uptick that customer's consumption. And so that lets us measure the— track the sales cycle and track pipeline of new workloads coming onto the platform. And then once the sales cycle is complete, it's quote unquote closed when it's been handed over and accepted by the CSM to onboard. As part of that, we then link that opportunity using this tool that we built internally, we actually link it to the product so we can actually connect. This is the consumption for this customer against this particular application or workload. And then the rep gets paid once the— once that workload hits a certain ARR target. So hopefully that made sense.

Bill, I don't know if you have any other questions. Feel free to come off mute if you do. His kind of secondary question to that is, what about expanding the functionality of an existing app? On top of the same database? Seems like that could be a little gray. Do you treat that as net new still?

Yeah, I mean, it's a good question. And, you know, this is probably all very specific to us and our product. Like, for us, we said, hey, a new workload means that you need to run a new sales cycle. So if you're just adding or flipping on a new feature, that's not a new workload. That's something a CSM should be able to do. But if you need to run a sales cycle, if there's, you know, you're going to be— there's competition involved. You know, then it's a proper new workload. But you're right, it is a little bit of a gray area. But the sort of guiding light for me is, do you need to run a new sales campaign to acquire it or not?

Great. Jason, do you want to ask your question? I'm happy to.

I think mine was answered. I was curious how you handle just sales compensation years 2, 3, 4, 5 for accounts, which is that it's workload-based. Is new workload-based is the answer, right? But maybe the related question, if I understand it, is just from sales psychology, is there a little bit of a free rider issue here? Imagine I close a pretty darn good account, right? They're going to add workloads almost no matter what I do. Like I could check in once a year and spend my time golfing when work moaning. And I think this is a real issue in that I think my life learning recently is a lot of sales folks that are good kind of work on a parabola where you want to work just as hard as you can to make 80% of your maximum. I don't think everyone actually wants 100% of their maximum because it gets so much harder to get that last dollar anyhow. And if they're going to add the workloads anyway, right, how do you, how do you, how do you avoid a little bit of a free rider issue in the sales comp plans? Or maybe you don't. Maybe it's just, it's just the way it is, right?

I mean, that's— so they have a mix of net ARR and new workloads, and that's kind of how we were trying to avoid the free rider, like what we call the free lunch. You call it free lunch. Outrider, we call it a free lunch, right? Like, hey, I inherit this account. Like, an example might be this, this has happened in the past. Gaming company, game, somebody, rep lands the account and then game takes off and it's game one application. I did one sales cycle and now I'm getting a massive paycheck when maybe I haven't done anything else. So what we try to do is find the balance. And so they can't get into accelerators unless they hit a minimum number of workloads that they've driven. The other thing we've done is rather than coming up with custom quotas, which we felt, again, this is our philosophy. We, we didn't want it to be black box. I know some companies feel are more comfortable with like account-based targets. We did everything t-shirt sized. So we have small, medium, large, and extra large territories. Your territory is based on your ARR. The smaller your ARR, the smaller your quota because you have less organic contributing to it. And we tried to set the quota so that like roughly half of your ARR is coming from organic. And the other half should be coming from your, the new workloads you're landing. And now let's say you have a great year, you crush it. Okay. So the next year, maybe you tick up into the next tier, or maybe we say we're gonna realign your territory and focus you on fewer accounts. Maybe you stay in the, in the same tier because we're taking away those distracting accounts. So it's not perfect. You still have those situations, but that's how we've tried to mitigate that.

Caitlin, can I steal another question?

Sure.

I'm just very curious for Megan. So just thinking through this, when you, when you have the sales rep's job is to, they're, so their quota, therefore their job is to bring more workloads on, which makes total sense, right? I wrote up Mongo and the amount of workloads your top customers do 4 to 5 years is epic, right? The growth in these accounts is, go read SaaS or Mongo, it's jaw-dropping how valuable your customers are in your 4 and 5, right? So I think that's the incentive. Question, even though Mongo is Is your average AE technically smart enough about Mongo? I, I get how they could answer the initial questions and close the deal, but are they really smart enough to convince a technical user to deploy more workloads? Can they really have those conversations on their own, or do you need so many other resources in sales engineering and architects and SEs? It's just an interesting question with the technical product. Can they really be such a trusted insight on technology that they can really create more workload insights?

It's a great question. I mean, it does have to do with the profile of rep that you hire. We do have— when we hire reps, we are looking for people who've sold not just like a technical product, but also kind of a conceptual product, right? Because Mongo— a database isn't really something that you can like demo, right? It's very— you can demo our Atlas product, but it is very conceptual. It's hard to demo. But we do, we do solutions architects or sales engineers, what we call our sales engineering team. They're a critical part of the sales process. And so that is part of how a sales rep is, it's a combination of getting the right profile, that somebody who's got the interest, the curiosity, the brains to sell a technical product and then pairing them with the right SAs. And then our CSMs, that's also an area where we try to find folks that have more of that technical curiosity. And then we layered on recently with this Coach GTM tool, which is meant specifically to help the reps if they're on a call and they're like, the customer's like, you know, what's vector search? They can like type in that question to our Slack bot and get that answer. And we worked closely with product and with our docs team to be able to help come up with those answers so that we can enable them to answer on the spot.

It's just such a, you know, when you have I mean, what I assume in a typical MongoDB sale or Workload Edition or conversation, the VP of Eng, the CTO, a senior director, even if they're not the only buyer, they're the key stakeholder in these decisions, right? They're key stakeholder. And it's just always interesting to learn how far the AE can take that, right? Because I find the toughest, the toughest customer is the VP of Eng because they don't suffer fools. If you're not like— and it's not that Mongo is a great company, but I would almost think I would buy immediate— if my AE wasn't great, I would immediately bypass them for my SE or my CSM if they're dedicated. And I wouldn't even want to talk to my AE if my CSM was the Mongo expert on my team, right?

Yeah.

Yeah.

I mean, and you add in a lot— there's another layer of challenge. We haven't really talked about this, but MongoDB is also— I would like to think of us as like the OG PLG company.

It really is, right? Yeah.

So we always targeted developers, right? Originally, our way to get to developers was through our open source product. And now it's through the free tier of, of Atlas, which is our cloud-based product. So we have tons and tons of developers, thousands every week kicking the tires on MongoDB.

Yeah.

And so our, for example, I manage the SDRs right now. You know, an SDR is gonna get an MQL that's a developer. That developer is not the decision maker, but the SDR needs to know how to talk to that developer in a friendly way, find out what's going on with that customer. Pillar up the decision maker. And, and in the—

And be smart enough to not piss off the developer, right? Because they've already tried Mongo on their own.

Yeah. In many cases, you know, and that goes back to the very first slide. Like, what is, what is consumption-based, right? It's like the power is in the hands of the customer. They could be using the product. It ties very closely to the PLG motion, right? In many cases, the customer knows as much or more about the product than the sales rep does. And that's powerful in many cases, right? So what we do, what we, we, what one of the other mantras we have among the DB is we talk about smoke as in where there's smoke, there's fire. So developers using the product is smoke. That's, that's for you to go get information, figure out what's going on, and then pillar up to a decision maker and have a more strategic conversation.

Cool.

Alright. I've got 20 questions I'd like to ask around that, but I'll, I'll, I'll let the group ask that.

We'll put you back in the queue just in case.

Put me back in the queue.

Put me back in the queue.

You go back to the end of the queue even though— Oh, yeah.

Back in line. Question from John. How do you reassign high churn risk accounts to reps?

Oh, that's a tricky one, right? I mean, in many cases, so in some cases, like for example, if it's a large optimization, that's where you might want to, we might want to think about some kind of compensation exception because it is an issue with a volatile customer. You don't want to be in a situation where it's like a, Nobody wants to touch that customer with a 10-foot pole. There's no easy way I've found to solve that other than being aware of who those customers are, making sure they have the right, right coverage model, and making sure proactively you're doing the right thing by the rep and the leadership chain supporting that customer. But that's like a— that is definitely one of the major issues with a consumption-based approach.

And how do you identify those churn risks? Are those churn risk customers? It's kind of a follow-up question from another attendee.

Some of it is proactive, but honestly, more often than not, the rep and the team knows, and they're coming proact— they're coming to us. They're saying, hey, look, I know this is happening or is going to happen. I know that they're price sensitive or they're there and they're going to optimize. And typically the sales leaders are bringing us those situations. Some of it is coming from us looking proactively, but it's kind of a mix of both.

You don't have like a definition or something that you can agree to of like, this indicates a high churn customer?

We do have some indications. It's typically a combination of data. So tracking what their usage looks like, input from the CSMs. And then we're also always looking, at least for me and with my sales ops hat on, I'm also always thinking about materiality, you know, like, is this material churn that's really going to impact the rep and the customer, like, you know, those are the ones I'm looking for, the outliers. Again, like if it's a big customer with a big optimization, that's like one we want to get out ahead of because again, I would hate for a rep not want to, not to want to cover a major account just because they're worried about their paycheck. Like that would be a terrible outcome.

Yeah. And goes back to kind of that incentivizing what's in their control. Another question from Milan. Can you share more about how your team set up Coach GTM?

So we, it was kind of a skunkworks project. We had an engineer who was actually a former sales engineer, former SA, who built it and in sort of partnership with all of the other teams, including product and doc And the idea was, you know, MongoDB is almost 5,000 people, but we try to have like be big company with heart of the startup. And so one of the things I love about the company is like, yeah, we're cool with having one rogue engineer trying to build this and we just went for it. So that's the approach we took and it was in some ways intentional. And this same engineer, it's a small team, it's an engineer and a product person. They've done a few of these kinds of projects where we've said, go like break glass and go build something. If it works, then we'll go operationalize it within like our internal tools and our IT team. So that's the approach that we've taken, which I think actually is a, has become a bit of a strength for us and helped us sort of fight against becoming overly big and big, slow moving and bureaucratic.

Awesome. Taylor, you're up next. Do you want to come off mute and ask your question or I'm happy to if not.

Give you a second to do—

Yeah, sure. Hi Megan, thanks so much. Question was around assessing the performance of your comp plan, right? Like, how do you know that it's working? Is it purely around driving the behavior, seeing the behavior that you're trying to drive, or you're also looking at, are like, how well are you retaining some of your top reps? And I guess like a small piggyback off that is like, when you're setting your quota for the full team, do you have an expectation of this is going to work if, you know, 50% of our reps hit quota, we'll be fine. We'll hit those targets. Like, how do you— like, what's like— what's that look like for you? Thanks so much.

Yeah, I mean, it's definitely a balancing act, right? So on one hand, you want to push— you want to have a comp plan that's going to push people to go beyond what they would do normally, right? But you also want to have a comp plan that's very attractive. So I I think one of our goals has always been to have a very aggressive and attractive pay-for-performance comp plan. We have accelerators that are much higher than I see at other companies. And even, you know, our CEO and our CRO, we say, hey, that's worth it to us to pay outsized commissions to a few people because we want to show, we want to be able to attract the best talent. So that's been part of our comp design philosophy. And then, you know, how is it working? So, you know, whether or not it's working for us is like, you know, are we getting decent, like, broad-based participation, but also getting a few outlier people really hitting the number, like, making a lot of money? That to us is important. And then for us, we're also measuring, like, how much, again, is sales actually moving the needle? So how many new workloads are coming from sales? How do we compare to our control group? Like, that to us is, is are the measures of, of success of the comp plan. Because you're right, like, you don't want to just have a comp plan that's unrealistic. Like, you know, you'll never be able to attract talent with a comp plan that's, uh, has unrealistic targets. And so I'm always kind of in the middle mediating between finance and sales. Sales obviously always wants lower targets. Finance always wants higher targets. And I'm like, hey, we need to make the targets stretchy enough that they're going to push people, but not so stretchy that we're not going to be able to provide like aggressive accelerators and make people really like excited about the comp plan.

Yeah, and keep them motivated.

Yeah, for sure.

David, you've got a couple questions that you've dropped in. Do you want to come off mute and ask?

Sure.

Hopefully that was for me. Megan, thanks. I always have to ask because there was a lot of Daves and Davids in the world. Megan has been really helpful. Um, I had a couple of questions kind of understanding that you explained the commission side. I'm wondering how that interacts with the customer side. So I'll ask these one at a time. One is, um, is there a different pricing model based on whether the customer is on a pure consumption versus if they make a commitment? Many companies would give kind of lower pricing per unit or whatever if there's a commitment.

I wonder how you do So we do offer discounts when a customer commits, but the reason we went with a consumption-based model, we wanted it to be customer-driven and not rep-driven. So if a customer's consuming and they want to commit to get better economics, we want them kind of coming to the table versus like customer, like a rep going to the customer and be like, commit, commit, commit, commit. So we were trying to make it like the incentives. Again, it's kind of a delicate balance. So we do have a spiff for commitments, but it's under very specific criteria. Has to be ahead of— customer needs to be committing ahead of their run rate. They need to be committing a certain amount. So again, we were trying to avoid a situation where the rep was artificially pushing a commit. But if it was convenient for them to take down a commit because the customer wanted it, we wanted to make it possible. We wanted to incentivize that. So hopefully that makes sense.

Yes, that's very helpful. Thanks. Also, I'm curious, frankly, one of my last companies, we had an issue with— we're on a cloud provider, I won't mention the one, but it was, you know, volumetric, you know, based, whatever. And, you know, what happened, we got surprised by the bills, right? And, you know, we were a relatively small company. And, you know, whether it was just not enough controls, right, by the CTO or whatever, but this went on for 2 or 3 months. And then our bill from the cloud provider was like 3x what we expected. So I was just kind of curious, do you run into that situation? And if so, do you give tools to your clients, right? Either whether they get an alert or maybe they can put their own governor on it or throttle and just say like, hey, you know, maybe just give them tools to make sure they don't get invoice and bill surprises. And if you do get that situation and the customer's upset, what do you do about it? Do you ever do any credits back?

Yeah, I mean, that's definitely, you know, the volat— customer volatility is, is definitely a challenge. I, I should say, you know, I, I mentioned that we try not to spend a lot of time in the sales cycle doing these complex sizing exercises, but we still do sizing to help them estimate how much they sp— are going to spend. And that's largely driven by the, the solutions architect. We have some calculators to help them help the SA and help the customer estimate what they want to spend. But we're trying not to make that— we, we tried to make that more lightweight rather than like a, again, trying to push the commitment onto the customer. And in general, one of the things that we've learned since we went full in on consumption at the beginning of this year is like you have to be proactive with customers if it looks like they're going to spend ahead of what they are expecting. And that's really the job of the, the CSM to flag those things because if you're spending out of control, then you're— yeah, maybe for the rep, maybe they don't care in the short term, they're getting paid on it. But the longer-term relationship, that's where the CSM needs to step in and say, hey, this is going to become a risk for the customer in the longer term. And they should be more of the, the mediating force in those scenarios.

Right. Okay. Thanks. I can sneak in one more question. I was with Teradata for a number of years, and what we found often was a fantastic solution architect actually could make all the difference in the world. So we went through different models, but I'm curious, do you pay commission for your solution architects and maybe recognition of knowing that they can turn a good salesperson into a great salesperson or great results?

Yes, they are on commission plans. They're obviously not as leveraged as a rep is. Like a rep is going to be like 50/50 in terms of their pay mix. SAs are typically like, you know, 70/30 or 80/20, similar to a CSM. But, you know, they have skin in the game, right? And, and they should. But you also want them to be, you want them to be like we were talking about, they're like a little bit of a counterbalance also to the sales rep, like they're the ones that are building that consultative relationship. They typically have been a developer at some point in their career. So it's a really critical relationship. So you kind of want them to be be a little bit more consultative and less, you know, of the aggressive salespeople. And going back to Jason's question, we actually have had some success bringing SAs into sales roles because they, they understand the product, they're more technical. It doesn't happen all the time, but it does happen. We do see people who were, were sales engineers wanting to go into a sales role because they know there's bigger upside. Obviously, there's a skill, there's some skills gaps, right? Like SAs never done prospecting. So that's like a whole new thing that they need to learn. But in terms of engaging with the customer and being able to provide, you know, value on the product, they can be really amazing.

Great. Okay. Thanks a lot. Appreciate it.

Thank you.

A similar question from Joe, just about the CS and sales relationship. So, Joe, I don't know if you want to add anything. I'll ask your question, but if there's anything else you want to chime in. I don't know if it's the same as with the solutions architects, but how do you avoid kind of the finger-pointing game, right? It's sales problem, or you sold me a bad deal, or you didn't do a good enough job on the customer success side. So, um, I imagine that's a, a mediation job for yourself, but how do you avoid, um, kind of the finger-pointing game across both sides of, of the role when you have a, a deal or a commission on the table?

Yeah, it— that's a good question. And one of the things we've tried to change, shift in a bit in the sales culture overall since we moved all in on consumption is that consumption is a team selling sport. So we're all in this together. And that's sort of like, the first step is getting everybody to realize like, sales can't succeed without CS, CS can't obviously can't succeed without sales, like we're all working together. It does mean that, you know, I talked about roles and responsibilities, they do blend CS, SA, sales, but if the incentives are properly aligned, so you know, we talked about SAs, SAs have very similar incentives to the reps, like they're tied to the performance of the reps that they support. So that really should drive alignment between the teams. Similarly, the CSMs have goals that align with, with, with the reps. So it's important not just to think about the rep comp plan, but the whole ecosystem comp plan so that you're not creating friction, friction between the teams. Another component of our comp plan, which is really important that we haven't talked about at all, is services. And typically where I see the problems happening where a customer isn't implemented right is where we haven't positioned services and given them the right help that they need from the get-go. So that's another area where you could be thinking about in terms of incentives is like making sure that you're placing services with, with customers from the start. We also built out for our, because we have this long tail of customers in especially on credit cards. And I, I didn't even talk about this. We have a sales team called Product-Led Sales that covers that customer, that credit card customer base. And they primarily sell these tiny little professional services packages that are delivered remotely in like 4-hour increments. And that's actually been hugely helpful to make sure customers are optimized ahead. Right? So like, hey, you know, it's, it's not gonna cost you a lot of money. We're gonna give you somebody who's a MongoDB expert to make sure you're set up. It's actually pretty easy and a pretty simple sale for a more junior rep. But you'll see the, the, the fruits of that is that the customer is better implemented from the get-go and then they tend to be retained for the longer term.

Very interesting. Kind of a random question, but question from Monique and then Jason, I'm going to throw it back over to you. So can you share what percentage of your revenue is pay-go versus commit?

Well, from a revenue standpoint, like if you listen to our earnings calls, like commitments are the way we recognize revenue as a company is on consumption. So you could sell a customer a million-dollar commit. If they don't consume, it's not hitting revenue. So that's like one of the reasons we moved to consumption is that we felt that it better aligned the reps with the company and with the customer. Makes sense.

Makes sense. Okay. Jason, any other questions you've got for us? Or for Megan, I should say.

No, maybe I could ask one last one. Just, just the, the one thing that's really interesting about Mongo, I'm sure there's a few others like this, but it's how Mongo has both the PLG motion and it's so enterprise, right? It's real because these million-dollar customers are the huge vector of growth, right? I'm just rereading this Aster post. 33%, 36% of your revenue comes to the top 100 customers. The million-dollar customers are growing 30%, right? How do you, maybe you've touched on it, how do you divide the line? Where is an enterprise account and how do you like segment the teams when you have this kind of PLG to enterprise? Like where do you, how do you decide who's in what bucket segment, AEs and all that sort of stuff? Because it's just, it's so interesting how big the customers grow and how these tiny acorns, right? And even these self-serve acorns become massive accounts.

Right.

Is it just by logo? Do you just analyze the potential size of the account or how do you fit in? What type of reps get what deals?

Yeah. So the way we're segmented, so we have— we're segmented into product-led sales, which covers the credit card segment, and they have an incentive to surface that, you know, digital native that might become the next, I don't know, Uber or Facebook. Right. And surface that to a field rep. But that's primarily like a more junior remote selling team.

I see. And they serve, they do the discovery and they hand it off. They're incented to hand it off to the, to the field team.

And then within the field team, we have an acquisition and a growth team. And then within growth, we have a strategic segment which we call pods where it's one or more reps on a single customer. So our largest customers tend to be in that pod segment where it's a dedicated rep or reps. And then there's typically, we have, it depends on the particular customer, but there could be a dedicated or a 50% CSM or SA on those like high, like, you know, highest potential customers. And then within the core sort of growth team, you know, we have the small, medium, large, extra large patches. And within those, we have a subset that we call aspiring pods. So accounts that we think have potential, massive potential.

More of us should do that earlier. You manually identify them?

We do. We have a scoring model to identify them. We have a bunch of different data points we look at. For our more, for the accounts outside of those like pod accounts, we, we do look at a bunch of different metrics. One of the metrics we look at is we came up with this concept of total addressable MongoDB market. So TAM, and we, we run a lot of our metrics on how many developers are in the, in the customer account. It's not a perfect metric, but we basically know, right?

It's directionally correct though, right?

Yeah, directionally, it says like, hey, we know typically, like, if you know the development team, typically they should be able to share like 1 or 2 pieces, 1 or 2 pizza pies, right? It's like 6 people, right? So we say, okay, so every 6 developers we think is a workload or an app, we assign a value to that. And that kind of gives us a ballpark on what the potential is in the customer. And that's how we sort of think about what the potential is and where we should place it. Whether we should give it to a rep, whether, hey, we think this is pretty much maxed out, let's give it to just the CSM team needs to own it, doesn't need to be going to a rep. And then we have a whole bunch of other things we look at to say these are the aspiring accounts that we aspire to have, you know, 1-to-1 coverage, maybe the next, you know, 1 to 3 years. Yeah. Anyway, it was a very long—

special squad that works on these, on these, on these aspiring customers. It's sort of a cross-functional team. Is that what it is?

So the aspiring pods, they have a little bit of extra resource from marketing. And now you're, you're stretching me. I can't remember what we decided on because we're in planning right now. But basically, like, they fall into the standard categories of small, medium, large, but the rep, it's one rep. So we're basically telling the rep, your job, you're going to get a little bit of extra resources. Your job is to try to get this to be at a point where you can go be in the pod program with all of the resources surrounding it. And so we've basically built a bunch of scoring models to figure out which accounts we think have that potential.

It's great. Yeah, I think too many folks, you can accidentally treat these aspirational customers as a normal SMB, and then you just, you just miss a huge opportunity, right?

Yeah, for sure. And, you know, those accounts need, you know, different type, they have different expectations also, right? Like they're, they're used to being treated a certain way. So proactively trying to treat them that way. But there's always a balance, right? Because you don't want, it's very resource intensive to have those kinds of accounts. So So we had to balance like, okay, what are the, what are the accounts that we want to put into this Aspire program and be somewhat selective. So we're not, because we also need to invest in other areas also.

You know, for example, one last question, one last different question. Do I have one? I have the last minute. We got one.

Yeah, the last minute. She's gotta go.

Just so you can read about Mongo on Saastr, been incredibly successful through all these macro wins, right? Up and down. It's, it's been But Mongo has gotten more efficient, like every— almost everyone else that's public has gotten more efficient, right? Every— everyone's margins have gone up, the operating margins. And Mongo, Mongo, what has changed in sales compensation in the more efficient era? Has not much changed? Is it a different perspective? But, uh, this is, I think, a meta topic a lot of us are thinking about. What has to change to be more efficient? What have you learned?

Um, I think the efficiencies we've been focusing on have been more around where been more around sales segmentation. So what are the accounts we want to focus reps on and what are the accounts we want to focus product-led sales and customer success or account management on? Like that's been where we've been trying to drive efficiencies. Like if there's not a lot of upside potential, we don't need a very expensive sales rep to basically pay them on organic growth, right? We'd rather go give that to a more junior rep or tell us, you know, someone who's a different, slightly different mindset. And that's where I think we're driving more of the efficiencies in sales.

Have sales more matched up with growth rather than maintenance of revenue is where you get efficiency. That makes sense on a spreadsheet. Cool, thanks. That's a great answer.

Awesome. Let's end with that. So Megan, thank you so much for joining us. This is such a great topic that I think a lot of people are just curious about, so we appreciate you sharing your insights. Um, and thanks everyone for joining us. Reminder, if this, um, type of comp plan incites you, Megan's team is actually hiring. So Megan, what's the best way— do we go to your careers page, or what's the best way to kind get in touch and learn more about your, your growing team?

Yeah, MongoDB.com/careers or just find me on LinkedIn or my megan@mongodb.com, M-E-G-H-A-N. So I will definitely would love to speak with folks who are looking for, for opportunities.

Love it. I just dropped the careers link in the chat. But thank you so much again. Really appreciate it. Thanks everyone for joining. Reminder, recording will be up on the YouTube, slides will be available on SlideShare, and we will be back here next week at 10 AM on Wednesday with the CIO at Freshworks. So we'll see everyone then.