How to Build a Customer Success Team in Six Steps: My MongoDB Journey

It was the summer of 2016. I was standing in a board meeting about to present my strategy for how I was going to build a Customer Success (CS) program at MongoDB. My heart was beating out of my chest. I was three months pregnant with my first child and had only 6 months to get the program off the ground.

You’re about to read the first steps we took to build the program. While I had experience building teams in the past, this was the first time a customer success function would exist at MongoDB. With six months to launch a successful program, I needed to prioritize the vital steps and weigh up the risks.

At the time, “Customer Success” meant different things to different people. It was a new and emerging field undergoing hockey stick growth. Before building the CS program, I restructured the early version of MongoDB’s Professional Services Program. This helped me understand the needs of our customers. The more I learned about our customers, the more passionate I became about building a CS program that would help drive our company’s growth. I noticed that we could improve our customer engagement strategy by being more proactive. This was especially true for those who didn’t interact with our technical resources like services and support.

Now, I’ll walk you through the six steps we took to jumpstart the program.

Step 1: Define what will drive your program

It might sound obvious but, as mentioned above, CS means many things. Ranging from first-line technical support to renewals management, and everything in between. However, CS cannot be a magic cure for all sales or product problems. As much as I needed magic at that time, it did not exist.

We were very deliberate in why we needed a CS program. We had three main drivers:

First, the success of our customer’s first MongoDB application - regardless of how big or small - remains critical to their follow-on adoption and expansion. Therefore, on-time onboardings and CS-driven early value creation were and still are key objectives of the program.

Second, successful software necessitates a CS program focused on continuously assessing the value of a subscription, and bringing customer input back to the engineering teams for product roadmap suggestions.

Finally, MongoDB had just launched our SaaS offering, MongoDB Atlas, but the majority of customers still relied on using our Enterprise Advanced subscription. The major CS obstacle with on-premise deployments is that there is no access to product usage telemetry other than asking customers how they are using our product. In a way, we lacked critical insights when it came to product adoption.

These three drivers helped shape the initial iteration of the CS Program. From there, we focused on gathering intel and understanding ways to scale the program in the absence of usage data.

Step 2: Start small by using customer segmentation

Today, we are a global team operating in New York City (NYC), Austin, Dublin, India, and Sydney. When we started in 2016, we were a small team of three - one CSM in NYC, one in Dublin, and myself as the leader in NYC.

Usually, the second step to building a program is to start hiring. However, I am a firm believer in building a deeper understanding of customers and their needs, before hiring new team members.

We studied multiple aspects of our portfolio to prioritize where to focus our energy. As we didn’t have telemetry from on-premise customers, we looked into current ARR, relevant use-cases and industries, potential to grow, and renewals. We also interviewed members on our sales and technical services teams to better understand the emotional state of our customers.

Step 3: How to measure CS programs without waiting for renewal rates

What originally kept me up at night were questions like, “What impact does the CS program need to deliver?” and “How will I show our board members and our CEO that our new CS function is successful?”

We knew CS would ultimately be measured on renewal rates -- typically a combination of gross and net. However, it takes a full year to measure the impact of renewal rates. Therefore, I needed to understand which operational or activity metrics such as Net Promoter Score, time to onboard, time to first call, engagement frequency, etc., would give us a sense of progress.

After multiple conversations internally and with other CS leaders at different companies, I decided to measure the adoption of key product features as our leading indicators. We started with only two product features. We collected data and measured the correlation with renewal before moving on to the next set of product features as our indicators. Overall, we iterated on the product adoption hypothesis every 4-5 months.

This type of iterative approach led to a number of surprising learnings. For example, when we asked our customers, “If you had a MongoDB Engineer next to you, what would you ask them right now?” We found that our customers had many questions. It became clear that customers thought our services team could only be of use when something was broken as opposed to being an educational resource. While this learning wasn’t necessarily a product feature, it gave us insight into the adoption of this service.

Step 4: How to find that unicorn A-player CSM

After we defined how to measure success, we turned our attention to recruiting. There are two separate skillsets customer success managers likely have — relationship-building or technical expertise. We needed to ask ourselves if we were trying to close a gap that was more on the product/technical side, or on the sales/customer relationship side.

I noticed that CS leaders often look for both skillsets in a single candidate. In my experience, these candidates exist but are rare like unicorns. When time isn’t on your side, you need to decide which profile you will seek out so that you can pinpoint the sourcing strategy and design your hiring process, compensation levels, and incentive plans.

With this in mind, I decided to look for someone who had experience in sales and relationship building. I knew that within existing teams at MongoDB we already had a good amount of product knowledge. We were missing someone who could bring product knowledge to the customer at the right time with the right tone.

Regardless of what profile you look for, having a “high tolerance for ambiguity” is a must-have skill set. When you build a program from scratch, there is a lot of experimentation that needs to come from the front lines. As a leader, you need to allow your team to take initiative by building flexibility into the organization. There also needs to be a buffer and an environment that welcomes experimentation and failing up.

Step 5: Building a self-funded CS program

Unless your CS team carries the full responsibility of renewal quota, then you need to be able to work with finance teams to define and identify the investment philosophy needed. This includes the ROI of the program, and how much CS contributed to avoiding churn.

This can be challenging because CS is relatively new, and there is not a standard way of evaluating.

For us, information around upsells helped create a solid case for CS investments. It was not our primary goal yet as CSMs built trust with customers, they were able to suggest additional features. Customers welcomed this approach because it was not a sales pitch. It was a common alignment of needs and priorities with the customer.

When the program was more developed, I came across the term CSQL (customer success qualified leads) and adopted it.

Today we still set upsell goals for the CSM team. That way the CS Program turns into a bookings generator for the company. Investment decisions became much clearer when discussed during budget cycles.

Step 6: Be mindful of constant change in the CS world

Once a CS function is built, it typically sits in the center of other key functions such as marketing, sales, product, and services. Additionally, CSMs are constantly learning about the competitive landscape and various customer trends. With this influx of information, change is a constant in the CS world. Any change in one of these pillars impacts CS strategy and execution.

Since the introduction of MongoDB Atlas, our global cloud database service, our CS team has been able to get product telemetry automatically. With these insights, CSMs became highly proactive as they understood their customers much better and advised around the right technologies at the right moment.

Secondly, we unlocked a whole new segment of customers and identified their needs and preferences. We had a rapidly growing, long tail of lower spending customers who were interested in early technical advisory, but preferred light, tech-driven interactions. They demanded their CSMs to be highly technical advisors.

With this new segment, we needed to decide if we should focus our CS program on our highest spending customers, or on our lower spending customers, which were typically a majority of who our customers were. This conversation was crucial to the success of the program and took many internal conversations to conclude that we needed both, with different metrics, different customer engagement models, and different talent profiles.

This is where we stand today as a Customer Success team at MongoDB. We are constantly growing, learning, experimenting, and transforming.

I hope that this post gives you an idea as to how we think about customer success at MongoDB. For candidates who are interested in joining our team, truly understanding the role makes our team one of the most critical parts of the company’s growth. Interested in pursuing a career in sales at MongoDB? We have several open roles on our teams across the globe, and would love for you to build your career with us!