MongoDB, Inc. (MDB) Earnings Call Transcript & Summary

Good morning. Thanks for joining us today. I'm Jack Andrews, I cover the data analytics and infrastructure software space at Needham. And we're very pleased to have MongoDB here with us this morning. We have Michael Gordon, the Chief Operating Officer and Chief Financial Officer; as well as Serge Tanjga, who is the VP of Finance and Business Operations. So welcome, gentlemen, and thanks for taking the time to chat with us today.

Thanks for having us.

Maybe just sort of starting off at a high level on the database market. I mean this is arguably one of the largest markets in software. When you think about the rate of change and what's happened in technology over the last 20 years, it's been truly amazing. But yet in the database market specifically, the top 3 vendors in terms of market share in the year 2000, when we think about Oracle, IBM, Microsoft, they're still market share leaders today. So given that the database market has been so stable for such a long time, it seems like a lot of change is finally afoot. Could you just walk us through, what are the new pain points that are arising in the database world and what is giving rise to all the innovation these days that you're able to take advantage of?

Sure. And again, thanks for having us. So you're right, the database market, one of the largest in all of software, per IDC's numbers, $68 billion in 2020. And their forecast is that number will grow to $106 billion in 2024. So a very, very large market opportunity. I think one of the important things though that's a little bit different about the database market than some of other markets in software is it tends to be less monolithic. And by that, I mean, any customer, any enterprise doesn't only run one database, right? So typically, you would expect 1 enterprise will run only 1 CRM or only 1 HRIS or 1 ERP kind of general ledger system, and that exists for the whole company, right? The marketing team is on a different -- human capital software than the legal team. Databases are different. Databases are done at the application level, and large enterprises can have thousands or tens of thousands of applications. And so that tends to lead to lots of applications that are across, and therefore, you can have companies that have more than 1 database. If you think about the market and the evolution, that $68 billion today is very large, but not every dollar of it is, to your point, creating an RFP today, right? Not every dollar is making an annual purchase decision of do I stick with Oracle or SQL server or not. And so I think that's part of what leads to this longer duration evolution because companies don't pivot on mass and switch vendors. It tends to be application by application. It's part of the reason why Oracle is so sticky, right? There have been challenges and there have been newer technologies many different times along the way, trying to threaten or challenge their lead. They've had very strong hooks. I think two things are different sort of this time. One is our technology and the document model where we can sort of talk about that in detail if you want to, but also the fact that we've been able to garner the developer attention, right? So MongoDB is the database developers most want to work with. And I think the combination of a better technological mousetrap, combined with developer enthusiasm, mindshare and those kinds of things has allowed us to sort of chip away in some sense customer by customer, really application by application, that the lead that some of the big folks have and sort of break in, while clearly we're very small in the grand scheme of the market, we're starting to build a level of critical mass on our own that people are paying attention or focusing on as we continue to compete for workloads. What we're winning is we're winning, of course, the new applications that are coming to market, right? And if you think about that growth of that $68 billion to $106 billion, it's effectively $9 billion to $10 billion a year of new business, right, which is the most popular modern general-purpose database, we're exceptionally well positioned to tackle and fight for. And in addition, you've got sort of the $68 billion of sort of incumbency legacy workloads. And I'm sure we can have a long debate around product life cycles and things like that. But if we just sort of assume a 10-year life for the simplicity of math, that's another 6.5 -- $6.8 billion that's coming to market every year. And so there's roughly $15 billion, $16 billion or so that's kind of up for grabs. And we're obviously disproportionately winning share in that, which is kind of how we've gone from nothing several years ago to where we are today. So I'll pause there because there's a lot there, but hopefully that's helpful context.

Yes. There is a lot in it, and I want to go to a little bit more some of those topics in detail. But just sort of starting off, how do we think about -- maybe given sort of the, as you described it, we'll call it database fragmentation, different databases for different use cases. Where is the sweet spot today for MongoDB? Where are the use cases that are strong opportunities for you to lay on new customers these days?

Yes. I think that the reality today, given the success and the investments that we've made in the product over time, is it's really any use case. And I think that's one of the things that's differentiated about MongoDB, is the general-purpose nature of what we do. Obviously, we're not the only player who saw a very large market opportunity entrenched decades-old incumbents and with putting on your good sort of capital is that you would expect that opportunity will set or that framework to attract capital. And so we're certainly -- we're the only one 10 or so years ago to think of this or try and do this. I think what's different and the reason that we've had success is sort of break out relative to everyone else or succeed in the prior years where XML and other technologies didn't is the strength of our technology and the general purpose nature of what we do. And so the reality is you could take any application, some new, highly scalable application, very large gaming or e-commerce application, but you could also take back-office billing applications. And so we've increasingly, over time, what we've seen is, as we built out the product, just the breadth of what we can cover as a general-purpose database really covers the landscape. And so the issue tends to be more from a customer perspective, where is their greatest source of pain, right? New applications again are fairly easy to think about if you're building some new application. But if you think about the existing applications, systems of record, things like that, you generally wouldn't choose to replatform them if you didn't have to, right? I mean if you're thinking about it being a business leader, CIO, CTO, line of business head, CEO, whatever, developers have become one of your most important resource and expensive resources, right? We -- you hear these phrases of software eating the world and every company becoming a technology company. That's shorthand for the fact that companies are competing on the basis of their technology, which is really their software. And at the heart of those software applications is the database, right So the scalability, agility, nimbleness of the database ultimately determines your competitive advantage. And so you wouldn't choose to replatform or redo applications if you didn't have to. But what we find is the trigger point is less about, oh, MongoDB is good for this use case. It tends to be more, oh, I have this issue, this app isn't scaling, or I can't innovate quickly enough on this customer-facing application or this system of record. And that's what catalyzes the migration from one of the legacy players to cause someone to incur the effort to replatform. Because again, I don't think you'd voluntarily just to choose that to do that. You'd always rather add new feature functionality or advance your own road map.

Right. That makes a lot of sense. And so just continuing on this theme, I think it was a few months ago at least that Oracle actually introduced a document database. And so I wanted to get your take on what the significance of that is for MongoDB. Is this sort of a potential new avenue of competition? Or is this actually more of a stamp of approval for you in your technology?

Yes. I think it tends to be more of the latter, sort of an acknowledgment of the success that we're having. Oracle, certainly, in addition to their classic traditional relational database has certainly continued to try and add new products or more modern approaches or modern-sounding technology. I think the fundamental issue is customers. At least I haven't met any customers who are looking to expand their sort of Oracle footprint. But I do think that it is definitely an acknowledgment and endorsement that what we're doing is not only having an impact, but is real. And it's a little bit surprising that they would take that step because obviously they've sort of resisted for a very long time, and it's sort of a -- you can think of -- we've talked about different analogies internally and haven't figured out exactly the right way to do it. But it's a little bit like the manufacturer of Kleenex rather than saying like, "Stop sneezing," they say, "Well, you should really be taking Claritin because that will make your problems go away." So it's -- but I think it's acknowledgment of the relevance that we have and the efficacy of the solution we have.

Sure, sure. So just sort of summarizing this together. We've talked about database fragmentation, different databases for different use cases. But at the same time, it seems like MongoDB clearly can serve as a general-purpose database. So when we think about this $106 billion market opportunity in a few years that you referenced, I mean, how much of that do you think is truly available to MongoDB today?

Yes. So I would go back to the sort of math I was doing before. I think from a technical perspective, all of it. From a practicals perspective, in the sense of, like I mentioned, not every dollar is doing an RFP, it tends to be more of the math that I kind of walked through earlier. I think the biggest challenge that we have, and we've sort of talked about this before, but I think the biggest challenge that we have is our footprint coverage is so small in terms of sales coverage and go-to-market, relative to the opportunity. You can see from our disclosures that our -- and conclude that roughly our sales kind of quota-carrying headcount is in the low hundreds of people. And this is measured against competitors that have sales forces in the thousands or tens of thousands. We talked earlier in the year about how we don't even have coverage in all the U.S. NFL cities, let alone major geographies with large IT spend budgets around the world. And so our biggest risk is deals that we're not in or not aware of. When we are aware of a situation or opportunity, we do quite well. Our competitive win rates are very high. The risk for us, it's just we're not in enough discussions or considerations because of our footprint. And so we try to leverage partners to extend that reach. And obviously, as you can see from the numbers, we've been continuing to invest in building out the go-to-market reach year-over-year, and we'll continue to do that.

Right. Well, when we think about where you are finding and capitalizing on opportunities today, can you just give us a sense as to how much is greenfield market opportunity? Meaning how much are you leveraged to brand-new applications versus how much are more of the displacement opportunities with legacy applications? I mean where is that today? And how do you see that mix trending over time?

Yes. So we see a very healthy mix of that and have for the last several years. And I think that underscores the general-purpose nature of what we do. We try throughout the earnings calls and sort of like some of the customer case studies or vignettes to give at least a sense of color and flavor. And so we'll talk about a large European telco replacing Oracle -- sorry, not telco, large European utility replacing Oracle with MongoDB for their billing system and things like that to give people a sense and flavor for sort of some of the use cases. I think what we saw is at the time of the IPO, about 30% of our new business was coming from relational migrations, relational replacements. That business has only increased. So year-over-year, we're seeing very nice increases in the dollar amounts of new business that we're winning. It's gone down slightly as a percentage because Atlas tends to be mostly new workloads, not relational migrations. But I think it's a very balanced and very healthy mix. And we focus less on the absolute percentages, but ultimately, because we're trying to capture the whole market. But really, if you look at the continued success that we're having, both on new business as well as relational migrations, I think both are areas where we tend to thrive. And really within any customer dialogue, it just tends to be where is the greater, more immediate opportunity? If I go back to this thought of where footprint-constrained, not opportunity-constrained, what you'd want is you'd want those salespeople pursuing whatever deals were most accessible, right? Like you wouldn't want them disproportionately spending time on a legacy replacement. If it wasn't about to happen or wasn't a pain in the app, they'd just sort of be banging on their head on the wall for no reason, would artificially inflate the sales cycle, their productivity would drop, as opposed to being rigorous and diligent about their qualification and where are the right opportunities within any given set of accounts.

Right. No, I appreciate that. So I want to shift gears a little bit on the technology side of things. You keep winning awards for the "Most Wanted Database." And I wanted to see if you could just drill down on what is really the secret sauce behind that. I think the latest stats are you've been downloaded over 130 million times, something along those lines. So just given that there's only maybe 30 million software developers on the planet these days, just how have you been able to gain such a strong following in the developer community?

Yes. So I think, ultimately, it comes back to the product and the technology. It's just the most easy and intuitive way to work with data for developers. And so I think the simplest way to talk about it is the advantages of the document model relative to -- which is our model, relative to the legacy historic relational model. The relational model of databases organizes things in tables of rows and columns, very much like a spreadsheet on steroids that your audience will be familiar with. And the reason why that was organized that way, it's not because that's how anyone would actually choose to organize their data. But the reason you do that is because back in the day, in 1970 when the first white papers were written in late -- in the '70s, in '77, when Oracle was founded, it's because storage was exceptionally expensive, right? And so the goal was to store things as efficiently as possible. And the sort of nontechnical analogy that I found most helpful is if you rent a parking garage, the most efficient way to store cars would be to disassemble them, right? And put all the fenders with all the fenders, all the tires with all the tires, all the steering wheels with steering wheels, and you'll get many more cars into your garage. And that's effectively what relational databases do with the data. The challenge is when you want to use the data, you have to go reassemble everything. And you have to remember, okay, this is the front tire and where I put it. I put it in column -- I put it in this bay B78, I have to go look for it and find it. And so if you're a developer and if you're programming in modern object-oriented programming languages, which is the dominant programming languages, you'd much rather interact with a document, which is our model, which is an object. And so if you just think about the ease of use and reducing the tax that a developer has to pay for sort of managing that cognitive load of what is my data structure, what is my data schema, where do they organize everything, as opposed to sort of the simplicity of the document model. At the highest level, that's probably the easiest way to explain it.

Yes. I haven't heard that analogy before, but that's a good one. So I appreciate that. Let's continue on this line of thought, your co-founder, Eliot Horowitz, left the company, I think it was middle of last year. And you have a new CTO, Mark Porter. I know he obviously has this very strong and deep background in the database role. But could you just speak more broadly in terms of what do you think his philosophy is in terms of just product development? And should we expect any changes just in terms of the cadence of product introductions and things of that nature?

Yes, sure. Yes. So I would say, at a headline level, no fundamental changes. I'll give a little bit of the context. So first of all, obviously, sad to see Eliot go. But you can understand, after 12 years as a founder and everything else, I totally understand and support him in that. We've not planned on backfilling him. But Mark Porter, who's our now CTO had -- was on our Board. And obviously, we recruited him to the Board because of his deep expertise in databases, first in Oracle, then at AWS. And then he was CTO at Grab and had a great customer perspective as well. And so brought Mark on to the Board. And then over time, a few months after Eliot announced that he was going to step down, Mark raised his hand. And so I think of it very much as a point of continuity. He's been steeped in the company, was obviously on the Board, believed in the product and the technology and the strategy. And so I think of it very much as one of sort of continuity as opposed to radical change or redirection in prioritizations or approach.

Right. Okay. And then could you -- I just wonder if you could expound maybe just on how the growth of Atlas has impacted your overall R&D efforts. Since Atlas runs in the cloud, does this allow you to basically gain better insights into how customers are using the product than your historic Enterprise Advanced? And I'm just wondering if there's any examples of new features that you've been able to introduce in Atlas or MongoDB more broadly just from sort of monitoring this customer behavior and usage patterns?

Yes. I think the best way to think about it is, we shifted a couple of years ago, the product road map to being what I would call more sort of cloud first. And you're right, it has some very distinct advantages. First, you can orchestrate the way that the products work together, right? So it feels more like a platform. There's a better integration and user experience. Secondly, you can get much faster feedback, right? Rather than working in a vacuum, trying to identify and hope that this is what we think customers want and then we ship it, you get very real-time feedback on which features are being used, what's being adopted, where people not having as much success or is the path not as intuitive. And so you can kind of continue to iterate much more quickly. That helps us both get better product out the door, better product out the door faster. And ultimately it also makes our R&D dollar more efficient because you're doing it based off of real live information and so you can invest in the areas that drive the greatest level of -- it's more information-based as opposed to sort of instinct or intuition or focus group-based way of doing it. You've got real hard data. And I think that's been an evolution over the last couple of years and has had a positive impact.

Right. And so when we think about some of the recent product functionality you've rolled out, what do you think we should be keeping an eye on from an investment perspective that could really move the needle for you in the financial statements? I mean how should we think about the impact of things like Full-Text Search, auto-scaling, Atlas Data Lake? How significant are these in terms of the overall impact on the trajectory of the business?

Yes. So most of these will show up in the Atlas line item. If you think about it, ultimately, they're not -- so the things you just described are not necessarily separate products for which you charge, but they're going to drive incremental consumption, right? So Full-Text Search allows someone to use their MongoDB application. Search is such an important part of many applications. And rather than having to stand up a third-party search environment where I'm dumping data out of my application into my separate search capability, and now I have to -- in addition to manage my application, I have to manage the search functionality, and I have to manage the sinking between the 2, right? So there's sort of 3 different things that I have to manage, which adds complexity. Now you just have to use one. We don't charge you separately for that, but you want -- consuming more Atlas as a result. And so I think from a financial perspective, most of these things will tend to show up in and under the Atlas line item. Search, Realm, Data Lake, all these kinds of things will ultimately drive more Atlas consumption.

Right. Okay. So I want to shift a little bit to the go-to-market side of things. You've had some really remarkable new customer additions in the last couple of quarters. I mean you're actually accelerating new customer adds in the pandemic here, which I don't believe I'm aware of any other software company that's been able to do this. So you've talked on your earnings call about changing compensation structure for your salespeople to perhaps incent new customer adds. But -- that's fine. But can you really tell us about what's really driving these extraordinary new customer adds in this macro environment?

Sure. Yes. I think the big picture backdrop goes back to the comments that we started off at the very beginning, which is this is an incredibly large market and we're very fractionally penetrated. And so we continue to iterate and turn dials and flip levers on the go-to-market with the goal of accelerating our ability to cover that footprint. And so we've made some changes prior to COVID, obviously, as we continue to sort of tweak that. One of the changes that I think has maybe gotten a little undue attention or maybe too much attention is sort of what you're referring to in terms of sales compensation. The way I would describe it is it was less about putting an incentive around things and more about reducing friction. So previously, the way the comp plan worked, as a sales rep, I got paid on the contractual committed amount from the customer, right? And so my incentive is to maximize that upfront commitment that someone is making. As an application owner, as a customer, that's a little difficult, both because maybe I haven't even run the application before and so I don't even know how much we're going to consume, and so how do I think about how much to commit for. And b, some of the cloud players have sort of acclimated me to thinking about cloud services as being more consumption-oriented. And so you, asking me to make this commitment in advance when I don't even know what I'm doing, doesn't really make a ton of sense. So it doesn't really feel very cloud-oriented. And the impact that, that was having is that was creating a lot of negotiation, a lot of friction in the dialogue and, ultimately, sort of impeding the sales cycle, if you will, because my incentive as a rep was to sort of maximize that upfront commitment. Instead, what we've done is we've enabled -- it's more about actually the billing than the comps sort of flows out of the billing, is that we made a change internally where we would -- someone could have an initial commitment and then they could keep consuming and we would just bill them for the amount that they're -- once they exceeded their commitment, we would just have a way of billing them for their incremental kind of consumption. And so now the conversation can be rather than me focused on getting you to sign up for an 80,000 commitment, you can sign up for a 50,000 commitment or a 30,000 commitment or whatever it is that you're comfortable with. I get you consuming. You're then still going to consume that 80,000 or 90,000 or whatever you were going to consume. And as you continue to consume above your initial commitment, the rep is wind up getting -- gets paid, right? Whereas previously, they didn't have a way of getting paid that they'd have to go back and negotiate another contract with the customer, et cetera, et cetera. And so the result of that ultimately is faster sales, less friction on the sales, right? So increased deal velocity, higher sales productivity and, hopefully, also incremental customer satisfaction because they didn't have this protracted haggling session where I felt like you're trying to commit to some much bigger number than I was prepared to commit for, even if that's where my ultimate consumption winds up being.

Sure. Sure. No, I appreciate the context around that. So just a follow-up, I recognize it's early, but are you seeing any maybe similarities or differences in terms of just the use cases of this initial group of new customers? I mean should we think about this group maybe expanding in a similar rate over time as your past cohort? Or is it too early to tell?

Yes. So I guess the big picture is that it's too early to tell. But let me sort of give you a little bit of more context in terms of how we will eventually evaluate the growth of these customers. It's no different than any other cohort. But key to our strategy and value maximization over the long term is less about the land, sort of that initial transaction, initial workload, and much more about the sort of the subsequent expand that happens in finding incremental workloads inside those customers and convincing them that that MongoDB is the best platform to launch it on. And as you can imagine -- and we talked about this a little bit in the beginning in Michael's commentary on the market. The market -- the database market is quite fragmented inside a single customer. So think of it almost as a confederation of workloads. And every one of them is sort of incremental sales effort. And we, obviously, over time, try to accumulate as many of them within every customer as we can. So -- but as you think about that expand motion, that plays out over years, right? As the customer gets to MongoDB, gets comfortable with the quality of the product and sort of how their first app is running, and frequently, sort of the cadence of conversations around expanding what we do together, it has to do with the annual renewal cycle. So it really won't be for a while that we know -- that we will know the long-term potential of the customer that we acquired this year. And -- but that's true every year. What we can say is that we have no reason to assume that they're different, I guess. And then the other thing that we do know for a fact is that we've acquired them at a lower cost, right? Because our CAC is lower because our sales costs are reasonably constant between one quarter or another. And the growth -- the number of customers that we acquired has expanded quite significantly.

And the only thing I'd just quickly add is to the point of even if they were different, we haven't taken any risk in the sense of we're only paying the sales rep for what they actually consume. It's not like we've sort of preemptively modeled out and prospectively paid someone and sort of taken some risks around that. And then secondly, I think also related to Serge's point is while the customer count gets the headlines and a lot of investor focus, ultimately, when we think about the sales productivity model, we think about the sales rep and the rep as a unit, we're thinking about how many new dollars are we getting out of that rep. And that's sort of without regard to whether that's a lot of customers at a small amount or a few customers with big amounts. And so what we know is that the actual incremental dollars that they're driving are very strong and accretive to sales productivity.

Sure. No, I appreciate that color. And then just to follow up on that. Could you update us in terms of some of your partnerships with the large global systems integrators? I know that you've got a number of them who are scaling and building up their own MongoDB practices. But could you sort of just talk about what benefits you are seeing? Are they helping you broadly? Are they helping you more on just the legacy modernization opportunities? What's been the impact from some of those partners for you?

Yes. I think the overall help broadly, if you go back to an earlier point that we're footprint-constrained, not opportunity-constrained, they're a great way to help extend our footprint. I would say that they are valuable across the board. They do tend to have broader practices and tend to find greater opportunities for themselves in the replatforming and kind of app modernization, digital transformation side of things, where you're replatforming existing applications because that tends to drive additional services for them, which is kind of their core bread and butter. And so that tends to be kind of incrementally valuable to them, but I wouldn't suggest that we exclusively engage with them on those situations. But I think that's one where the win-win math is even clearer.

Right. Okay. And then just to -- want to ask about the sort of the public cloud vendors and your latest take on how you interact with them. Is this sort of a coopetition type of situation? Given that, obviously, you're driving workloads to these clouds, but at the same time, some of them have introduced their own document-related databases. How do you think about navigating the relationships there?

Yes. There's definitely competition as well as partnership, so coopetition, frenemy, whatever mash-up phrase you want to use, applies. And I think that, that's pretty typical. I mean if you're offering infrastructure software, you're going -- you're certainly going to compete with the big cloud players. I think what's important and we've been pleased with is I think there's a recognition of the popularity and relevance of MongoDB, such that each of the 3 hyperscale players have actively wanted to partner and been effective partners with us. And I think that they also recognize that they are much more competing with each other than they are competing with us. And I think there's an acknowledgment and understanding that the database layer, in particular, is so sticky that if they can lock workloads into their cloud using our database, that's valuable to them. And I think when you think about that overall, that's sort of an important factor to consider in the dynamic. So yes, I want to stop there.

No, I appreciate that. So just to put a fine point on it, I know that MongoDB can run in any cloud. But are you -- do you care where it's utilized? Do you have preferences or anything like that?

No. No, no, no. So I think a couple of things. So not only can we run in any cloud, but we recently introduced cross-cloud. So it's the first time that you can actually run a specific application across the cloud players, right? And I think the other piece of it that's important to understand is most customers, certainly larger enterprises, are very afraid of vendor lock-in. And so that platform independence is critical, particularly at the database layer, because they understand how sticky that database layer is and they've gotten burned before with other providers. And so picking a proprietary cloud vendor database is very concerning to most customers because it's relatively easy to move the applications from one cloud to another. It's very hard if I have to rewrite my application. And certainly, we've only made it easier to port from cloud to cloud or run across cloud by introducing cross-cloud capabilities. And so I think that's sort of another kind of piece of the puzzle.

Sure, sure. Shifting gears a little bit. I just wanted to ask, now that we're sort of 9 months into this, just about the impact of the COVID-19 pandemic on MongoDB. I'm just curious, from your perspective, mean what changes do you think are going to be permanent to your business as a result of the pandemic? What changes do you think are temporary today? What do you think are going to go back to some sort of normalization over time?

I think a lot remains to be seen. And while we've executed well, I certainly wouldn't suggest that next quarter is going to look like this past quarter or the quarter before in the sense of if things continue to change and people kind of continue to evolve. But I'm incredibly proud of how the team has performed and how we've executed against this sort of challenging environment. I think we've certainly learned ways to be more efficient and do things in a way we hadn't expected, which is great. And hopefully, we'll keep some of those things. I think people will want to have some semblance of returning to an office. I think obviously, people want to meet in person with customers. I think people will want to travel, but probably not travel as much. It seems unlikely that people will do the magnitude of travel that they used to. They'll just realize that there are more efficient ways and they've gotten more used to doing video conferencing and everything else. So I don't know if there are any unique aspects that are unique to our business versus what most of corporate America is sort of thinking through. But I guess the other thing I'd say in terms of like the raw business piece is, I think, unrelated to how we run our operations at a more macro level, I think the -- this sort of pandemic and the sort of forced experiment of working home and everyone else is sort of highlighting the need for people to modernize and innovate more quickly. And so all these things that were secular tailwinds for us, I think, get accelerated. And so whatever you thought the future was 3 to 5 years from now, I think it's more optimistic and brighter than in a pre-COVID world even though the current period is challenging, and -- but we've been succeeding through it.

Sure. No, absolutely. Let me just wrap things up here. Last question. We're in a new calendar year, you're going to be wrapping up your fiscal year shortly. Just can you talk about what are your priorities here over the next year? And what's the hardest problem that you're working on right now?

Yes. So obviously, there's a certain arbitrariness to the calendar. And suddenly, just because the calendar flips to Feb 1, our priorities don't suddenly change. I'd say there are a handful of things that we continue to work on. First is scaling the go-to-market side of things, given the opportunity that we have, that continues to be incredibly important. And certainly, we're aware that there are many other companies that have not executed well on that as they've grown their go-to-market organizations. And so I think that's an important piece of the puzzle. Secondly would be continuing to scale and build those self-service muscles that we've talked about. I think third would be, increasingly, there's interplay between those 2 and figuring out how do we get more efficient and effective across that. And then the fourth would just be scaling R&D. There aren't that many companies that have built truly world-class engineering orgs. And again, that's not trivial either. Different sets of personalities, as you might imagine on the go-to-market side, but a significant area of focus and investment. And then, of course, the backdrop of all that is scaling everything else and managing a culture amidst the remote environment and trying to make sure people don't just think of their job as showing up on a Zoom screen every day, just given all the challenges that we're currently going through.

Sure. Makes a lot of sense. Well, we are just about out of time here. So we'll leave the conversation here. But thank you so much for joining us today. Really appreciate your perspective and thoughts on the company.

Great. Thanks for having us, Jack. And good luck on the rest of the conference.