Sales Operations, Monetization and Pricing: a chat with Meghan Gill

Sales Operations, Monetization and Pricing: a chat with Meghan Gill

Meghan Gill joined MongoDB as the first non technical hire and 8th employee. She spent 13 years scaling the company from 0 to IPO and building the foundation of all the Sales and Sales Operations of the company.

You joined MongoDB as employee number 8. What did you expect from this (then) tiny startup? (becoming a $25B publicly traded company?)

I joined MongoDB because I wanted to get my foot in the door at a tech company. I had always wanted to do something entrepreneurial, and I thought joining an early-stage company would give me a broad experience. That said, I never imagined MongoDB would have such an incredible trajectory. 

What was your initial scope? And how did it evolve?

When people ask for career advice, I usually quote Sheryl Sandberg, “When someone offers you a seat on a rocket ship, you don’t ask which seat, you just get on.” People often ask me why I’ve stayed for so long (13.5 years now!), and it’s largely because I’ve been able to take on new challenges (“seats”) in each phase of the journey, which has kept me very engaged.

Phase 1 - the first 1-2 years:

I was the first “business” hire, which meant I did everything that wasn’t software development. When I joined we had two weeks before our employees’ health insurance would lapse, so my first job was to get everyone onto a new provider. Then I organized our first “MongoDB Day” conference to educate developers about MongoDB. I also technically closed the first deal in Salesforce, since I also set up our initial instance.

Phase 2 - Marketing:

I gravitated towards working with the developer community, and spent about 7 years in marketing and developer relations. 

Phase 3 - Sales Ops:

I wanted to learn more about the other half of GTM, so when the opportunity to lead sales operations opened, I jumped at the chance. 

I’m curious: what does a ‘day in the life’ of the SVP of Sales Operations and Sales development of a massive company like MongoDB look like? 

There is a lot of variety. I looked at my calendar and here’s what I worked on today:

  • Forecast analysis comparing the bottom up call from sales leaders to a top-down model that we built in Sales Ops
  • Review of recruiting process for Sales Academy - our program to hire Sales Development Representatives through universities
  • Leading a call with the global sales leaders to update them on updates to tools and compensation policy changes
  • Discussion with the exec staff on the productivity of our Product Led Sales team

About Sales Operations

You’ve been heading Sales Operations and Sales development for 7 years now. I’ve heard the role involves a lot of work on sales commissions! Is it true? Can you share more on this topic? 

When I was considering the Sales Operations role, I asked my friend Giuseppe Incitti for his advice. He asked me two questions:

Question 1: Do you like spreadsheets? I told him yes.

Question 2: Are you prepared to spend half of your time dealing with sales compensation? I said, how complicated could it be? Boy was I naive!

Compensation is at the heart of Sales Strategy & Operations. Nothing sends a stronger signal about the behaviors that you want to drive than a commission plan. 

Our Sales Development team is a good example of how compensation plans need to evolve to drive the right behaviors. When we started the Sales Development team, we measured them on meetings, which was a good way to drive lots of activity. However, over time, we found that SDRs could overachieve on their meeting target without driving many opportunities or revenue. We then shifted to discovery-stage opportunities, and we’ve now moved even further down the funnel to incentivize qualified pipeline. (For us, that’s opportunities that are past the second stage in our sales cycle.)

Apart from sales commissions, what are your main priorities? And how is your team organized? 

Within Sales Operations & Strategy, we have a four main sub-teams:

  • Strategy & Planning - this is a team of embedded business partners. They work with the most senior sales leaders as a “mini COO” by monitoring the forecast, analyzing the pipeline, planning headcount investments, and building territories.
  • Sales Intelligence - this is the analytics function that is responsible for producing data and dashboards that are used by sales. This includes, for example, our “Metrics for Success” dashboard to track leading indicators such as pipeline and meetings, attainment dashboards to understand how the sales team is performing against quota, and productivity dashboards measuring the average output per rep.
  • Sales Technology - we have an ecosystem of sales technology, both 3rd party vendors and proprietary tools. This team manages those tools, such as Outreach, Clari, SalesDirector, and more.
  • Sales Compensation - within Sales Operations, we have a small team that designs plans, sets quotas, and analyzes results. The plan administration and payroll is managed by finance, but we work closely with them.

I listened to one of your interviews saying you have a BDR team in India. How did this decision happen? Any words of wisdom for companies considering taking a similar approach? 

We have a large presence in India, including several supporting sales functions. 

Our BDR team was the first team we built. It is a research team that supports sales by building target account lists and org charts, identifying initiatives within a target company, and executing any other research that supports pipeline generation. 

We then experimented with hiring people for supporting the sales team. That pilot was successful, and now all inquires from Sales to Sales Ops are also routed through our support organization.

We realized we needed to have higher-quality data in Salesforce for territory management. Based on our previous experiences with the BDR and support teams, it was an obvious choice to build a data quality team in India to enrich our account data.

I’ve also read that you’ve created a fantastic internal tool called ‘Argos’. What does it do? Did you try out off the shelf solutions before building your own? 

MongoDB has a massive developer community - we were one of the early product-led growth companies. Our sales team looks for “smoke” signals in an account, as in “where there’s smoke there is fire.” Smoke could include developers using our free tier, MongoDB skills on LinkedIn, and marketing engagement. 

We decided to build our own tool, Argos, because there wasn’t a vendor on the market that could combine data from Salesforce, marketing engagement, product signals, and third-party vendors to enable us to design and balance territories. Because we are a data company, we felt we were in a unique position to build that tool. Of course, all of the data is stored in MongoDB!

Do you have any recommendations for people who want to learn more about Sales Operations and Usage Based GTM? Blogs, books, podcasts? 

Usage-based GTM models are relatively new, so there isn’t a playbook on how to compensate and measure sales teams. There have been some great reports from companies like OpenView and ICONIQ, as well as articles from peer companies like Snowflake and New Relic.

The Qualified Sales Leader by our board member, John McMahon, is also a great read about building a repeatable sales process.

Monetization & pricing

There’s been a lot of love and hate about usage based billing. It can seem ‘fair’ because you pay as you consume, while other people think the cost can be out of control, and want more visibility on how much they are going to spend. 

I imagine you’ve been thinking a lot about that, how do you address this ambivalence? 

I see usage-based billing as only positive for the customer: customers only pay when they get value, and it forces the vendor to provide value consistently to earn revenue. And most of our customers have already been conditioned by the hyperscalers to buy via a usage-based model.

The approach we take is to get the customer started with usage-based billing, to minimize friction. As the customer sees value and their spend increases, we help them optimize their environment and their spend. If the customer wants discounts and predictability, we do offer commitments - but this is driven by the customer and not by a sales rep “forcing” a commitment. 

Have you made massive pricing changes in the past five years? What were the main learnings?

The key changes that we made have all been to align the customer, company, and the sales rep to the same goals. Customers are demanding pay-as-you-go billing. Not only did we need to offer that model, but we needed to make it as attractive for the sales team to sell a pay-as-you-go deal as a commitment. 

We did that by giving sales commissions and quota credit for the annualized run rate of the deal, regardless of whether the customer made a commitment. Here’s how it worked:

  • If a customer opted to pay-as-you-go, we would take the usage from the quarter and annualize it. For example, if a customer got billed for $25 in the quarter, we would credit the rep for $100.
  • $100 then became the customer’s baseline in the subsequent quarter. So if the customer used $30, their annualized run rate would be $120. The rep would earn credit for $20 ($120 run rate less the baseline from the previous quarter.

This got the sales team on board with pay-as-you-go, and massively reduced friction in the sales cycle.

Final question, and my favorite one by far: what was your dream job when you were a kid? 

My dad was a small-business owner - he was a photographer and he pivoted to a business producing photos for other professional photographers. He inspired me to want to do something entrepreneurial in my career, which is what I think led me to join an early stage company like MongoDB.

Two hosting options, same benefits

Whether you choose the cloud version or decide to host the solution yourself, you will benefit from our powerful API and user-friendly interface.

Open source

The optimal solution for small projects.


The optimal solution for teams who want control and flexibility on cloud or self-hosted version.