MongoDB, Inc. (NASDAQ:MDB) 24th Annual Needham Growth Conference Call January 10, 2022 11:30 AM ET
Company Participants
Michael Gordon – Chief Operating Officer and Chief Financial Officer
Serge Tanjga – Vice President Finance and Business Operations
Conference Call Participants
Mike Cikos – Needham & Company
Mike Cikos
Great. Thanks. So, for everyone who is tuned in now, we currently have MongoDB management team. We have Mr. Michael Gordon and Mr. Serge Tanjga. Thank you for joining us today.
Michael Gordon
Thanks very much Mike.
Question-and-Answer Session
Q – Mike Cikos
Absolutely. Absolutely. Looking forward to a great fireside today. For any of the listeners who are tuned in, if at any time you guys have a question or should be at chat box, where you can also make questions and I will do my best to make sure that we address those during this time.
With that behind us, and we will just extend out of the way, guys thanks again for joining us. Can you just provide a quick overview of MongoDB and the company’s value proposition just to serve as a baseline understanding for our listeners?
Michael Gordon
Sure. Just to give a broad context. So, we compete in the database and application data platform arenas. And so, really the easiest way to think about this, especially for the non-technical folks in the audience, is that, increasingly companies are competing on the basis of their technology, specifically their software for their customers. And at the heart of every software application is the database. And the database is what determines the agility, scalability, and ultimately the speed and pace of innovation that the company can execute.
So, if you think about these phrases, like — excuse me — software’s eating the world or every company trying to become a technology company, those are all sort of code names or shorthand for talking about how the fact that companies are trying to drive competitive advantage from their built software. Obviously, all the off-the-shelf software is available to everyone, so that doesn’t really provide much of a competitive advantage, but it’s the software that you build. And the database is at the heart of each one of those applications.
And the problem that we’re solving is historically, relational databases have been the core technology choice of companies and they were great, 40, 50 years ago they were pioneering and solved a number of the problems of the day. But today the managing of that data is the biggest problem for developers and that’s what inhibits their speed and their ability to innovate quickly. And so, what we do is we’ve got a modern developer-centric approach that makes it much more easy for the developer use, much more intuitive than the old legacy models that were built before mobile, before social, before the internet, this is all sort of designed to be cloud-friendly modern and everything else. And so, it’s part of the reason why we’ve been able to have the success that we’ve had is this.
We’re tackling this very, very large market. The database market is one of the largest in all of software, $74 billion in 2021, going to $121 billion in 2025. And we’ve got this very large market. We have this exceptionally strong and unique and differentiated product that makes it easier for developers. And the result of that is it was sort of won the hearts and minds of developers. And so our — the database that developers most want to work with. We’ve paired all of that with really good execution in the field to build on the success and kind of capitalize an opportunity.
Mike Cikos
Awesome. Awesome. Thanks for that, Michael. And in this database market that you guys are now attacking, who are the primary competitors that you’re seeing? And maybe if you could split it up between some of the more legacy guys coming from that application focus versus some of the new up-and-comers.
Michael Gordon
Sure. Sure. So, if you think about that $74 billion market that I talked about today, like the largest wallet share is with the incumbents that would be typified by companies like Oracle and people like that. There’s certainly a crop of new relative to the Oracle — new players like MongoDB, who’ve come at the opportunity, and have observed this very large market that for decades was really not disintermediated and with your good capitalistic mindset, markets like that should draw capital, should draw competition. And so we, along with a bunch of other people, saw that opportunity.
I think we’ve been the most successful really the only one that’s sort of broken out and kind of had any kind of meaningful, critical mass of success. And again, I think that really is because of the strength of our product, the differentiating features, and the fact that developers love it, that sort of developer-centric aspect to we do. And the developer popularity that we have, and then all of that very good execution.
And then the third bucket of competitors would really be the cloud players, right? So, these are folks who are increasingly trying to provide lots of different layers within the infrastructure software stack. I think the database layer, in particular, has been interesting. And ultimately what we’ve seen is while there’s certainly a competitive angle with each of the big three hyperscale players, we’ve increasingly seen them taking a more cooperative approach recognizing that, of course, they have competing offerings, but that we at MongoDB bring a lot to the table. I think there are kind of two important aspects that to understand there.
One is that customers, particularly large customers are hypersensitive to vendor lock-in and because the application is built on the database, the lock-in or the stickiness of the database layer is even greater. And so they’re very reluctant to build on cloud proprietary databases because that will lock them in more broadly to that cloud player. And so, there’s sort of generally an openness MongoDB because we’re multi-cloud in addition to being able to run it on prem or running on your laptop, or however you want to.
And then also the cloud players themselves see the additional pull-through or drag along, or however you want to characterize it of the stickiness of that workload, that even if they’re not getting the database layer, they’re getting a whole bunch of ancillary services and value. And so, over time we’ve seen that relationship evolve. There’s, I think, always going to be a competitive angle, but also increasingly cooperative.
Mike Cikos
That’s great. That’s great. And it sounds like the cloud providers really — this more, I guess, cooperative effort is just based on the fact that from drawing an analogy, it’s almost like you guys are the splits being able to play multi-cloud. And then their understanding that once the workload is there, they can still recognize services on top of that. But feeding into both sides of the equation between the cloud providers.
Michael Gordon
Yeah. And they get the underlying storage and compute from us as well, in addition to sort of being able to sell the value-added services. And I certainly wouldn’t want to pretend, I mean, obviously they prefer to get every layer that they can, right? But I think there’s an understanding of the popularity of the product superiority, and ultimately, from a customer perspective as a heightened degree around vendor lock-in then I think sort of often carries today.
Mike Cikos
Coming back to the TAM, because I know we had some comments before about that database market being $74 billion growing to $121 billion. Could you walk us through, I guess, how much of this market is coming from this more relational database looking to improve or to find some of the latest technologies on that? I guess, how much of that market are you addressing in addition to that?
Michael Gordon
Yeah. So, the way that I think about it is from a technical standpoint, the entire market is available and addressable. But that doesn’t mean that every workload will instantly or should instantly move over to MongoDB. I think that the database market is different than many other markets. In the sense of, if you’re buying HR — an HRS or HTM software, you’re buying an ERP or a CRM or something like that, those tend to be monolithic across the organization. Meaning that the legal department doesn’t run at a different set of HR software then than the HR — then the marketing team. Applications are different, right? And a large organization will have thousands or tens of thousands of application. And each application will have its own database. And so, a company — just because we win an account, we talked about Verizon in the third quarter earnings call or back in early December, that doesn’t suddenly mean that Verizon — every application within Verizon runs on MongoDB, right? It tends to be much more sort of workload by workload. And so, I think that’s sort of an important backdrop to the NAMIC [ph].
And so, what that means, if you think about the numbers that are shared in terms of the industry spend $74 billion going to $121 billion over five years, you’ve got sort of more than $10 billion — roughly $10 billion a year in new applications, right? Most of the new growth — most of the growth is a new application. And so, there’s sort of this, $10 billion, $11 billion chunk, that’s up for competition every year and then we can have a debate around what’s the life cycle of the legacy span, right? The $74 billion that people are being spent today. And just for simple math, 10 years, we know product life cycles are certainly shrinking. But that probably means there’s another seven, and change of that which replatforming every year. So, in terms of like the actionable or addressable piece, it’s in that sort of $17 billion, $18 billion, $19 billion a year that sort of in play. And certainly we see — given MongoDB as the most popular database and the database developers want to work with, we’re very well-positioned for new applications, but we also continue to see a lot of legacy applications, that are just having challenges with relational who want to move and need to move to MongoDB.
And so, if you look at our product line, MongoDB Atlas is the majority of the business. That’s our database as a service that tends to be new applications, given that those are either new applications because they’re native to the cloud or they’re being rebuilt. And so they’re mostly kind of considered new.
Enterprise Advanced as our self managed product and about a quarter of that — it obviously varies and fluctuates quarter to quarter, but roughly a quarter of that business tends to be replatforming of legacy relational applications. And so, we’ve always found a healthy mix of both is valuable, but certainly from a technological standpoint, we could do the whole thing. It’s just if you have application and it’s working just fine, there’s really no reason for you to want or need to replatform that. I think that with my CFO hat on, engineers are a precious resource at any given organization and I’d always much rather have them do new features, new functionality, new capability, and improving user experience rather than rebuilding something existing, right? You go back to rebuilding something existing when it’s just not working for you, right? And mean that’s when we went of solving some of the problems that relational causes.
Mike Cikos
Understood. Okay. And I think one of the things that’s interesting, and maybe as a backdrop here, but in this market, there just seems to be a ton of disruption that we’re seeing versus even 10, 20 years ago. What is fundamentally changed that the legacy vendors can no longer solve for? Can you walk us through the major pain points that Mongo was really solving that those are the vendors can really address today?
Serge Tanjga
Yeah. Why don’t I think that one, Mike? So, really the story begins 15 years ago, and the story of MongoDB, but also the story of sort of increased innovation in the database space. And the reason is because that sort of timeframe coincides with Internet 2.0 with Google, with Facebook, with other applications that sort of reached a whole new level of scale. And frankly, that’s also the founding story of MongoDB and our founders came from double-click. And these are companies that just had requirements for their application that are different — orders of magnitude different than what came beforehand. And they became obvious that the relational technology, the legacy relational technology was not going to be sufficient frankly to solve the challenges of the application of the future.
And so, the realization that the application in the 21st century effectively are going to require a different underlying database architecture underneath. And what Michael was talking about sort of this idea that in the world of capitalism markets will attract competition meant that literally dozens of companies were founded and received significant funding to go after this market and go after this market in a way that is, to try to solve the problems that relational couldn’t solve. And those problems were difficult for developers to work with problems scaling and real problems distributing data, in other words, not built for the internet age. And so, a lot of innovation happened again, starting sort of 15 years ago.
A lot of companies were finding — they were introducing different models, different ways of sort of building the database. And we were one of them and we focused on the document model, which is at the core of what MongoDB is all about. And what — much are the companies that we — that sort of came to — that crop of companies try to do was sold for the problems of durational of a sort of throw the baby out with the bath water. Meaning, leave the good things behind that relational headed. Don’t forget it’s technology to work for a long period of time. If that technology that’s still the vast majority of the dollars spent in the database and the database industry. And what we do is different. We try to marry the best of both worlds. So, we tried to solve for developer productivity. We try to solve for scalability, performance, data distribution, but we also understood that there’s actual guarantees, rich query functionality and a number of other sort of features that are sort of table stakes for relational technology. We needed to bring to bear as well in order to be seen as a mature enterprise ready platform, that can handle the most demanding workloads.
And frankly, that’s the story of MongoDB over the last 15 years, just sort of continued investment behind the original idea, that was going to solve for problems that are relational, but continue investing in order to make sure that the platform is enterprise ready and sort of the market share that we’ve been able to gain and the sort of the distance we put between ourselves and all the other newcomers in the case that was sort of the — that was the right strategy. And also that we executed really well against it. But there was this sort of — what should we call it? There was a problem in the market. A lot of people try to solve for it. And there was almost a fragmentation of the market because a lot more offers were put there in the market, because customers were struggling and they were willing to try any number of these new vendors. And that’s sort of that fragmentation is with the market’s been going on for the last 15 years.
Mike Cikos
So, that’s actually hitting on like the next — the absolute next item I wanted to touch on with you. And we’ve been discussing it as well. This database fragmentation based on the various use cases, the technologies, the vendors, in your view — given this has been taking place over the last couple of years now, is this fragmentation a good thing or a bad thing? And over time, do you see consolidation towards a single vendor again, or we just passed this tollbooth and this fragmentation likely persists.
Serge Tanjga
So, I’ll speak to it from the point of the customer, because that’s who we ultimately want to listen to and sort of adjust our approach based on what the customers tell us they want. Customers don’t want more database. Customers don’t want a net new database for every new workload, because with that new database comes increased complexity of the backend, increased data siloing, and actually turns to then slow down the developer, because now that developers need to sort of context switch between a variety of different technologies, and you’re not maximizing the resource that’s most scarce in today’s world. That’s your developer time.
And so, we understand why fragmentation happens, and we see this sort of pendulum swinging and technology over and over again. There was a problem. There was a dominant technology. It was 100% share of relational, whatever 15, 20 years ago. It became obvious that that technology had limits. We had innovation to solve that, and customers were adding key value stores graph, graph databases, time — in any number of other technology — time series databases, any other technologies to try to supplement their relational estate. But that was because they needed to solve their burning application front end issues while increasing the complexity of their backend. And so, where we think is going to go, and frankly, the bet that we’re making is that customers actually want to run a fewer general purpose databases rather than more specialized niche databases. And that’s what we think is the appeal of MongoDB is that we’re the best application for all, but relatively small number of very, very specialized and niche use cases.
So, we are betting on this pendulum swing the other way in the market. So, away from fragmentation, which is kind of gone too far and back towards consolidation where you’re going to want to have a modern standard on which you are going to deploy majority of your modern applications. And you’ll still probably have a relation with standard as well, because that’s still the largest state that will likely stay in the enterprise for a long period of time. But the customers will go away from this approach of new workload for — that application for every workload only because they understand that the tax that they’re paying in terms back in complexity is enormous.
Michael Gordon
Yeah. I would just describe it. That’s what we see in the market what we’ve seen for years. I wouldn’t quite characterize it as sort of a bet or some future state that is divergent from the existing state, is more just sort of what we benefit from in the market, given that people don’t want to have a net new application for every new — sorry — net new database for every new application. There really — there are benefits to standardizing and I think Dave and Serge and I have talked about in the prepared remarks in the earnings calls, this sort of progression that accounts go through where they start to become — they declare MongoDB a standard. And we’re one of the few technologies that has the potential to broadly be declared a standard, really across the board is sort of like the modern alternative.
Mike Cikos
Right. Okay. And if that is the case, how would you best describe the use cases where Mongo resonates best in the market? And are there specific use cases that you think are more utilized for, let’s say a new customer land whether it’s by vertical, by geography, how do you think about those use cases for your database specifically?
Serge Tanjga
Yeah. I think that was either more true for us several years ago or is more true for some of the other would be challengers, if you will. But I think part of the reason why we’ve had the success that we’ve had, is this breadth of use cases is the general purpose nature of what we do. And so, there’s certainly other players who — to surgeon’s description saw the challenges of relational came up with a solution, but could only do this type of use case. And so, in some ways that’s easier, right? Because they can then go train the Salesforce and be the hammer that looks for all the nails out there that they can find.
Ours is a little bit different because of the general purpose nature of what we do. It’s really the full suite. And so, you’ll see every flavor of applications. You can find single view of a customer, content management and transactional and like all different flavors. And so, it’s a little more challenging in a certain sense for our Salesforce, right? Because they can’t just sort of like quickly with them, the universe say, okay, here are the things that are going on within this account that we can’t do. And so, let’s look and see if we can find the one or two things that we can do. It’s a good thing overall in terms of the breadth and scope of the opportunity. But there is a little bit of an incremental challenge sort of prioritizing and finding out and everything else because you’re — you can’t just go look for the one use case that you do really well.
Mike Cikos
Okay. And I know we’ve hit on the developers by being able to make sure they’re using their time efficiently and helping them scale to the best of their abilities. Can you help us understand the go-to-market approach for MongoDB? Maybe any detail on how the pipeline looks today and interweave with that? I know I’ve gotten a couple of questions around the potential impact from the Omicron variant given where we are today.
Michael Gordon
Sorry, I muted myself. Yeah. So, the go-to-market has got a couple different aspects to it. We — there’s both a self service component, which lends itself nicely to sort of the developer led motion, but also a direct sales component and the direct sales component. Well, there’s sort of increasing — segmentation is best described as having sort of two flavors, sort of a inside sales kind of mid market model that would be familiar to folks. And then an enterprise model and that’s field focused on the largest customers Fortune 500, Global 2000, kind of people like that.
And so, there — it’s a little bit given the MongoDB is open source, right? So, people can use it on their own, whether they’re using a free cheer of MongoDB Atlas, whether they’re self-serving into becoming a paid Atlas customer, or whether they’re downloading a free version from our website, or any of the other repositories out there and just getting started and going to use it. So, the situation is then trying to find opportunities where people either want to run it as a managed service, which is our Atlas product. Or if they’re in a — if it’s a larger organization, that’s probably less cloud forward, it’s more — they might need help or want to think about how to deploy MongoDB broadband. So what the sales team is looking for — is looking for activity and looking for pockets of the signals. Obviously with Atlas, the database and service, we have many more signals than we used to have.
So, we used to only know sort of who downloaded it. And then we’d have to do a lot of exploratory work within the account to understand that maybe there was activity, maybe someone asked for a white paper, maybe someone attended the webinar and try to figure out and triangulate where the activity is. Obviously, it’s with — the database is a service offering. We have many more in product signals that are getting better about harnessing those. But over time, what we’re seeing is that all the channels are working better together, sort of effectively more in concert, which sort of originally conceived of the channels, particularly the self-serve and the direct sales is a little bit more separate or discreet. And we’ve increasingly gotten more effective at finding ways to sort of interact those, right?
So, we talk about Atlas. And while the self-serve — when you look at the customer accounts and the sort of implied revenue and everything else is larger, I think it’s easy for people to sometimes forget that the majority of self-serve customers or majority of social revenue started out — sorry — the majority of Atlas revenue started out as self-serve, right, was self-served source. But the majority of the expansion occurred while it was in the sales team’s hands. And so, I think we’re sort of increasingly getting better and more effective at how to leverage those two together.
Mike Cikos
Okay. And anything that you guys are seeing currently as far as impact the pipeline, or as a result of this Omicron variant, or is that not really shown up just yet? Or is it not expected to show up? Sorry, let me, rephrase it.
Michael Gordon
Yeah. It’s funny. So, I’d say a few things. Obviously, Omicron most showed up over a lot of the holiday periods, so certainly a little too early to tell. But if we take a broader step back, we’ve been fairly consistent, certainly folks who’ve been followed the company will know that we’ve been quite deliberate in and transparent and trying to describe the impacts that we’ve seen throughout the many waves now of COVID starting with the March 2020 call that we did where we describe the outlook, quantified the potential impact on the horizon that we saw from COVID, the primary impact being concerns around the ability for the Salesforce to close new business, right? And sort of concerns about new business.
One of the things we said most recently in the December call of this past year reporting our Q3 results, was as we look out on the Q4 guide, certainly at that point, we didn’t obviously know exactly what Omicron will take us. But it was very clear that there continued to be lots of uncertainty in the market around COVID. But now we had several quarters of having dealt with that uncertainty. And so the risk related and uncertainty, our judgment was lower than it had been previously, because now we at least had some data points, where sort of — despite the uncertainty, we’ve been able to sort of manage through all of that. So the uncertainty continues to exist. Omicron just being the latest. But I think that we’ve developed a level of confidence and conviction that the sort of risk of the businesses is smaller than we’d previously sort of identified and quantified in terms of forecast and guidance, and things like that. As a result of the fact that we clearly executed successfully and beyond our expectations for the last several quarters.
Mike Cikos
Great. Great. And turning back to the customer base, can you help us think maybe from a strategic standpoint, how is it you think about growth whether it’s forming your existing customers or an approach towards, I guess, acquiring new logos, just given this massive market opportunity we’re talking to, how do you guys strike that balance?
Michael Gordon
Yeah. So, I think what we’ve prioritized is a healthy mix of both. And if you think about an individual sales rep, they have a certain territory and because as we described at the beginning, the database market isn’t monolithic, and once I’ve won an account, I’m sort of getting all of the workloads within the account. There’s a very, very large opportunity to continue to expand within an account even after that initial layer, right?
So, the simplest quantification to offer was to go back to the IPO several years ago. And what we talked about at that time was that we had just over half of the Fortune 100 more customers, right? And I think it provides a neat little example to help people understand, what that means from a customer count standpoint is that you — the best you could do is not quite double your customer count, but at the time, our estimation was that we also had less than 1% mark — wallet share from that set of customers, right? Which means that you could increase your business with them more than 100 X, right? And so there’s this landing — given the size of the market, landing new logos continues to be important, and we continue to do well at that. But there’s also a lot of opportunity just within the existing accounts that we still have, given that the way the database works — market works is more sort of application by application. And so, we’ve talked about and help people try and dimensionalize this in a few different ways.
Another way that we’ve talked about it, that’s maybe helpful as we — if you look at our customers that are our largest customers, right, our largest 50 — our top 50, top 100, customers spending over a million, whatever way you want to sort of like conveniently kind of slice and dice it. What you’ll find is, there a minority of those customers, where we really have very, very high market share, right, high wallet share, right? They’ve affected — these tend to be exemplified as sort of newer businesses, cloud native businesses that have built the entirety of their business on MongoDB. And so, there’s not a lot of incremental in those accounts, opportunities for workloads, but we’re benefiting from their growth as a company or as an application. And then that tends to be the minority of those largest customers. The vast majority of those customers are, again, the Global 2000, the Fortune 500 customers where even though they’re a seven figure relationship or one of our top customers, or however you want to slice and dice it, we’re probably still single digit market share or wallet share within their database spend, again, just sort of underscoring the magnitude of the market opportunity that we have, and the fact that it tends to be more a workload by workload, even when you’re sort of a standard in the accounts.
Mike Cikos
Terrific. Terrific. And probably more competitive question here, but I’m thinking about the technology behind your database. Can you walk us through the advantages of how you guys have architected the solution? At this point I would think that it’s not so much in evangelical sale. But do you think that that architecture the way that you guys have been built resonates in the market today? Or is there still more to do on that front from an awareness standpoint?
Serge Tanjga
Yeah. So, at the core of how we organized our architecture is sort of the data model that you use. So — and we sort of — I’ll juxtapose us versus the relational technology. So, relational technology is based on rows and columns. They could be the Excel on steroids, where you have data organized in tables and multiple tables pointing to data, to other tables, to pull information together, to represent whatever needs to be represented. By contact — by contrast, we’re organizing the document model. And so, usually information on a single entity is all placed in a single sort of locations in a single document. So think of it — you think of an application that needs to store an information on a customer or an employee. So, if you need to have first name, last name, address, credit card number, and whatever other characteristics you’re going to take from that customer in our relational technology that’s going to be distributed across a number of different tables. Whereas all of it is going to be in a single document for us.
And so, why would that be the case? Why was the technology that was started in 1970, built around the concept of rows and columns and tables at that point to one another versus different technologies, including ours that is used today. Relational was trying to solve in the 70s and 80s when the technological was started for the constraint of that time. And the constraint of that time was expensive storage. So, what you wanted to do is repeat as few times as possible data because that data would take space on a storage disc and that was very, very expensive. So that’s why they created this elaborate systems or multiple tables that point to one another in order to every single piece of information or capture only once. It would be the equivalent of — if you had a garage and you’re trying to park as many cars in there as possible and disassemble the car at the entrance of the garage in order to maximize the space of the number of cars that you would need to put in there.
Fast forward to this century, storage is effectively free or heading in that direction. That’s no longer the dominant constraint. The dominant constraint is how quickly you can innovate based on some of Michael’s comments. So, when you have all the data around an entity or an object in a single place, that means a few things. Number one, it’s much easier to add to that document. You could add incremental information, incremental categories, incremental metrics, statistics that you want to keep on the customer, as opposed to in a table where it’s not just about updating a single table, all of them need to be updated and all the relationships between them need to be updated. That’s extremely complicated and taxing.
Second of all, if you’re trying to grab quickly information on that customer, because they’re pinging your database for something, instead of going to many different places to grab various features of them to bring their profile together all at once, you’re all going to the same place and getting it quickly and therefore delivering a better customer service. So that’s why — those are some of the major advantages of the document bottle, data that is access to get a restore together. And that means that developers can innovate faster and the application can deliver the data back to — get the data from the database faster because of the way that our technology is organized. And also ours is easier to scale, because distribution of incremental documents is relatively simple compared to scaling of this enormous labyrinth of data tables across many more customers.
Mike Cikos
Got it. Thank you for that Serge. And I didn’t want to come back to the go-to-market as well. I know that Michael was talking to this developer led engagement alongside some of the Salesforce, more traditional Salesforce teams that we would think about. When you guys are seeing these channels line up, I’m curious, are you seeing some of the conversations in the market, maybe shift to a different persona as these purchases are taking place, or maybe more of your leads beginning higher up in the market, whereas is it expected that these two channels are going to stay about where they are, and continue to work alongside each other as you guys look to the future of the company?
Michael Gordon
I think they definitely work together. I think that what I would say is increasingly over time, we’ve had, and we’ve called this out, I think, and even some of the earnings calls, more and more C-suite level dialogue, right? As you wedge or break into an account, there tends to be a specific application, either an existing application or a new application. That’s important from a launch perspective to the business, that isn’t working, right? The relational isn’t scaling. It’s too brittle. They’re not able to innovate quickly enough. And so they want MongoDB in this sort of point of pain. And then within an account, we tend to repeat on that success and use that first application as an internal reference account. You build up more momentum, you get a little bit more awareness, and then you start to see some broader adoption and then ultimately it gets — there’s a higher level conversation that involves some level of — usually a C-suite dialogue that involves some level of standardization.
Then one of the ways we’ve sort of talked about this and said initially, you have to sort of break in the side door. And that’s our first application. You then develop a relationship and you’re working more broadly in the account. And then you’re sort of invited to the front door, and people like finance and procurement sort of other organizations or functions within a big larger organization evolve. And then eventually it becomes a strategic relationship. And then you’re sort of move to the loading dock, where you’re more central or you’re sort of integrated more effectively. You’ve been declared a standard. Adoption becomes much — the topics become much broader. There’s still work to do. It’s not like suddenly you become zipped care [ph] to standard and then like just the orders flow. There still is a sort of an application by application workload by workload, dialogue that needs to go on, but some of the barriers from there.
Mike Cikos
Terrific. Terrific. And I’m looking — we are just about out of time. Then when I don’t know, I have about a half dozen more questions for you guys. I have to leave it there, unfortunately. I do appreciate the time, and thank you very much, guys. Good luck with the rest of the conference and to everyone listening in. Thank you everyone very much for your time as well.
Michael Gordon
No, thanks for having us. Really appreciate it. And both of the session and the conference overall, so thanks everyone.
Serge Tanjga
Thank you.
Mike Cikos
Terrific. Thanks guys.
Be the first to comment