From Free Open-Source Database to a $20B Enterprise Data Platform | MongoDB SVP of Product, Andrew Davidson | E242

In this episode, Carlos Gonzalez de Villaumbrosia interviews Andrew Davidson, Senior Vice President of Product at MongoDB.

MongoDB is the most used modern database, powering some of the largest companies across industries like financial services, healthcare, and manufacturing. Originally launched as a free open-source project in 2009, MongoDB went public in 2017 and has grown into a $20Billion dollar enterprise data platform. 

In this episode, we’ll discuss how to incentivize team members to grow within the same company for a long period of time, the key product milestones in MongoDB’s transformation, nurturing a developer ecosystem, using AI to accelerate code deployment and scaling in the cloud, building 3rd-party integrations with over 100 partners, and allowing companies to integrate with MongoDB as they create their own data stack.

Key Takeaways👇:
- Empowering Developers with AI: Andrew emphasizes that leveraging AI can significantly enhance developers' productivity, enabling them to manage complexity more effectively and build applications faster.
- The Importance of Open Core Models: He advocates for maintaining an open-source version of MongoDB, ensuring accessibility for developers while adding value through premium features.
- Continuous Learning Culture: Andrew highlights the necessity of fostering a growth mindset within teams, encouraging collaboration and knowledge sharing to drive innovation.

Social Links:
- Follow our Podcast on Tik Tok here
- Follow Product School on LinkedIn here
- Join Product School's free events here
- Find out more about Product School here

Brought to you by:
Sprig, a product experience platform that generates AI-powered opportunities to continuously improve your product at scale. Sprig AI captures your product experience in real-time through Heatmaps, Replays, Surveys, and Feedback studies, instantly analyzing all your product experience data to generate actionable insights. Join product teams at Figma and Notion by uncovering AI-powered product opportunities at scale. Visit sprig.com/productschool to book a demo and get a $75 gift card.

Credits:
Host: Carlos Gonzalez de Villaumbrosia
Guest: Andrew Davidson

Transcript

Andrew Davidson (MongoDB) (00:01)
Carlos (Product School), great to be here. Thank you so much for having me.

Carlos (Product School) (00:04)
Andrew, I noticed that you've spent most of your career working in tech in Silicon Valley and New York. However, you spent a year in Bangladesh helping advice on energy infrastructure.

Andrew Davidson (MongoDB) (00:15)
Yeah, yeah, I had a great experience there. I had grown up in the San Francisco Bay Area and an opportunity came up. Actually, an ex of mine did research there and I went with her for a year. Yeah, it was incredible. It was like going down levels of abstraction and almost in some sense back in time to see a city that was really building the foundational layers of the onion. For me, was a real opportunity to think outside the box and to be exposed to something new. Also very inspiring to see just what they're doing in place like that, absolutely.

Carlos (Product School) (00:50)
And I read an article you published on Forbes that was talking about your experience there and how you were trying to leverage technology to combat climate change. And so I'd love to get your takes specifically around AI and how this new technology can be applied in an emerging economy.

Andrew Davidson (MongoDB) (01:09)
Yeah, mean, you know, the thesis of that article is perhaps a bit controversial, but it was kind of the idea that a lot of people talk about the significant energy requirements going into these data centers right now. And data centers are growing like crazy. And so the energy required is growing a lot too. People focus on that quite a bit. But I think if you take a step back, it's important to understand that we're in an interesting time. As of a couple of decades ago, and this largely correlates with the rise of the internet, the GDP growth for the first time has decoupled from those energy inputs. And that's kind of an exciting thing. It means the digital economy is opening up ways for us to have livelihoods. This is good example of that. Without necessarily needing to have it be physical inputs. And so I think we can lose sight of the forest through the trees that Gen. AI and many other innovations are going to make it possible for us to build new concepts that allow us to experience different kinds of meaning that will basically both change our lives in many ways, but also grow our economy. And it'll be a continuation of that same trend. know, data centers are a very tiny percentage of overall energy consumption today. While they will grow, they're going to remain a very small percent, but the GDP impact that we'll be feeling will, I think, be significant.

Carlos (Product School) (02:27)
I also think it talks about your care for things beyond just tech, beyond the bubble that sometimes we live in. I live in San Francisco and obviously we all hear about GNI applied to something which is important, but I think what you are describing is also arguably even more important.

Andrew Davidson (MongoDB) (02:46)
Yeah, mean, when you think about what is tech, that's why I describe it as in some ways it's like going back in time if you live in a place like San Francisco or New York to imagine what it was like in New York 100 years ago when they were building the subways, for example. Or even more fundamental things, like when you go to a place that perhaps doesn't benefit from foundational urban design capabilities like sidewalks, say. Once you realize sidewalks are optional. Then you start realizing, holy moly, the value of sidewalks being there that I've taken advantage of because maybe I didn't know that those were optional. It makes you realize, wow, something that's so fundamental to my quality of life. Instead of having to compete with cars all day long, can walk in a sidewalk. When you realize that there's tons of things like that that you have to sort of fight for and innovate with to build into your society, in a place like Bangladesh where they're doing that every day. It is kind of inspiring, it's also exhausting to realize how much just has to be built up. And I think it's important in the West or in these developed economies to not take for granted all these layers of abstraction that you kind of rely on every day and to recognize that you have to kind of fight to keep it up.

Carlos (Product School) (03:59)
Well, Andrew, I want to switch gears a little bit and talk about your experience at MongoDB. You've been there for 11 years and for whoever's been under a rock and doesn't know about your company, please tell us more about what it does.

Andrew Davidson (MongoDB) (04:12)
Sure, so MongoDB is a modern database. Fundamentally, it's all about saying there's got to be a different way to build modern applications with a data model that represents how people want to build today. I think if you're a software engineer, you know that applications are fundamentally a business logic tier and a stateful database tier.
So every application has behind it a database. And so this is a huge part of the economy that's somewhat hidden away. It's a very large market, roughly $100 billion annual revenue in the database segment. And yet it's so hidden by virtue of kind of being abstracted away by all the software we use. So we are a modern participant in that space. Our founders from the very beginning believed that there's just a different way to think about data, to use a document model that resembles JSON, if people have used JSON or document oriented objects in their code, it should be a natural way for developers to think about data with rich structure and shape to it, with flexibility to it. But on the back end, it should be a truly elastic distributed system that gives it something that really is built in natively for cloud that allows you to power many of the largest applications in the world.

Carlos (Product School) (05:30)
You've been at work for 11 years. are currently the SVP of product. So first of all, know in jobs in tech usually don't last that long. What was your rationale to find that fire and stay there for so long?

Andrew Davidson (MongoDB) (05:44)
Well, you know, it is interesting that the database segment is incredibly long-term in its orientation. I have to say, you know, what we have been disrupting here is this operational transactional database idea that, you know, previously came out of the 1970s of relational tables, the idea that you would always join objects across a bunch of tables. And so, you know, we kind of came in 40 years later with this new idea, you know, saying, there's got to be a new way to do this.
But because this part of the industry is so entrenched and so slow to turn over because it just requires you to rewrite software applications in fundamental ways, this is one of those very rare segments where you could grow for decades. And so, you know, still, I've been at MongoDB for 11 years, it's true, but I still feel like we're only at the end of the beginning. And it's kind of wild to think that way. We only have, I don't know, ballpark 2%, maybe 3 % market share, if you can believe it.
So there's this incredible continuous set of challenges that has kept me excited. I think as we've grown the company as well, we've been able to bring in incredibly talented people. And I've always felt that there's just this learning opportunity. Each time someone new comes in who's done something before, to be able to learn from them, to open doors for each other, we have a very strong growth culture at MongoDB. One of really ensuring that everyone's always learning. We're always building together here. It's a key part of our company value.
I think all those things and just that sense that, wow, there's such a huge opportunity in front of us. There's so many hard problems to solve with mission critical, uptime, core, fundamental aspects of our customers riding on top of us that we just can never stop investing in. That's what's kept me committed.

Carlos (Product School) (07:29)
One of the major milestones I can imagine is when your company went public. I see in 2017 and you joined in 2013. So we love to learn from your own experience. How did your job change now that you are a public company?

Andrew Davidson (MongoDB) (07:48)
You know, it's interesting that you ask that. I'll say, actually, you know, we tend to, that's an exciting milestone, but the biggest changes were, were almost different from that particular milestone. The biggest changes were, you know, when I first joined MongoDB, we were very much an open source company with an early monetization strategy on a de-risk value prop for IT operations. We were trying to figure out, can we find IT operations teams that are looking to have sort of management tooling to augment and make safer to run these environments that app devs had just built on top of our open source core platform with. And I think that was a good way to get started in building a business. We were able to build a strong business, but to be honest, if that's all we had done, we would have plateaued. So we made this major shift in recognizing we have to go up a level of abstraction and build an as a service, fully living breathing true SaaS model for the database. And we had to do that in a multi-cloud way and do all the hard work to bring that to bear. And I think, you know, if you were to look at our revenue mix shift, you know, initially we had this traditional software base that was, again, that de-risk value prop. It was very hard to sort of build this startup within the company that was doing SaaS and to take them both seriously. We luckily had sort of a top-down alignment on the importance of that.
And it actually took us five years of really focused work to become a majority SaaS revenue company, that product being called MongoDB Atlas, our database as a service. And so I would say, the most important shifts that happened in the company were starting out as self-managed software with important tooling that we could sell to enterprises, then shifting across a five-year horizon into an as a service Atlas offering. We went public soon after the launch of Atlas, but really it was that five years of work that transitioning the company end to end into being SaaS forward, that was the biggest change.

Carlos (Product School) (09:48)
That's so interesting. By the way, I was going to ask you that right after. So like, damn it. But it's true. mean, that's a big part, right? You started as an open source only database. And then I think it was around 2018 when you decided to add this additional tier and have an enterprise offering. So what is, what's going on now? Like, well, how do you think about allowing this type of free tier open source with also a paid enterprise version?

Andrew Davidson (MongoDB) (10:15)
Yeah, mean, we think that anything that is in fundamental developer infrastructure, it needs to be the kind of thing that can be free forever to use anywhere in the world because people just want the power to understand it. They want the power to run it locally, and they want the power to run it in production if that's how they want to be. That ubiquity, especially for something as fundamental as database, we think that just has to have that open core model to it.
If it isn't everywhere, we're going to have a problem. In fact, we've added innovations, for example, in our SaaS service MongoDB Atlas that we hadn't been able to bring to that open source version yet. But we were excited earlier this year to announce that our search and vector search capability, one of the most strategic enhancements we had added into Atlas that wasn't there yet, that will be coming to MongoDB community in the near future. So I think it's based on this idea that you have to be everywhere and that in a way it's the ultimate customer guarantee. The customer always has the choice to go use that and you have to really add so much value on top of it. For something this fundamental, that's an important differentiator.

Carlos (Product School) (11:29)
Yeah, and I have a question around go to market here because if you have two distinct offerings and when you are now serving an enterprise client you see specific use cases as you mentioned right now you can decide to bring them to the extended community but are there situations where you see the other way around that say something going on at the open source level that you decided to also move up market and offer to enterprise service in a slightly different way.

Andrew Davidson (MongoDB) (11:55)
I think in general, the good news, or the way we think about it is, the open source world that is highly complementary to us, that's always evolving actively, that's just almost like this incredible Petri dish of Darwin evolution, is the area that sits in what I'll refer to as the app tier above the database. In other words, there's so much innovation happening in how people build applications, whether it's the rise of Node.js as a backend stack with the mean stack and then the Mern stack and now Next.js and other innovations or what you're seeing in the Java ecosystem or what you're seeing in the .NET ecosystem. Basically, all these open source developer oriented ecosystems, they pull us forward in a way that is complimentary to us in incredible ways. I think it's easy to sort of, the reason I bring this up is it's easy to get kind of self-focused and focus on, hey, what matters is us. But really in many ways what matters is what's happening in those ecosystems. And you have to ask yourself, are we something that can easily be plugged in there? Is it just so obvious that if you're building in that layer we would be dragged along? If not, we have a big problem to solve.

Carlos (Product School) (13:08)
And how are you thinking about AI and machine learning in this new stage as a way for your product to continue evolving?

Andrew Davidson (MongoDB) (13:17)
Yeah, so mean, there's so much possibility here. You know, I think we look at it kind of from a couple different levels, from like a first principles level. One of the key disruptions that's happening or innovations that's happening is software developers, thanks to this Gen. assist capabilities are going to be able to write more applications more quickly than ever before. The way I think of that is kind of a continuation of this idea that if computers are bicycles for people's minds,
Well, Gen.AI as well as MongoDB and Cloud in general, they're all bicycles for the developers' mind. The developers thinking about building these incredible cathedrals in their minds. Like we as product people, we work with these software engineers, right? We kind of know that they have this enormous complexity in their minds that they, you know, and you can see how it, that's why one solo developer sometimes can build incredibly fast. And then once you start introducing a team, there's always that fundamental, you slow down, but that's how you bring about some ways of scaling in other ways, right? Well, I think when you think about developers, a lot of what they do is manage complexity. And if they can abstract away lower level plumbing and move faster, they'll just do more. So I'm optimistic that Gen.ai will open up way more applications being built and new use cases. Now, I think we're still early in the new use cases. Like we've got great customers that are out there doing really interesting things. Like, you know, one of our customers that we talk about is Novo Nordisk, the creators of Ozempic, they've been able to massively reduce the amount of time necessary for their clinical study reports thanks to GEN.AI. Really cool use cases. Cool. But if you think about what they're doing there, it's fundamentally summarization. And I think what we'll see is over time, there'll be more and more use cases that go far beyond what's possible today as GEN.AI becomes fast, cheap, and therefore high throughput and at scale. In many ways, we're the at-scale high-throughput people. And I think we're still early days there. But what we're leaning into quite a bit is the power of our vector search capability, which is a critical part of retrieval log-managed generation, as well as memory for agents, which is, these are kind of key use cases that operational data is critical to. You need to have your own business data, your own application data. It needs to be in real time, put to use with the power of GEN.AI. And that's what's possible thanks to that open composability we were talking about a moment ago.

Carlos (Product School) (15:40)
I'm seeing more and more of that. I I come from a technical background, even though I can't claim to be a good engineer by any means. But it's true that I'm seeing that transition now with more technical folks spending less time doing the thing and now asking AI to do it for them, which gives them more power. And of course there are situations where they still want to tweak certain things. But I think what you were talking about, deploying cloud environments faster by leveraging what already exists, just being able to move faster with new technology. It's in itself a huge, huge improvement, even if there are no new or any new cool use cases yet.

Andrew Davidson (MongoDB) (16:19)
Totally, totally. I mean, this is very much related to Jeevan's paradox, which goes back to the energy topic, where Jeevan's paradox is this idea that essentially as you lower the cost of energy or make energy usage more efficient, paradoxically you end up using more energy. And the general reason being that it makes it possible to do things that weren't possible before, so you go do those things.
All of these innovations are going to open up things that weren't possible before, and all of a sudden we're going to do more things and unlock more value because of them. We're still early with GEN.AI, obviously for software development acceleration, there's some really good fits. We've been able to bring incredible natural language to query capabilities into our developer tools. We've been able to show that GEN.AI can help lower the activation energy required to modernize from legacy environments by helping to rewrite queries, helping to remap schemas, and eventually probably helping us to analyze code bases and rewrite code bases. So you can just see where all this is going on the app dev side. But then on the application and use cases side, mean, sky's the limit. It's just so early.

Carlos (Product School) (17:25)
Let's talk about that application layer side. I was checking out your website and I saw so many partners. You call it partner ecosystem. So as you think about scaling your own platform, what's your rationale behind providing integrations with specific partners and also build a thing yourself?

Andrew Davidson (MongoDB) (17:44)
Great question. We go back and forth on this. I think everybody does. It's really tricky to know what's the right area to focus on. And I think, you know, it is fundamentally incumbent upon you to always ask, are the things that I must be excellent at, are they fully appropriately being invested into? Or are you finding yourself chasing the shiny object? We can all be guilty of sort of, wanting to talk about something new. But the question is, for the things that fundamentally are your core, in the database space certainly it's things like security, durability, availability, performance. Are we where we think not only we need to be today, but are we going to be where we need to be a decade ago? Are we doing the necessary work to get there? And I think only if you feel like you have all of that sound can you then even contemplate whether you have an appetite to expand the appetite. Of course, that's assuming you have strong product market fit already and all those. So that's where we are anyway. And I think, you you separately have to ask the question of will customers want you to be in that space or are they going to love having an ecosystem of alternative offerings that are complimentary to you in a way that if you were to go after it yourself might cannibalize that beautiful ecosystem that is so great for customers. I think that duality of are we investing in what matters to our customers most for us? And will our customers love us going in that direction or not? If you can't easily answer those questions, you shouldn't even be thinking about expanding yet. You gotta really get your house in order.

Carlos (Product School) (19:18)
Yeah, and I think another benefit of providing integration is that you can test the waters in a cheaper way. And if it actually works, you can always revisit and decide if you also want to invest in building that capability in-house.

Andrew Davidson (MongoDB) (19:30)
Totally. You know, and I think for us, it's particularly nuanced one because in many ways the front end, it's one thing if you're a SaaS productivity tool, let's say, like you log into a website and there's lots of different widgets in there. While we have that in our kind of control plane for our database service, the real, the fundamental front end, if you will, of MongoDB is very much the database client itself. The thing that the software developer uses in their code to interface with the database.
And so it's almost, I like to think of it almost as like the primacy of that front end. Like if that's really the main conduit through which people experience value in our ecosystem, you know, we can add things in totally, but first and foremost, we're kind of adding it in that context. And that's pretty nuanced when it comes to like what it would mean to sort of expand. And we've done that with search and vector search. I mentioned those earlier. Those were like great examples of us explicitly adding into our developer front end into our query language, search and vector search primitives that are just natural parts of the database. But on the back end, they're operating on independently scaling separate software, essentially, that's kind of hidden away. And that's why we hadn't yet brought those to our community offering we're going to. But that was an example of us making that decision. That's not something we can just push to a partner. That is fundamental. It's inside the database. And if we're not investing in it, we'll be really seeing an existential risk there.

Carlos (Product School) (21:04)
And one of the things that I like about what you're saying here that hits home is that sometimes making what works just better is an improvement in itself and it's not always about just building the next thing.

Andrew Davidson (MongoDB) (21:19)
Yeah, mean, we as product people can get excited, right? We want to announce the next big thing. We all love going in front of that keynote audience and announcing what's new, what's exciting. You know, I think one thing I'll say is one lesson I've had, frankly, is the more senior you get in product management, the more you realize that in many ways the job starts resembling product marketing. Because what you're really trying to do is internal to your company, give people a shared mission, a shared sense for kind of what it is that they're trying to go after and why it matters. And externally, you're trying to explain what it is that you're doing. And you have to really be comfortable explaining things like I just did, Fundamental security, durability, availability, performance. If we're not talking about those as a database company, then in a sense, your priorities can be off. And we all kind of, we try out different things. But yeah, sometimes you realize you just have to be able to explain why it matters. And not just assume that some shiny new thing is what needs to be your driver.

Carlos (Product School) (22:22)
One term that I heard you use in other interviews is the anything platform. You're building the anything platform. I would love for you to elaborate more on that and what that means for your product.

Andrew Davidson (MongoDB) (22:35)
Yeah, I would think specifically it's the build anything platform. So in other words, we want you as a software developer or software engineer to be able to build any kind of application on top of us. So, know, what that kind of means for us is we need to make sure that our data model supports all the different kinds of use cases you might be building with. You're building with, you know, textual data, you're building with transactional banking data, you're building with unstructured data that resembles data that you're only going to be query into with vector embeddings or anything in between.
Couple on top of that the ability to have different kinds of workloads or shapes or algorithms and query types that are possible to efficiently access into that data. The ability to do a very rapid look up of a particular type of data. To be able to evolve what kinds of queries can be run. Translating that to the app tier, what that means is a new feature in your app should be easy to launch without the database holding you back. The database should be able to easily be changed on the backend so that you can launch a new feature, So I think our vision is you should be able to build any kind of application. It could be banking, could be dating, it could be gaming, and it could be a manufacturing assembly line. Whatever it is, we want to be a general purpose primitive for you to be building software on.

Carlos (Product School) (23:59)
I think of this as Lego. My kids are so young, you know, that I still build Lego with them. And I think having those Lego blocks that give you the peace of mind to know that that works. You just need to now have the creativity to put together the pieces in a way that is useful to you. It's powerful. But I think the next challenge is scaling that at the level that you are. So how are you able to optimize your data infrastructure to provide this level of scalability?

Andrew Davidson (MongoDB) (24:27)
Yeah, there's many layers to that question, but I'll say at a high level, first and foremost, it goes back to this kind of foundational thing that our founders brought that kind of made MongoDB special. Putting on the side for a minute the importance of the document data model, that's kind of more the front end. The other part of it was this distributed system. In the early days of cloud, MongoDB was actually, the first line of the first commit was really written this the same year AWS launched. was very much this kind of two peas in a pod. In the earliest days of cloud, when AWS was really nothing more than a virtual machine that you could get, you know, by the hour, maybe with S3 off to the side. In those days, having software that democratized or turned a bunch of virtual machines into a developer relevant platform, that could allow those virtual machines to be used for fundamental concepts we talk about a lot in the industry like high availability, auto failover or horizontal scalability, sharding to be able to take a bunch of those machines, put MongoDB software on top of that and get out of the box continuous uptime and continuous scale of broad spectrum of scalability. That fundamental realization of the importance of a distributed system, that's kind of been the core for us ever since. And if you carry that into the future and you start wrapping around that, us doing it all as a service, still on the back end, we're taking advantage of these fundamental distributed systems ideas that allow us to give our customers transactionality, availability, and scalability in a way that are kind of those fundamental Lego blocks, frankly, that make it all possible.

Carlos (Product School) (26:11)
There's a lot of product leaders listening who are working at companies that are smaller than yours. And I would love for you to share some of those maybe takeaways as you were scaling your own company on how to scale a data infrastructure so they can hopefully avoid some of those pitfalls.

Andrew Davidson (MongoDB) (26:35)
Well, I mean, obviously in our case, the data infrastructure is the actual product. think there's separate questions around the data infrastructure that you use to sort of gauge how your product's doing, right? There's the analytical side of house, if you will. And that's much easier in a SaaS business, it goes without saying. The ability to scale an analytical data infrastructure for an open source oriented business is really tough, right? Because you don't know what your customers are doing with your products, especially assuming you don't have some kind of phone home. I think my real way of answering your question, which is less about the data infrastructure, is more to say that there's this tension in product management thinking around does everything need to be data-driven as in quantitative, as in measurable, as in KPIs that I've determined that I'm measuring? Or instead, do I do a lot more anecdotal customer conversation and judgment oriented synthesis of what's going on. And the reality is in product management, you're always doing a combination of those two things. But I am always particularly wary of those who over rotate into measurability. Only because I think you can only of center everything on measurement if what you've already figured out is everything and you're at scale. And the reality is you're always doing new things and new things are hard to measure. So new things are where you want to be talking to as many customers as it's just gold to talk to and reach out to customers that have first used your product or to talk to customers that have stopped using your product or to talk to your customers who are using you at the highest and most unique levels of scale and to triangulate across what you're hearing from all of those and couple that with what you're analytically measuring about usage of your product. If you're not doing all those things, you've got major blind spots and you know, I just wouldn't trust you to be on the pulse of what's going on.

Carlos (Product School) (28:27)
Well, first of all, that's refreshing coming from you, a product expert at a data company saying that you can also make data informed decisions without all the data. But also, in your case, give me an example on how you actually create the space to be in touch with your customers.

Andrew Davidson (MongoDB) (28:48)
Well, I think one key part of it is that the product team culture here, and I certainly am big believer in it, is we don't have that idea of inbound product managers and outbound product managers. We're very focused on everyone needs to be 50-50. Your ability to work with engineers closely to build that shared understanding for what might be possible, what problems to solve, to prioritize the backlog, that ability is fundamentally predicated on your credibility being close to the customer. And your credibility when you speak to customers is fundamentally related to your ability to go truly influence the roadmap and ultimately bring back what matters to them. So I just see it as this critical figure eight. If you're not really 50-50 across those two worlds, it's so tricky. And so I think we've tried to just maintain that. Now, as we've scaled, we have more and more people who interface with customers who are not product managers.
Obviously, sellers and customer success managers, technical services engineers, and solutions architects, and countless others in a B2B SaaS business. And I think the relationships with all of them is vitally important for product managers too. But you have to make sure that you're sampling into actual customers. You can never allow a proxy to get in the way some percentage of the time. Some percentage of the time you have to be talking to the real customers. And the question is, how do you get them to tell you what you really need to hear? And I think the good news is you just have to tell them that you want to know. You want to know how you can improve, that sort of no feedback is not valuable. If you invite it, you will find the customers that will give it.

Carlos (Product School) (30:28)
Well, let's talk about that because I resonate with what you said. I personally block time to talk to customers. And sometimes those customers, depending on what we're talking about, if it's a large enterprise client that I'm talking to another executive, that's one type of conversation. Sometimes those executives might not be using the product, but sometimes I also, I'm intentional about talking to whoever is using the product. I do not care about the title. But it's sometimes for that other person is like, my God, I'm speaking with the CEO of this company, and he's asking for feedback. How am I going to give feedback to this person? So what are some good ways for you to really create a safe space and make this a productive conversation?

Andrew Davidson (MongoDB) (31:11)
Yeah, I mean, think you have to find common ground and sort of break it down. Like, you know, if you imagine them spending a lot of time in VS code and you're kind of trying to figure out, you in VS code, are we elegant and easy to use or are we kind of this weird appendage? Then you just have to kind of like be willing to talk about that. You know, I think I love you brought up the concept of speaking to executives versus say like a software engineering builder or similar.
There's no doubt that you can't speak to everyone in the fluffy, high-level way you might speak to executives. That's clear, it'll just turn people off. And I think the good news is we find ourselves at a time in which executives need to be more, at least in our world where executives like CTOs that lead software engineers, they need to increasingly really know the details and be close. They can't just kind of be high-level managers who don't care about the details. So I think the worlds are getting closer.
But ultimately, you just have to come in with low ego and show that you genuinely respect and care about their needs. I think the good news is your interests are aligned. I would hate to be working for a company that sold through executives and didn't care about the users. I think we've all used products from those types of companies. We know that they're atrocious. If you find yourself at one of those companies, you got to ask yourself like, "Is that sustainable?" No, you're atrophying your growth persona. So the fundamental question is, what type of company do you work for? How do you sell? And is the end user critical to the company's long-term growth and retention or not? I think it's particularly risky if you work for the kind of company that is a single choice for the whole company, because then it's disproportionately gets sold only to an executive. Keeping those products great is the hardest thing. And guess what? Those are the products that have the quickest cycle time. Because there's always a new one that comes in. Database is very different. We have to grow cubicle by cubicle, application by application, year after year, over a long timeline. And so our ability to saturate the S curve and to start plateauing in growth the way a SaaS productivity suite that sold centrally to an enterprise, for us, we won't hit that for decades. Whereas they could hit that.

Carlos (Product School) (33:08)
Yep. Yeah.

Andrew Davidson (MongoDB) (33:33)
in like two years if they execute really well.

Carlos (Product School) (33:36)
Yeah. So going back to the previous point you were sharing around finding the customers at any level to really have an honest conversation about one of the things that helps me is first not disclosing my title and actually pretending that I have a different title. It sometimes makes people more comfortable if they don't know me. And then the other one is there are other ways to collect data. So when I see that someone is particularly unhappy, I already know that they shared their opinion. So going to them so they can also be prepared to share what they just shared anyway.

Andrew Davidson (MongoDB) (33:53)
I agree.

Carlos (Product School) (34:06)
it also makes them more comfortable instead of catching people off guard. But I think you are onto something here, especially as these large organizations and people who used to be ICs now suddenly become super managers. How do you really keep a finger on the pulse while honoring and leveraging, obviously, the rest of the people that are feeding you with information because you cannot be everywhere?

Andrew Davidson (MongoDB) (34:29)
Well, it sure is tricky, isn't it? I sometimes, one of the things I always recommend to my team is to read the, I think it's called, Analytical Thinking for Intelligence Producers. You can Google it. I think it was like the CIA internal training manual. There's a PDF available on Google. And it's just incredible to read, like, so this is how they train intelligence analysts. And you realize, product people are very much like intelligence analysts.
You're never going to have complete information. You're always going to have to make judgment calls in the absence of that and try and summarize what you think matters. You're going to have to be open or call out where you think you have the gaps in your judgment. And you just have to do the best you can and keep moving forward because making decisions and moving forward is a key part of the job. But I think ultimately, to answer your question more directly, you have to keep sampling. You have to just do what you can to not allow yourself to be so far removed with so many blind spots.
You have to go in there deep occasionally. But you can't do, one thing I think, you don't want it to be so that when you go deep, it causes everyone else to feel total anxiety. You have to be comfortable going into the workshop, so to speak, and not expecting that the workshop has to be all cleaned up before you got there. Sawdust is okay, right? So I think finding the safety for people to feel comfortable with that and to join into the workshop without being overwhelming requires you to just have that kind of safety in your leadership style.

Carlos (Product School) (35:59)
Andrew, one of the things that I heard you talk about before was the importance of four particular pillars for your core offering. However, I didn't hear the word real-time data processing in that, and I know that's another big part of your differentiator. MongoDB facilitates real-time data processing. I think for now, enterprise clients, that is huge because sometimes you do not need to wait for the data meeting in order to receive the information. You can literally know what's going on in real time. So how do you think about that? How has that kind of evolved as now more people who are not super technical can access real time data?

Andrew Davidson (MongoDB) (36:42)
That's a good call out. I almost take it for granted that we are in this category of operational transactional or real time data as distinct from what I'll refer to as analytical or OLAP or warehouse or lake style data. And I think it's actually really good to kind of demystify that a little bit because unless you use a database all day long as a developer does, these two worlds are overlapping and vague. it's in fact, the analytics world is the world that probably product people and in general, person on the street are way more familiar with. I think the analytics world where, know, ooh, I get to derive insights from data, that sounds really reasonable. It's kind of like a glorified, fancy version of a spreadsheet. We all know that world. So there's nothing kind of mystical about analytical data processing, which turns out to be a small minority of the database industry. And you wonder, so this majority that is this operational transactional, why do we not know it exists? And I think it's really because this idea of real-time data processing or transactional or operational data processing, you're doing it all the time, you just don't realize it. We're doing it right now. Every software we use all the time is reading and writing with millions of end users doing the same thing through that software interface, reading and writing to these databases behind the scenes the application we're using to make this podcast possible, the email inbox, the application that's giving you a real-time notification that every app you use all the time, everything that you see presented to you, all of that is in real time being synchronized back to a remote database generally in the cloud. And so this idea of real-time high-throughput concurrency is this sort of workhorse that powers the back end of the digital economy. And that's very much the segment we play into. And so yes, it's about things like real-time insights, but it's even, it's about more basic things. It's about you being able to have state that is shared with others that can evolve in real time so that software can keep up with ground truth reality. And that's what makes software so exciting to use.

Carlos (Product School) (39:02)
And I agree and I see that now most of the companies are now software companies in a way, right? This is not just for high tech companies or for engineers. So as you serve some of those large enterprise clients and they go through what they call digital transformation, like, can you tell us more about what is that role that operational data is playing into that?

Andrew Davidson (MongoDB) (39:23)
Yeah, no, it's a great point. know, I think over the last decade or so, people have become more and more aware that they can't just buy off the shelf software packages to solve all their business problems. That while software packages are great, every company needs to solve at least some of their problems with software that's specific to the nature of their business. Because increasingly software is what defines internal business processes. It's what defines your ability to communicate with end consumers, to give them interfaces to engage with you. And it's fundamental to how you stay ahead of the upstarts that are competing with you or the ability to go disrupt someone who's out there with a great new software offering. And of course, to go through a digital transformation, there's so many components to it. On the one hand, for many of these companies who haven't had much in-house software engineering or product teams,
For them, they just have to start building out that talent, that ability, that mindset. They have to start thinking about empowering small teams to move with that agile mindset. And I think we're well past that being kind of the norm. Every company has pockets of teams doing that. But I think once you go further down that road, you realize you also have to really make sure that you're building on top of a modern infrastructure foundation, that you're using the right building blocks that make this possible. And of course, cloud is a key contributor to that.
And having an operational data layer, a developer data platform, a modern database in MongoDB is a key way of making that possible because it allows a small team to operate without having to involve dozens of others and to have that special forces level impact. A small team should be able to create incredible software experiences, like the bank that you used to hate logging into the website of that now feels modern like a consumer app that you love. That could have been built by a small team that's operating in this new way, building on cloud infrastructure, using a modern operational data layer like MongoDB on the backend. And layering in great product management and great product design on top. You sort of need the whole stack. You can't just do one part of it and expect to become modern.

Carlos (Product School) (41:39)
I love that example because that's reality. All of these companies were misunderstood as just legacy companies and now they have incredible technology and incredible teams. I think one of the challenges, and we also face it as one of the vendors when we go and do training for them, is how do you go about the transition? There's a lot of people, there's a lot of tech. So do you set up a Tiger team to start working on the new stuff? Do you find ways to incorporate the new stuff while also keeping some of the old one alive. What is your take on that?

Andrew Davidson (MongoDB) (42:13)
It's a great question. I think it depends on, it always helps to find critical business objectives that need top-down buy-in to be achieved that are a key thing to move forward on. So for example, if basically the app is hated and that's causing the customer to hemorrhage users, hopefully it's a top-down agreement. We've got to create a great app. So right on the coattails of that to start, bringing in the new ways of thinking. But then the question is who should be involved in that? And I think you have to ask yourself, who's already been kind of floating into the ether of showing that they're interested in doing these things? Who's already doing this in hackathons? Are you running hackathons? If not, how are you getting a chance to see who wants to build that way? Who wants to execute fast? So I think you sort of need to think, like, let's start changing our way of building to see who kind of essentially raises their hand and says, I want to build different, then go have them go pursue some of those critical business priorities. If you need to hire people to do it, that's another reasonable thing to do. I think eventually you start kind of getting that critical mass. You have to bring people along. In product, people have such a role to play in kind of bring people along. A DBA who might have traditionally managed databases in an on-prem data center 10 years ago.
DBA over the last 10 years, in many cases, has retooled and become, you know, essentially a cloud architect or a site reliability engineer, SRE. And in order to do that, they've had to learn a ton and evolve their skillset. But the beautiful thing is that allows someone who was once a DBA to sort of evolve into having a much higher leveraged impact than ever before. You have to ask yourself for all the different roles, how can they show a path to evolve and grow and have a higher business impact and give people those paths? Give them the resources, and generally they'll step through those doors.

Carlos (Product School) (44:12)
There are two main motivations that I found very powerful when trying to drive change. And these are very extreme. One is fear. The other one is greed. And I think we're seeing now with AI, lot of people, they really want to keep their jobs or become irreplaceable. And that's kind of the fear feeling. There are others who really want to become the first movers and win big in a new paradigm. And I think that's more of the greed feeling. But I think you're right, finding the talent from within and see who are those early champions or adopters that can be on your side to drive change is very powerful because if there is only top-down instruction at some point, you you can't just push it alone.

Andrew Davidson (MongoDB) (44:56)
Well yeah, I think I'm one of those people who believes there's always a way to explain the why and get people excited to think differently than they were before. And I don't even think, know, it doesn't necessarily need to even be as stark as fear versus greed, though those are certainly key ends of a spectrum. I think just really give investing in people so that they understand why something is appropriate for them. The macro strategy or why it is appropriate for them to start retooling and investing in new things. Sometimes people just jump past that or don't want to spend the time doing that. And I think, you know, that's where it's definitely not just senior leaders who are going to be involved in that. It's everyone in the organization, especially highly leveraged individuals like product people who are out there really talking to people within the research, the R and D or software organization more than almost anyone else. Like it's product people oftentimes who are asked to give the state of the product to the whole team, who are asked to speak to the whole team, to get them excited about what problems we need to solve for customers or what the business strategy is or how we might need to change how we're doing what we're doing. While we might think of it as, and foremost, engineering leadership needs to make the changes in terms of how we engineer things. That's true on the one hand, but don't forget the role product people have to play in inspiring people to want to make that change. That's a big part of our jobs.

Carlos (Product School) (46:23)
Andrew, it's been a pleasure to learn from you and see how you're thinking and structuring your thoughts in a field that could sound and sexy from the outside, but you are definitely making it sound extremely interesting. I can feel the passion you have for this.

Andrew Davidson (MongoDB) (46:39)
databases are an extremely interesting space. Now, product is great. know, it's a, we really have interesting roles, don't we? It's this, no one quite, it's a difficult role. think it's important for people to understand that it's a role that may have certain levels of prestige, but it is much more difficult than people assume. think a lot of people see product through a very specific, narrow lens based on the stakeholder that they happen to be.

Carlos (Product School) (46:41)
Haha

Andrew Davidson (MongoDB) (47:08)
And once you realize that every stakeholder sees a different thing and that you're trying to balance it all, it's a tricky role. And it's a role that requires you to really leave your ego to the side or you're going to feel so frustrated. But once you sort of accept the infinite to-do list and accept that you're never going to feel perfectly like you know exactly what to do and that you just have to be OK with those things, if you can thrive in that ambiguity, sky's the limit.

Carlos (Product School) (47:32)
Thank you so much for your time.

Andrew Davidson (MongoDB) (47:35)
Thank you so much, Carlos.