I spent eight years running Sales Operations at MongoDB, including the years when we made the transition from subscription software to a consumption model. I wrote this article for the founders and GTM leaders navigating this now, particularly those building AI products where per-token or per-API-call pricing is the default. If you charge on usage, you need to think about comp on usage. Here’s everything I learned.

TL;DR:

• If you’re building an AI business, it’s likely priced based on usage. The pay-per-use model pioneered by AWS is now standard for AI-native companies: per-token, per-API-call, or hybrid seat-plus-usage.

• Traditional SaaS comp breaks in a consumption world. When revenue is usage-driven, the deal close is just the starting line. Measuring rep impact, setting fair quotas, and avoiding perverse incentives all require fresh thinking.

• There are three main models: paying on committed spend (similar to traditional SaaS), paying on incremental usage, paying on gross usage, or some combination of those three. Each has trade-offs.

• I share my personal experience iterating on the MongoDB compensation plans when I was head of Sales Operations. We used the incremental usage model, and fine-tuned it over the years.

What do we mean by a “consumption” or “usage” based pricing model?

Before we get into the compensation mechanics, it’s worth grounding ourselves in what makes a consumption model fundamentally different from what came before it. Let’s explore the three eras of software pricing:

The perpetual license era (think Oracle) meant the customer bought the software outright, typically via large upfront deals. The vendor owned the market, pricing was complex, and the customer was locked in. This was a very vendor-friendly world.

The SaaS era (think Salesforce) shifted toward subscription-based pricing where the customer “rents” the software and renews annually. More customer-friendly, but still with friction, including large upfront commitments and complex pricing tiers. And from a metrics standpoint, you have a misalignment between bookings and actual revenue recognition. (Bookings are recognized upfront while the revenue is recognized ratably over the course of the contract.)

The consumption era (pioneered by AWS and now AI-native startups) means that the customer pays for what they use, billed in arrears. Usually paired with a product-led growth and/or self serve model, the product has to continue to prove itself in every single billing cycle.

“For customers, the benefits of doing business with vendors that offer a usage-based pricing model are clear: use the products you want, when you want, and be billed when you do.”

— Ben Chambers, Sales Compensation Consultant (formerly New Relic, Databricks)

This pricing model is particularly relevant in the age of AI. Many AI native companies price on a per API call or per token basis, or use a hybrid of per seat models with usage. If you’re building a product that calls an LLM under the hood, your pricing model is almost certainly consumption-based in some form, which means your sales comp model needs to be too.

During my tenure leading Sales Operations at MongoDB, we shifted our pricing and sales motion from subscription to consumption based. In this article, I’ll share the evolution of that model over time and compare it to other companies that I studied while designing the plans, such as AWS, Twilio, Snowflake, and others. These insights should be applicable for founders and GTM leaders at AI companies who are navigating building their business around usage-based pricing.

The two main usage-based compensation models: incremental usage and gross usage

In working on MongoDB’s shift to consumption, I researched several different approaches and spoke with RevOps leaders at many companies. The compensation models typically fell into the following categories:

1. Pay on committed spend, similar to a traditional SaaS model

2. Pay on incremental usage (example: MongoDB)

3. Pay on gross usage (example: AWS)

4. Some combination of the above, e.g. a comp plan with an element for committed spend as well as usage

I’ll start with the incremental approach, since that is what we adopted at MongoDB. We didn’t get there overnight, so let me walk you through the process.

Compensating on incremental usage

MongoDB built their sales incentives around a metric we called Net ARR. I want to share how we actually got there at MongoDB, because it took several iterations on the plans over many years, each one fixing a problem the previous stage created.

Stage 1: Paying on commitment

When MongoDB first introduced its cloud product, Atlas, in 2016, the company was operating in a world built around traditional software sales. Sales had been selling an on-prem product (MongoDB Enterprise Advanced) where they were credited using a traditional New Annual Contract Value (NACV) method. Atlas, in contrast, would be billed based on usage.

When we introduced Atlas, we initially applied the same NACV logic to sales compensation. Reps were credited when they got the customer to agree to purchase a predefined pool of credits, from which the customer would draw down as they used the product. When they ran out of credits, they would have to go back to sales to either renew early or do a short “top-up” deal to bridge their usage until the end of the contract.

Challenges with this approach:

• It introduced friction into the sales cycle. Customers had been conditioned by the hyperscalers to pay on a usage basis and had come to expect that pricing model.

• To purchase a commit, the sales would need to go through a sizing exercise to figure out how much the customer should buy. Sales engineers were spending weeks trying to help the customer predict their spend.

• There was an incentive for reps to pressure customers into commits before they were ready. Even worse, in some cases they might oversell the product, getting customers to make large commitments and then walk away before the customer implemented the technology.

• Reps were wasting cycles chasing paperwork for “top-up” deals with customers once they ran out of credits. This was annoying for the customer too, most of which preferred to be billed overages in arrears rather than sign a new contract.

Stage 2: Neutralizing the incentives with run rate crediting

The goal of Stage 2 was neutralization: we wanted reps to be indifferent between selling an Enterprise Advanced commit, an Atlas commit, or having a customer pay-as-they-go. Whatever was right for the customer should be right for the rep.

After a customer consumed their commit, we would bill in arrears and pay reps on the incremental run rate above the commit. This solved the problem of reps chasing top-up deals.

Once the customer burned through their commitment, the rep would automatically get credited for any incremental ARR. And if the customer had no commitment at all, we’d pay on the run rate directly. This addressed the issue of reps prematurely pushing commitments, and also reduced (but didn’t eliminate) the time spent working on sizing deals.

Example

Let me illustrate it for you in an example.

• Q1: The customer commits to 120 and they use 25. That means that their annualized run rate is 100 (25 per quarter x 4 quarters). The rep would get credited for the commit of 120.

• Q2: The customer starts to ramp up their usage and consumes 35. This means that their annualized run rate is 140, exceeding their original commit. However, because they have only consumed a total of 60 (25 in Q1 and 35 in Q2), the rep wouldn’t earn any incremental credit.

• Q3: The customer’s usage accelerates further and they consume 50. This brings their ARR to 200 (50 per quarter x 4 quarters), and they have used up their commit of 120 (25 in Q1, plus 35 in Q2, plus 50 in Q3 is 135). The customer wouldn’t need to go through procurement again; they would start getting billed for the incremental usage. And the rep would get credited 80, which represents the difference between their baseline of 120 (established by the original commit) and their run rate (200).

• Q4: The baseline on the account would be 200. In order for the rep to earn further credit, the customer would need to increase their usage or commit to more than 200.

What worked:

• Reps were still incentivized to drive commitments, but they weren’t pushing them on customers unnaturally.

• Sales and the customer spent less time on sizing commitments.

• Reps (and customers) no longer had to do top-up deals.

Challenges with this approach:

• We started to notice reps racing to pull renewal commitments forward at the end of quarters, and sometimes even sacrificing discounts, in cases where a customer’s run rate exceeded their commit but they hadn’t yet exhausted the commit balance.

• When a customer’s use declined below the baseline, reps were subject to commissions and crediting clawbacks.

Stage 3: Greater of the run rate or the commit

To address the issue of reps pulling forward renewals, we made a simple change to the crediting guidelines. The rep would be paid on the greater of the customer’s ARR run rate or their commit, whichever is higher, regardless of whether they had exhausted their commitment.

If we revisit the example above, under the new crediting rules, the rep would have earned credit of 20 in Q2 because their run rate (140) exceeded the baseline set by the commit (120) even though the customer hadn’t exhausted their commit. This effectively pulled forward ARR crediting, and had to be taken into consideration in quota setting. (Said another way: quotas went up because reps could get ARR more quickly and easily.)

What worked:

• Reps no longer pushed customers to renew early if they hadn’t exhausted their commitment, putting them in a better negotiating position.

Challenges with this approach:

• We continued to have challenges with customer churn impacting reps’ paychecks. This was largely addressed through an exception process that was highly manual, and was the major pain point of this comp plan.

Compensating on gross usage

While MongoDB was undergoing this transformation, I spoke with peers at many other companies, and most had some element of compensation on gross usage. The logic is intuitive: every dollar the customer consumes is a dollar of revenue for the company, so give the rep credit for every dollar billed. The quota is set as a total billing target, factoring in an expected organic growth rate, plus an additional uplift that the reps were responsible for driving.

Here’s a simple example of how you might set a quota in this model:

• Territory billed $1,00,000 in the prior year

• Organic growth is 25% → $1,250,000 of billing expected

• Quota is set with an uplift of 20% → $1,500,000 quota

What works:

• The elegant part of this model is the alignment: the customer, the company, and the rep are all measuring the same thing. Unlike the incremental crediting approach, the crediting model is simple, and you don’t have to clawback if a customer’s usage drops. (The reps just earn less of their overall variable and have to make it up elsewhere.)

• Reps have predictable payouts as customers consume.

• This can be paired with a separate element for commitments. In some cases, prior year commits informed the consumption element of the comp plan, and the commit element would be weighted (e.g. 30% on commitment, 70% on usage) based on how many customers were available for renewal.

Challenges with this approach:

• The biggest challenge is quota-setting. You need a model to project growth for all of your accounts, and these growth expectations can feel like a black box to reps.

• Reps earn commissions on the usage across their entire territory, including the portion that would have grown without them. You’re effectively paying on retention as well as expansion. And you can suffer from the “free rider” effect, where reps can earn a large portion of their variable just for retaining the customer.

• It’s harder to make an attractive comp plan with big upside, because the quotas end up being so large.

There’s no perfect comp plan for consumption

When I’m asked about compensation plans for consumption businesses, my answer is always the same: There is no perfect solution, only trade-offs. I’ve described many above, but here is the cheat sheet:

If you’re building an AI company on usage-based pricing, expect to start somewhere imperfect and improve from there. The goal isn’t to design the ideal plan on day one. It’s to design a plan that you can measure, that reps can understand, and that you can change when the incentives drift from the behavior you actually want.

Sources & Related Reads

• The AI pricing and monetization playbook from Bessemer Venture Partners

• A new framework for AI agent pricing from Growth Unhinged

• How Do I Build a Usage-based Sales Compensation Plan? from the A16Z blog, co-authored by my former colleague Joe Morrissey

• Overages: The Overlooked Problem in Usage-based Pricing (and How to Fix It) from the A16Z blog, also by Joe Morrissey

• Navigating Consumption-Based Pricing with Mike Scarpelli, CFO of Snowflake

• Sales Compensation in a Consumption Pricing World, Andrew Straus on the Snowflake blog

• Going Usage-Based? It’s Time to Rethink your Sales Comp by Ben Chambers

• The Cloud Consumption-Based Model: Changes Sales Leaders Can Make to Ensure Success, Laura Palmer on LinkedIn

• Usage-Based Pricing: Behind the Scenes of New Relic’s Transformation, OpenView blog

• Google Cloud Considers Scrapping Sales Commissions Based on Deal Values, The Information

• The 10 Commandments of Sales Compensation

• Finally, embedded below is a talk I gave at SaaStr on this topic in 2023

The failure usually shows up in one of two ways:

1. The founder hires a marketer to focus on messaging, and then disappears, assuming positioning is now “handled.” It isn’t. Messaging requires the founder’s ongoing involvement, especially when the product is still evolving.

2. The founder hires a marketer to drive pipeline before they have product-market fit or positioning. Spending $$ on distributing a sub-optimal message is $$ down the drain.

Marketing is different from almost every other function you’ll hire for. It’s a function with several distinct sub-disciplines.

In sales, the rep in New York is doing the same job as the rep in London. In engineering, yes, you have specialties, but a senior engineer in one stack can usually ramp on another. Marketing doesn’t work that way.

Under the marketing umbrella you have product marketing, communications, demand generation, marketing ops, and design. These are distinct skill sets. Hiring a great demand gen person and expecting them to also own your messaging strategy is like hiring a great radiologist and expecting them to see patients in the emergency room. They’re both doctors. One diagnoses; the other treats. You would not want them to switch.

So when a founder asks me “should I hire a VP or a more junior do-er?” I usually push back on the question. The more important question is: which flavor of marketing do you actually need right now?

AI has changed this a bit. Senior marketers can do more (and should be expected to do more) than ever before. One person with the right instincts and good AI tooling can cover ground that used to require a team. But it hasn’t collapsed all the disciplines into one. It’s mostly made good marketers faster.

Product marketing vs Demand generation

For most early-stage B2B startups, it usually comes down to two options: someone with a product marketing background, or someone with a demand generation background.

The case for starting with product marketing

Founders are often better at positioning than they realize. You sold the early deals. You know the domain. You’ve had the customer conversations. The problem isn’t that there’s no story, it’s that the story lives in your head and nowhere else.

Take Charity Majors, the founder and CTO of Honeycomb, as an example. Charity didn’t just build a product. She invented a category, using the term observability as early as 2016 to describe and differentiate Honeycomb from simplistic monitoring tools.

That’s product marketing at its best, and it happened because someone with deep domain knowledge spent lots of time thinking about the problem, speaking with customers, and even writing an entire book on the topic.

You may think that I’m making the case for founders to lead product marketing. And I do think founders are best positioned to drive messaging. But hiring a product marketer can make sense as long as the founder stays involved. For example:

• A product marketer can help get the story out of the founder’s head and into a format the rest of the company can actually use: website copy, sales decks, one-pagers, competitive battlecards.

• A product marketing hire is a good fit if your product is evolving quickly. In the early days, when what you’re selling can change substantially from quarter to quarter, a product marketer can own the process of keeping messaging up to date and aligned across all the teams that are customer-facing.

• A product marketer is also a great fit if you are scaling your sales team. Sales will demand sales collateral and provide constant feedback on positioning based on their customer conversations.

The biggest failure mode is the founder who hands off positioning and then disappears. Messaging is not a one-time exercise. The market evolves, competitors shift, you learn things from customer conversations that should feed back into the story.

Charity was inspired by the term observability as it was being used in another domain (hardware) and then “spent a couple of years trying to work out how that definition might apply to software systems.” Yes, it took years for her to nail the messaging. So don’t expect to solve positioning over night.

The case for starting with demand generation (or a growth marketer)

If product marketing is about what you say, demand generation is about getting people to actually hear it. Running campaigns, testing channels, driving traffic to your website, and filling the funnel is the job of a demand gen marketer. Content, events, webinars, digital channels, whatever combination works.

Some founders take this role a step further and hire a growth marketer. In addition to running campaigns, a growth marketer will also be working on optimizing the product itself, seeing the first-time user experience as an extension of the marketing funnel. This profile typically makes sense in a company with a product-led growth approach.

The best growth marketers share a trait: they experiment constantly, kill what doesn’t work fast, and double down hard when something does. They are allergic to running the same playbook quarter after quarter regardless of results.

Product marketing builds the message, and demand generation distributes it. For that reason, demand generation typically builds on product marketing.

This is the right hire if:

• Your messaging is somewhat stable you’ve got product-market fit, customers who get what you do and love it, but you need more of them to know you exist, and/or

• You’re a founder who stays deeply hands-on with messaging and needs someone to build and run the distribution engine.

So which profile should I hire?

Start with the problem. What’s actually blocking you? If everyone’s confused about what you do, hire a product marketer to refine the message. If everyone who hears about you loves it but almost nobody has heard of you, hire a growth marketer to drive awareness.

And if someone suggests you hire a VP who will “oversee all of marketing” before you even have a team, just know that what you’re actually getting is someone who manages. What you need, at this stage, is someone who does things.

More on this topic

• I recently co-authored a post for the Ansa blog When (and how) should I make my first marketing hire? with my long time friend and former MongoDB colleague Justin Dunham. Justin now runs an agency called ércule that helps startups build organic and content marketing. Watch the Ansa blog as this is the first in a series on this topic.

• Ansa and Base10 are co-hosting a breakfast event for founders at Base10’s San Francisco offices, where Justin and I will be talking about this topic, along with Austin Lau from Anthropic. You can apply to attend here.

“We need to slow down hiring,” the ops team told me.

“Are you sure that’s the right conclusion?” I asked.

“We need to gain more confidence that our AEs can attain their targets before investing more,” they explained.

“But do you know if you missed your number due to a productivity issue or a productive capacity issue?” I challenged.

“Well… it’s both… I think.”

Productive capacity and productivity are the most fundamental metrics in a sales organization. Not only do they help you forecast your expected output, but examining them is the first step to understanding how your sales organization is performing.

Yet, these two terms are frequently confused and conflated. So let’s get precise about what these two things actually mean.

Productive Capacity vs Productivity

Productive capacity is a projection of what you think a team should produce in a given period. It’s a representation of how much “firepower” you have. If a ramped rep produces, on average, $1M per year, and you have 5 fully ramped reps, then you have $5M in productive capacity (5 reps x $1M/rep per year).

Productivity is your average output per rep. It’s an efficiency metric that normalizes performance on a per capita basis. If you have 5 reps and they collectively produce $4M in a year, your productivity is $800K per rep ($4M / 5 reps = $800K per rep).

Here’s a quick example:

• Team A: 12 ramped reps close $12.6M in Q2 → $1.05M productivity per rep

• Team B: 30 ramped reps close $21M in Q2 → $700K productivity per rep

On the surface, Team B looks like the better team. They closed $8.4M more. But on a per-rep basis, Team A is dramatically outperforming.

A Quick but Important Detour: Quota Is Not Productivity

Before we go further, it’s worth pausing to discuss a pet peeve of mine: when people use productivity and quota interchangeably.

Quota is how you pay people. Productivity is what you actually expect them to produce. They’re related, but they’re not the same thing.

Most companies set quotas above expected productivity deliberately, by 15-25%, to create a performance buffer. So when you’re modeling what a team will actually deliver, you shouldn’t be using quota as your input, you should be using historic productivity. And ideally, you are using different productivity assumptions for each segment and geography.

Here’s why it matters: if you have 10 sellers each carrying a $2M quota, you have $20M in “street quota.” That sounds like a lot of firepower. But if those reps realistically produce $1M each based on historical performance, your true productive capacity is $10M. If you only look at the quota in the field, you’ve just inflated your sense of safety by 2x.

Here’s another reason it matters. When a new rep joins, they typically have a quota from day 1. It might be a lower quota to reflect their ramp, but they have a quota nonetheless. Yet, it’s unrealistic to expect a rep to start producing immediately. For this reason, I would typically model productive capacity at $0 during the ramp period.

Why This Distinction Matters

Going back to the company I was advising: it’s entirely possible to miss a revenue target because of rep attrition, while the remaining reps are overachieving. In that scenario, the right answer might be to double down on hiring, not pull back. (And to diagnose why you are having such attrition.) If you don’t separate the capacity question from the productivity question, you won’t see it.

The first step in diagnosing a performance problem is to break it into one of these two categories:

• Capacity problem: You don’t have enough reps. The team is producing well per capita; you just don’t have enough of them.

• Productivity problem: You have plenty of reps but on average they are underperforming. Adding more headcount here just scales the problem.

An important callout: as your sales organization gets larger, it becomes as important to forecast hiring and attrition as it is to forecast revenue. But that is a topic for another article.

If it’s a capacity problem, then you can narrow in further on the issue:

• You aren’t hiring fast enough

• You are attriting too many reps

If it’s a productivity problem, it will take you on a different path, where you will want to look at:

• Productivity by segment, geography, and tenure cohort

• Pipeline generation (is it a top of funnel issue?)

• Close rates (is it a deal execution issue?)

• Ramp times (are you hiring the wrong profile or not enabling/onboarding?)

This flow chart illustrates the process:

If you enjoyed this topic, I recommend reading The Use of Ramped Rep Equivalents (RREs) in Sales Analytics and Modeling by my favorite blogger Dave Kellogg.

1. Know what you are optimizing for.

This may seem obvious, but it’s worth stating explicitly. The comp plan communicates the behaviors that you want.

It’s easy to skip this step because, doesn’t everyone want more revenue? Well, not all revenue is created equal. Do you value new logos over retention and expansion of existing customers? Are there certain market segments that are a better fit for your product? If you have a product-led growth approach with an option for customers to purchase self-serve, do you want reps calling accounts that have started spending on a credit card, or is it more efficient to leave them in the self serve channel?

You need to start with these questions, before putting anything into a spreadsheet.

2. Not everything can be managed in the comp plan.

Compensation is a powerful lever, but it’s not the only one. Inspection, management, and coaching all matter too.

Take pipeline generation: an AE needs to build pipeline to hit an ARR target, but that doesn’t mean you need to put pipeline metrics into the comp plan. Build dashboards. Inspect. Coach.

Another relevant example: Sales Development Reps (SDRs) are the most junior reps in the organization responsible for building pipeline. They are highly motivated by career trajectory, in the hopes that they will graduate into a quota carrying role. They will pay close attention to criteria for promotions, often more than they focus on their comp plan.

Trying to shove everything into the comp plan is the best way to over-complicate your plan, and confuse the hell out of your reps.

3. Upside and risk go hand-in-hand.

Sales engineers, channel reps, and SDRs sometimes push back on how much more AEs earn. Why do they earn so much, when they didn’t find the deal or didn’t do the technical demo?

Because the risk profile is completely different. Typically 50% of an AE’s comp is variable, and their job is on the line every quarter. The supporting roles carry less upside, but also far less risk. That’s not an accident.

What does this mean practically? For AEs, you want to give them a path to at least double their variable (and hopefully more). In contrast, the supporting team members should have much more modest upside. If they want the big bucks, they have to go carry the bag.

4. Beware of blunt instruments.

When you need to contain costs, it can be tempting to cap commissions. Resist that urge. If a rep hits their cap, you’re telling them to go on vacation for the rest of the year. It’s also a strong signal to your best performers that there’s a ceiling on how much they can earn.

There are other ways to manage cost structure without punishing success. You can decelerate past a certain point, i.e. at 300% of plan, the reps rate goes back to their base rate instead of the accelerated one. You can incorporate a gate to accelerators that makes sure that the overachievement happens the right way (e.g. you must sell professional services with the software to make sure that the customer implements). You can add terms in the comp plan agreement to do the same, e.g. you can’t earn more than your OTE on a deal that you inherited from another rep. And I’m sure there are others that I’m not thinking of.

5. Don’t be penny-wise and pound foolish.

Speaking of upside: offer aggressive accelerators for your AEs. Especially in the early days, outsized performance can have a meaningful impact on overall revenue. At the early stage, when driving growth is existential, why not reward handsomely?

I recently recommended top-tier accelerators of over 25%. The founder responded, “but is it okay to pay that much on a deal?” My answer: if they bring in $5 million of incremental revenue, that’s a very happy problem.

Sales tends to be outlier driven. A small percentage of reps can and should get those big paychecks, and those are the ones you definitely want to retain.

6. Keep it simple.

Compensation drives behavior, but only if people understand what you’re asking of them. The person receiving the plan should be able to look at it and immediately know what they need to do.

Everyone aims to keep comp plans simple, yet rarely succeeds. Here are a few ways they can get complicated quickly:

• If you have four components to your comp plan, it won’t be clear what to focus on. And the rep’s variable will be so diluted that it spreads the rep thin. (I’d recommend no more than two or maybe three elements, an “element” being something you’d quote and pay on, like ARR or services.)

• Splitting or reducing credit (e.g. if the deal is sourced by the channel the rep gets x% of the deal…) creates both confusion and friction between teams.

• Too many bells and whistles, such as multiple gates or multiple accelerated elements.

• Terms and conditions that require a law degree to understand.

7. The devil is in the details.

But, Meghan, you just told me to keep it simple? And now you are telling me to focus on the details?

In a comp plan, the details really matter. How do you pro-rate quota for someone who changes roles mid-year, or joins in October? Do you increase quotas across all currencies by 5%, or set USD as the base and convert FX? Which exchange rate do you use, and when? Do commissions pay at booking or at cash collection?

These micro-decisions add up fast, and getting them wrong is expensive. Discuss, debate, and document everything. And then you need to pick your battles, and decide which items you want to explicitly cover in the comp plan. You may even leave some items sub-optimal for the sake of simplicity.

8. Quota-setting is an art and a science.

The science: model quota coverage top-down and track your “street quota.” Top-down modeling simply means building a capacity model with the number of reps you plan to hire and your expected attrition rate. Your street quota is the every-changing sum of the quota you’ve actually assigned. It will incorporate the actual hiring and actual attrition, as well as any exceptions that you make.

The art: overall coverage is a judgment call, not a formula. Typically you want more quota on the street than your company target, but how much more quota? No spreadsheet will tell you the right answer. You need to balance making sure you have enough quota on the street to hit the plan, without making the target so unrealistic that your reps all quit (which, of course, reduces your street quota). And you need to constantly track the street quota against your plan.

9. This is a test to see if you are reading this article.

I had a bunch of candidates for the 9th commandment, including:

• Remember that people hate to lose more than they love to win

• Start by defining what success looks like, as well as what excellence looks like

• Reps are like water, they flow to the path of least resistance

But I couldn’t really settle on one, so I thought I’d add this Easter egg instead. Make a note in the comments to share which principle you think I am missing.

10. Sell the plan.

Designing a great comp plan is only half the job. You have to tell a story: not just here’s the plan, but here’s why it’s designed this way and here’s how you can make a lot of money.

Before rolling it out broadly, I always previewed it with a few people to gauge their reactions and get ahead of objections. And I’d ask the most aggressive reps how they’d “break” it. If they can find the loophole, your reps will too, and it’s better to find out first and prepare.

You need to enable the reps and their managers on the benefits of the plan. A good plan can be a recruiting tool, and the managers need to know it inside and out. And when you roll out the plan at the beginning of the year, show them the scenarios: here’s what you need to do to earn twice your OTE. Here is your path (even if highly unlikely) to earning a million dollars.

The plan is the strategy. How you sell it is the execution.

Acknowledgements: Thanks to KJ Logue for his expertise on comp planning and Graham Neray for edits and feedback.

While the latter half of my 15 year stint at MongoDB was running sales operations, I got my start as a generalist, largely focused on marketing and developer relations. You could say I was the “first GTM hire” but people didn’t really use the term “GTM” for sales and marketing back in 2010. And it was such a small team (less than 10 people when I joined) that we all kind of did a bit of everything. More on that later when we talk about conferences and events.

While it’s kind of Tim to say that I had a hand in blazing the DevRel trail, I often think that I get too much credit for the early success. It really started with the product.

The OG PLG

Dwight and Eliot made an early decision that became the basis for the company’s success: they made MongoDB open source.

Another term that didn’t exist back in 2010 was product-led growth (PLG), the idea of building your business with a product that delights customers and can be accessed without the clunky interface of a sales rep. In the years before MongoDB launched a cloud product, open source was the equivalent of a freemium model.

Downloading the software was free and completely frictionless – we didn’t even require any information from developers to download it. (The fact that downloads weren’t gated behind an email form would be cause for much consternation among the sales team, who complained that they didn’t have visibility into the people using the software. A problem that I was later faced with while running sales operations.)

At the heart of the viral adoption of MongoDB was the simplicity of the product. When I spoke to developers during many long days of booth duty at events like PyCon or JavaWorld, they spoke enthusiastically about how intuitive MongoDB was. Organizing data in tables and rows was complex, and didn’t map to the way that they wrote code. Storing data in JSON documents felt natural.

(Few people know it, but the leaf in the MongoDB logo embodied that intuitive user experience. Dwight gave the designer instructions that he wanted something that felt “natural.”)

The first-time experience was critical. Not only did it need to be easy to get up and running, but if you needed help, Eliot would typically respond to questions on the user forum in less than 15 minutes. “We can’t give people a good experience,” I remember Dwight saying, “it needs to be amazing, so that they remember and tell their friends about it.”

This product experience is the foundation for the early success of MongoDB. Making developers feel like they were part of a movement, not just users of a tool, simply added fuel to the fire.

The in-person developer community

I took direction from Dwight. Even though he was CEO, he spent most of his time coding, and he understood developers.

I was struck by Dwight’s comment about giving people an amazing experience. When I saw community members answering questions on the forums, posting on social media, or writing about MongoDB, I would reach out to thank them. Soon I was mailing MongoDB coffee mugs all over the world.

We made a list of developer events, conferences, and meetups, and started reaching out to organizers to get a MongoDB engineer on the agenda. Soon the small team of engineers (remember we were less than 10 people at this point) were getting pulled into events so much that it was eating away at their programming time. I quickly started tapping that list of MongoDB enthusiasts I had mailed mugs to, offering to sponsor them to attend a conference and speak about MongoDB. Honestly, what now seems like a brilliant hack was born out of necessity: the engineers were frustrated that events were eating into their coding time, and I was caught between Dwight’s desire to be everywhere and a team that just wanted to code. But this approach ultimately made the community an extension of the team.

That quickly evolved into us running full-day events dedicated to MongoDB. They weren’t sales pitches, but rather technical sessions from both MongoDB engineers and community members. Soon we were running events almost every month. These have since evolved into MongoDB’s .local event series.

As I write this, I am struck by the fact that connecting with people one-to-one (sending them a coffee mug) and in-person (at meetups and conferences) were such old-school, low-tech ways of building momentum. Yet they were critical to the early adoption and enthusiasm.

Going online with MongoDB University

The one-to-one approach was critical, but it couldn’t scale. We needed a way to bring the same sense of welcome and momentum to developers we’d never meet in person.

I can’t take credit for the next major marketing innovation, which was MongoDB University. My friend Andrew joined the company with the mission of launching massive open online courses (MOOCs) that could teach thousands of developers around the world.

Developers were thrilled to post their certificate of completion of the first course, M101 MongoDB for Developers, on LinkedIn and Twitter. This small piece of recognition became a source of pride for those that took the first course. And those social media posts fed the virtuous cycle, driving more virality and momentum around the product.

BTW, the last time I checked, over a million people have taken an online course on MongoDB.

There was a lot of other stuff to

There was a lot of other stuff too. Stickers mailed to university students. Answering a post on our free support forum at midnight. Posting the logo of every company using MongoDB on the docs. None of it looked like “marketing” in the traditional sense.

I think that’s the point. The early success of MongoDB wasn’t a campaign. It wasn’t a launch moment or a viral video… though the infamous “MongoDB is Webscale” video certainly helped 🙂 It was thousands of small interactions. That accumulated into a community, and the community became the engine.

(MongoDB would get a lot of flak on Hacker News for the MongoDB is Webscale video, with many developers assuming that we made the video as a marketing stunt. Another fun fact: I still to this day have no idea who made the video, but rest assured it wasn’t anyone who worked at MongoDB. )

The playbook, if you can call it that: make the product so good it sells itself, then treat every person who shows up for it like they’re part of something. The rest tends to follow.

By the time I was in high school, things changed dramatically. Times Square became a tourist hub where families traveled via subway to see performances of the Lion King.

So what happened in the early 90s to change NYC? One popular explanation is the “broken windows” theory, where the NYPD pursued petty criminals, such as turnstile hoppers, under the assumption that if you addressed the petty crimes, then everything else would follow.

My friend and former colleague James Underhill recommended a podcast that provided a different perspective from the broken windows theory. The podcast tells the story of Jack Maple. Jack was a transit cop. Now, I mentioned I grew up in NYC. I also grew up around a lot of cops. My grandfather was a police sergeant and my uncle was a homicide detective. Two of my cousins are (now retired) cops too. The transit police are not at the top of the pecking order within the NYPD. And when Jack was in the NYPD, the crime in the subway was terrifying.

Jack took a very simple approach to tackling this problem. He created a giant map of the city, and he started using color-coded dots to track crimes on the subway to identify patterns. Through this approach, he was able to pinpoint the places where criminals were more active, and deploy cops there. According to this podcast, he believed in the 80/20 rule: that 80% of the crime was generated by 20% of the criminals.

This approach worked so well that Jack was promoted to deputy commissioner. As deputy commissioner, he instituted something revolutionary, a system to capture and digitize crime stats all around the city, called COMPSTAT. Every week, he would bring the leaders of each precinct downtown to review their metrics and ask them what they were doing to improve crime in their respective neighborhoods.

When I heard that, my first thought was, that sounds a lot like a QBR! He was:

• Using data to make the invisible visible

• Inspecting leaders

• Holding people accountable to results

And what happened? Crime went down across the city. Jack was invited to introduce COMPSTAT to police departments all over the country. And we all lived happily ever after.

Not quite. Over the years since COMPSTAT was introduced in NYC, crime just keeps going down. Statistically. But is crime truly going down? The COMPSTAT system had some side effects. NYPD started measuring not just crime, but activity. Over time, quotas for activities — like arrests — were introduced. Jack Maple wanted to find the outlier criminals and eliminate them, but this approach became distorted to focus on activity and arrests.

Not only that, but the measurement began to impact the inputs and the process for collecting crime data. Police started downgrading crimes because they didn’t want their stats to look bad. “Assault becomes harassment, robbery becomes grand larceny, grand larceny becomes petit larceny, burglary becomes criminal trespass.” (NYTimes)

Why am I writing about the NYPD? Because there are many parallels in RevOps. We create processes, like logging and categorizing meetings or tracking deals in a CRM. We aggregate data about those processes, like the number of meetings and the size of opportunities. Then, we derive insight from that data to figure out how to improve the processes.

It’s possible (and common) for the relentless focus on data to result in unexpected consequences. For example, after having tracked meetings and deals, the RevOps leader surfaces data on pipeline generation in a shiny dashboard. We instruct sales leaders to hold AEs accountable to driving pipeline. But all too often, a leader uses those dashboards to “scream at the scoreboard:” they ask their AEs for more activity. The micromanage instead of coach, asking for more pipeline but without helping them figure out how to generate it. The result? Lots of low-quality meetings and opportunities that doesn’t convert to sales.

The NYPD tale reminds me of a story I always loved about sales compensation. There is a village that is overrun with cobras. So the mayor says, I’ll offer $1 for every dead cobra. So what is the result? People start breeding cobras and killing them. It’s a great example of how incentives drive behaviors, not outcomes.

The day after the conference, I signed up for HeyGen to try out Ross’ workflow. To test out the approach, I decided I wanted to turn one of Oso’s explainer pages on RBAC vs ABAC into a short video as a proof of concept. Here is what I did in my first attempt:

• I asked ChatGPT to create a YouTube thumbnail using my image

• I fed ChatGPT the blog post and asked it to write a short explainer script

• I selected HeyGen’s Photo to Video option and uploaded the thumbnail ChatGPT created

• In order for the script to sound like me, I had to create a voice by uploading a two minute recording of myself

Below is the result of the first attempt, which I would say was fine as a POC but not something that I would publish. The pacing is awkward, and without any visuals to support what I am saying, it’s hard to follow. I was also having a hard time getting the AI to pronounce RBAC and ABAC correctly (for the uninformed, it’s r-back and ay-back).

First Attempt

But I was encouraged that I was able to produce that video so easily, so I decided that I would try again. This time I used the PPT/PDF to Video option, using a template from HeyGen. I uploaded a picture of myself to use as the avatar (which ended up requiring an extra payment).

I had a lot more control using this mode. I could add pauses to pace the talk, and I could preview the voice over (though not the video) to make sure that the content flowed. I was also able to start a brand glossary for pronunciation of terms like RBAC and ABAC. (Though for some reason, the final instance of the term ABAC is mis-pronounced.)

Here is the result of the second attempt. I think it’s much easier to follow with the supporting visuals and pacing. However, my avatar is waaaaaay too excited about access control, and I’m too impatient to re-generate it to be less excited (it took about 20 minutes to create). But my skin looks fantastic!

5 key trust signals for LLMs:

• People are looking for answers, not content! Your meta description should spoil the answer.

• Use readable URLs that you can understand (like /best-goggles-for-triathletes)

• Forums with real discussion are very influential (more on Reddit later)

• Recency is also important - stuff published in the last 30 days gets 3x the weight

• Content with specific data/numbers/comparisons more likely to be cited

Instant disqualifications:

• Sites with JavaScript heavy content

• Obvious affiliate marketing sites

• Content farms

• Sites that load slowly

• Cryptic URLs

Influencing LLMs can be fast (much faster than SEO):

• The Profound presenters demonstrated how 3 LLMs gave different responses to the same query: “best CRM for a 50 person company”

• They then changed a response in a user forum on that topic, and within 3 minutes the responses from the LLMs changed

• Also showed an example from Ramp where they created two very targeted pieces that performed better than hundreds of SEO blog posts

Attribution:

• There was an agency presenter who said that some of his clients are seeing this as branding and doing brand uplift studies to measure impact

Content creation - it isn’t just about blogs anymore!

• Multimedia increasingly important: 25% of Google AI overviews include a YouTube citation and 8% include a LinkedIn citation

• Tools like distribution.ai can help you repackage content into different forms

Example workflow to create video content at scale:

• Use ChatGPT to research popular topics

• Ask ChatGPT to create a thumbnail for a YouTube video based on your selected topic

• Have ChatGPT draft a transcript for a video on the topic (or, if you have existing content, you can prompt the LLM to turn that content into a transcript)

• Use HeyGen / DID / Eleven Labs to generate the video and audio

Reddit is hugely important

• #1 influencer overall and #2 for ChatGPT

• Reddit gets way more citations than the traditional review sites that B2B marketers have invested in, like G2 or Capterra

• A presenter from Reddit team said that you should narrow your focus to 3-5 subreddits that are the most influential, lurk & learn

• LLMs look for opinionated answers and controversial cues, superlative language (e.g. “this is the best…”)

• Upvotes and downvotes matter (and Reddit is selling that data)

• Use Reddit retargeting to advertise to people on your most influential subreddits!

• This is a long game - the most cited posts are over a year old

• Community size, user engagement, and content clarity are all important, it isn’t just about popularity

15 years at a single company, particularly in tech, is unusual. Many people would ask me why I stuck around at MongoDB for so long.

When I joined MongoDB (at the tender age of 9 years old, obviously 😉 ), we were less than 10 employees and pre-revenue. As I depart MongoDB, there are over 5,000 employees and ~$2B in revenue. Each phase brought different challenges and experiences.

🌟 It wasn’t all glamorous. My first day at MongoDB we were weeks away from having the company health insurance lapse. Somehow I made sure that everyone started 2010 with insurance 🤦‍♀️

👩‍💻 Over my first several years, I spearheaded dozens of MongoDB Days events (the predecessor to the .local series), getting to meet developers around the world. Thanks Dwight Merriman and Eliot Horowitz for hiring me and guiding me as we built the developer community around MongoDB - it's one of my proudest accomplishments.

☁️ I was part of the marketing team that launched Atlas, our MongoDB-as-a-Service, which is now the main growth engine for the company.

🧮 I had the opportunity to pivot my career to lead Sales Ops about 6 months before the IPO (and while I was pregnant with my first child!). Dev Ittycheria told me “you know marketing, you need to learn sales.” Thank you Dev & Carlos Delatorre for taking a chance on me to lead this function when I’d never even seen a comp plan before. Boy, did I have to learn fast and overcome major imposter syndrome.

📈 Then came IPO day, the day every startup employee dreams of. And it was a truly amazing experience, arguably the best day of my life (my wedding day to Graham Neray is up there too 😂 ). At the time our office was a block away from NASDAQ. I attended the bell ringing and celebrated with my colleagues late into the night.

I had expected the IPO to be the end of the startup journey, but it was only the start.

💰 Leading Sales Ops post-IPO proved to be a transformational experience. We shifted the entire sales organization from a traditional bookings model to a consumption-based pricing and compensation approach. I built a high-functioning organization, largely due to the constant feedback from Cedric Pech. Thanks Ced, for always keeping the bar high - it's the best way to learn & grow.

☎️ I was also honored to lead the Sales Development team, combining my experience in demand generation and operations to build a pipeline-generation machine.

🤝 Last year I made the best hire of my career: Hacer Demiroers. I was confident that she could lead the Sales Ops org to the next phase. It felt like the right moment to hand over what I’d built in ops.

🚴‍♀️ So what’s next for me? I plan to spend more time with my three amazing kids and train for triathlons. (That new bike I bought this summer ain't gonna ride itself!) I’m not taking another operational role; I am advising early-stage startups.

Since leaving MongoDB, I’ve been working with both early-stage and growth startups—mostly B2B SaaS—on go-to-market strategy. When I left MongoDB, I assumed that I would be spending a lot of time on RevOps, since that is where I spent the last 8 years. But the reality ended up being quite different. My primary customer is Oso, where I am acting head of marketing and DevRel and getting back to my roots working with developers.

I’ve always enjoyed writing. I gained a reputation at MongoDB for rapidly writing memos — largely because I find it much easier to express ideas in writing than in slides. And it’s long been a desire of mine to share what I’ve learned. I’ve been sitting on this Substack for months, anxious about putting these ideas out there.

It’s go time!