Andrew Davidson (7:53)

Great to be here Melissa. How are you doing?

Melissa Perry (Host) (7:56)

Good. I'm excited about this. I was telling you a little bit before we jumped on, but I used mongodb when it was very new back around 2010 open sky was like one of the the companies in New York where our developers were obsessed with MongoDB. They were like we're doing it this way and I knew how to code in SQL but not MongoDB. So I had to go take a three month long MongoDB class and be able to query all my own stuff and pull things out of it to get all our customer information. So I am really excited to see where MongoDB is today.

Andrew Davidson (8:29)

I love that there's so many great things in that story. On the one hand, Lower Manhattan at that time which is exploding, started to see the rise of what we then called the Alicorp World or and New York tech has grown so much since that time. And also for you, you as a PM needing to know what's going on in my product in real time and just making sense of that which is such a crucial part of it. But yeah, I'm going to be the company. We've come such a long way over those years building on that early excitement and momentum and developer adoption. Frankly, at a time early on that you might describe as kind of a shadow IT type of people started to use it maybe without full permission, let's say which pros and cons of that. And MongoDB was not ready for a lot of mission critical stuff at that time. But we were able to keep building up over the years and layer in fundamental primitives that make it something that you could really build mission critical applications on top of. And we're privileged today to have 70% of the portion 150,000 customers around the world building on our flagship database as a service offering which is called mongodb Atlas it's amazing.

Melissa Perry (Host) (9:30)

I remember too back having conversations about, you know, will MongoDB keep growing? Like, why should we use this new technology instead of SQL? Like what's the purpose of this? Maybe we could start back there. What, what sparked MongoDB? Like how did it get started? And why create like another data. Why did they create another database company compared to SQL, right? Like isn't SQL enough?

Andrew Davidson (9:53)

It's certainly one thing's for sure, it's not easy to create a new database company that challenges something that is, that has so much inertia in our industry. Something like relational databases, which dated back to the 1970s and which had just become so ubiquitous. And if you look, if you were to go back to the 1970s and ask why did relational databases become a standard at that time? It was because they were optimizing for the key cost bottleneck and computer computing at that time, which was the cost of storage. Not everyone knows this, but basically storage used to be the really expensive thing. But over time, as we've seen, storage has just gotten real cheap. And essentially over time, the key cost bottleneck in computing shifted, I would argue to two places on the one hand to compute instead of storage. But what's talked about far less is it also shifted to developers minds. The builders around that era, you think like 2008, 2009, 2010, who had this incredible new set of building blocks to build on top of. With the rise of the early days of cloud, the challenge was they were still trying to build with these relational databases and those for developers were extremely rigid. Essentially for a developer to imagine an object in their code that they're going to express in their software, to have to fit that into rows and tables, columns and kind of fracture their objects across, across those tables, had a series of problems. It was inflexible. But perhaps more importantly, especially that boom time and the rise of Web 2.0, it was fundamentally not scalable, it wasn't built for the kind of scale you were going to need for the rise of ubiquitous web access and then the rise, certainly the explosion of access around the mobile wave. And MongoDB came in, it was founded by developers who had been dealing with that friction and they were struggling to build around those legacy relational databases. And they realized what if I could start at the bottom of the stack and start rebuilding this? And it started with some basic primitives. But I think a second thing led to that rapid adoption. It wasn't just the ease of use which MongoDB came in with the document model instead of Those tables which conforms to how a developer thinks in their objects. It wasn't just that, which is a user space part of things for a developer. It was also the back end. MongoDB came in and was a distributed system that very much democratized the idea of using cloud commodity hardware at a time in which that was newly available to people. So if you're a developer in 2010, you could use AWS. In those early days it was just EC2 and S3. You could spin up some virtual machines, EC2 instances and now MongoDB allowed you to turn that into a developer relevant abstraction. You take three of those instances and create a highly available replica set using MongoDB's nomenclature and from your software connect directly to that. That basically allowed cloud to be more accessible to developers. I think that's a part of the story that's told less so when you.

Melissa Perry (Host) (12:56)

Were thinking about MongoDB in those early days too. If a company is choosing to to use it, what types of benefits are they going to get from, you know, a business value perspective to do that?

Andrew Davidson (13:08)

Yeah, the fundamental thing that comes from, from building on this document oriented data model that MongoDB offers is something that gives developers something that's much more natural, much more intuitive for them to build in a way that they can move faster. And this is correlated with the trend to empower small two pizza development teams to move super fast and own their own destiny. There was a time in which we built these monolithic code bases and everyone had to figure everything out together. We've all learned as an industry it's important to empower those special operations teams to move super fast. And MongoDB very much was built perfectly for that trend that was going to empower these teams to in their code, control their data models in their code, take advantage of the ability to push down to the database strong but consistent secondary indexes that could change, which means I could now change the features in my applications that would take advantage of different queries and very easily evolve them. I could evolve the actual data models themselves with the flexibility of the document model. Meaning I change my software based on the needs of my end customers rapidly, all the time. And I don't have to deal with the complexity of doing the schema migrations which traditionally were very challenging relational database. And if you kind of continue that trend over time, the expectations, the velocity, the personalization, the scale, the needs for proximity, for example, the rise of mobile, find someone nearby, geospatial capabilities, Transactional capabilities critical e.g. in financial services and Building to more recent times, people have the expectation to really have fuzzy search right at their fingertips to be able to do retrieval with large language models in the mix that are going to be super powerful, taking advantage of vector search. So we've been able to just keep layering in these primitives that allow a developer to, when they sit down at their workstation, write their software code to experience those superpowers of expressing concepts through the singular abstraction behind the document model. That's been the, I think, the key differentiation from the alternative, where you would just be stuck in complexity, bolting on a bunch of solutions to move around the fact that the relational database at its core were so limited.

Melissa Perry (Host) (15:16)

I think about MongoDB too, back in those days, in 2010, since it was like so new, I know been out for a little bit, we always had these conversations too, which I think people still do, about is this going to be obsolete, right? Like, is this the next cool, amazing, like developer language or developer tool where it's just going to go out of style and then we're stuck on this thing that's no longer supported? And it's been really exciting for me to watch MongoDB's journey because obviously like that didn't happen. You just kept growing. What do you think was the secret to your success to have this type of longevity? Whereas we've seen so many different, I think developer tools and developer languages and stuff that were hot back then just completely go out of style.

Andrew Davidson (16:00)

I think it's been so many different factors. One, certainly the market was ripe for something new and yet there was just so much inertia. There was 40 to 50 years of people building it a particular way, which in computing is mind boggling when you think about how much turnover we see in technologies. So I think there was a pent up need for something new. Cloud came in and in those days we referred to it as the rise of commodity hardware. But cloud came in and just completely changed the game. And so the market was being shaken up, people were starting to get open minded to look at something new. And we started seeing this early adoption and interest. And from there I think MongoDB as a company was just very disciplined about continuing to slowly invest in a combination of things that were appropriately balancing what I would describe as the growth Persona, the developer who chooses to build on the platform for whom it needs to be ubiquitous, it needs to be available everywhere, it needs to be free forever as an option. And then separately, in continuing to judiciously evolve how we commercialized it. We started out Commercializing more of a de risk value prop for traditional enterprises that might have adopted it and then needed to layer in bells and whistles for monitoring and automation and backup. And then later with the rise of the expectation that databases were going to be delivered as a service truly SaaS for databases. In other words, we went top down decision all in on MongoDB Atlas and it took us five years to to have Atlas become the majority of our company's revenue which if you look at peer companies that's pretty accelerated. It requires really focused efforts and I think the only way we're able to do all of these things is to continuously stay super close to our customers and just stay customer obsessed. What do they need us to do to both continue to be relevant for builders to keep growing and separately to be solving enough problems to be to have a commercializable business.

Melissa Perry (Host) (18:01)

The thing I keep hearing you say over and over here too is that you really care about the developer experience. The people are actually using it and making sure that it scales and it's their mental model rather than trying to put arbitrary frameworks or structures on top of not how people think. So you're architecting it. I think that's got a lot to do with the success too. So let's talk a little bit about product management. You came to MongoDB, you've had a successful product management career and other companies too. What got you excited about, you know, a database type company where you said this is an interesting product challenge? What, what led you here?

Andrew Davidson (18:42)

I. My own personal story is a little funny in that unlike, unlike a lot of people who move out to the Bay Area from say the East Coast. I'm actually from Palo Alto originally and I moved to New York and I, and I did that thinking I gotta, I'm not sure what I'm. I had taken a year living in Bangladesh, long story there. So I was like, I'm no longer rooted in the Bay Area, I can move to New York. So I did it and I started going to job interviews in New York for product roles and I started and other roles, by the way. I hadn't really worked as a traditional product manager. I had done kind of internal product management for stuff at Google, but I haven't really. I hadn't felt yet that I had a true product role. So I was looking for all kinds of stuff when I first moved to New York and I remember I was looking at fintech and marketing tech, all the classic New York tech. And I remember showing up to a fintech interview wearing A suit. When I first arrived in New York, thinking that's what they do in New York, they wear suits in New York. And they were like, you know, in tech, we really don't typically wear suits. And I felt. So I got it wrong.

Melissa Perry (Host) (19:43)

That was a big deal.

Andrew Davidson (19:44)

Somehow I felt a little bit like a fish out of water with a lot of these companies. And somehow mongodb was a really good fit for me. I remember in the end interview because it was just the first kind of like pure tech company that I found in New York, which resonated so much for me as someone from Palo Alto. It was just way more natural. So I started feeling, wow, I have a lot of kind of intuition for how this type of company thinks and feels and the challenges they're going to have. I have a feeling I'll be a good fit for them. And I think I just got lucky in a way to land it. But I'll say MongoDB is very lucky to be in New York because you have all your customers that you could ever want right at your doorstep. Right. So it's this duality where, if I think back, in some ways it would have been interesting if MongoDB were a silicon Valley company. And obviously we've always had a presence there in a big office and everything power all the San Francisco. But it is very unique to have found it here. And I think I was lucky to have early mentors at MongoDB who really helped me to realize I. I barely even know what a database is, but the door can be open and I can step through it. This is not something that's impossible to make sense of. So that was a big relief early on.

Melissa Perry (Host) (20:55)

So when you came into MongoDB, obviously it looked very different than it does today. What were the leading factors and kind of the path you were thinking about as you started to think about how do we expand from just like a database company to a data tool platform for developers?

Andrew Davidson (21:14)

We always had this challenge, which is that we were. The database is this really critical thing. We sort of, in a way, take it for granted. It's just they're everywhere. Databases. I don't really think about them much. So therefore it's almost like it sounds like it's not a big deal. And so there's this tension. How do you get people excited about something like a database? And then more importantly, at least for us, is how do you get them realizing that what they think of as a database is something that could be radically changed? We've, I think, long used almost the analogy of could we be like the apple of databases? Or more specifically, sometimes we use the iPhone analogy, where it's like the iPhone was called a phone. It was not called some new thing. And that's perhaps because it made it more accessible. Like, we all knew what a phone was, it made sense to start there, as that's what it is. And yet we know that the iPhone had just collapsed so many things into it collapsed whole industries essentially into the experience. I think that was the metaphor that we've long used to think about what we're trying to do with the database of Mongoose be. We want to collapse concepts that a developer will need in their applications, concepts that have to do with data, into the database. But the problem is if you just say it's just a database and you think you know what that is, then they won't know that they could find these other concepts. For someone to realize that you could have fuzzy search, geospatial capabilities, time series capabilities, and vector search all in a database that also gives you transactions and aggregations and many other things, all accessible through something that's really intuitive and natural from your programming language, from your code. They just wouldn't expect that from a database. So this kind of led us to this. We should feel confident that putting that value in there and empowering the builder, the developer, to discover it and build with it. They will build with it, but how do we explain it? And so we started explaining it as developer data platform. We have to go beyond just database. And the reality is, I go back and forth on that. Sometimes we just say, we have to just say that we're a database that has all that stuff in it. Which is true, but that's, I think, an interesting. The key point though is collapsing huge sets of value into the interface where they build so that they're not having to go build with a separate time series store, a separate search engine, a separate vector search engine, a separate system for transactions, a separate system for key value, and just having it all at their fingertips in one system.

Melissa Perry (Host) (23:48)

What I think is interesting here is that, you know, we're talking about a database here, which is one of the most basic, like, development platform components. But you're talking so much about user experience. And I get into a lot of debates and I get a lot of questions from product managers who are on the platform side or the technical side of products, or working on APIs or, you know, different components there. And they're always asking me, like, what's different about product management when it comes to these more technical products when it comes to these platforms or these components than they would say like user facing ones. But in their mind, user facing is like an app, right? Something I access on the the web or an app, a banking, you know, a banking transaction, something like that. I've just heard you talk about a lot of user experience. Tell me about what's different or what's similar when it comes to doing product management and thinking about your customers. Your user experience in a technical product like this versus something that might be more what an everyday consumer would use.

Andrew Davidson (24:49)

I'm happy you thought you mentioned user experience because there's many layers of it here now that I think about it. Especially so if we're offering a database, which is this kind of critical primitive that the developer uses directly from their software, what's interesting is obviously we're pretty obsessed with the developer experience of that database. What's up? What's also interesting though is by being obsessed with that, we allow the developer building on top of us to deliver a better experience in their software to their end users, which is something obviously product managers care a ton about. The reason is by having a data model that can, in a rich and structured way, easily express the fidelity of the real world. We can easily express features in our applications that have that fidelity. Like I always think of the kind of the penultimate example of a horrible data model is something that feels horribly top down, like a filling out a census form or electronic health record or those types of things where it just feels like someone chose a couple of column headers in a giant table somewhere and I need to be conforming to that. Versus something like a great application is one in which, you know, it just feels like you can be you in that application. It's just natural to use as a human. And what's amazing is that application somehow on the back end is structuring what is being expressed in a database. And I think not all PMs actually realize this. Certainly regular folks on the street don't realize this, that every software application has a database behind it. Specifically it has a transactional or operational transactional online database behind it. And that's the type of database MongoDB is. I bring that up because I think sometimes it's important to define the category you're in when you're in a category that a lot of people doesn't know exists. And the reason I'm proud that people don't know the transactional database exists because it's a sign that software has gotten so good that it's abstracting the back away old software that we hate, enterprise software that we hate. That feels like I'm using a relational database. That's the old world, if you will, where it's like the database is imposed on the user. The new world is one in which the developer is so empowered to be flexible that they can build an amazing front end framework on top of it that expresses great experiences, great functionality, all the apps that you love, but there's always a database in the mix. And so, you know, I think once people realize, oh, there's always a database in the mix, I didn't even know that was there, then it opens you up to, yeah, it's a database in the mix. And not just that, it's a critical part of what enables a software engineering team to do its job every single day is whether or not they're building on a foundation that allows them to move fast and deliver those delectable experiences. And so I think you had a deeper question, which was when we think about developers, for example, as a customer and thinking about product management, for them, it is quite different, I would say, than like a typical consumer use case in that you're dealing with. Developers are a really unique Persona. They're extremely sophisticated. On the one hand there's a sort of they are people who have figured out how to make things work in a way, a developer, if you filter, there are people who, if you filter through, there are people who will jump through hoops, figure out puzzles, do move mountains to figure out how to get something done. Because anyone who's tried to write code knows you just constantly run into issues and you have to get overcome them. So they're like people who love overcoming issues. So on the one hand, that sounds amazing. You could think to yourself, they therefore don't care about experience because they'll just get over whatever experience I give them. But on the flip side, they're some of the most sort of love, hate, fickle. If they feel like you're wasting their time or they're not treating them with respect, or you're not empowering them to really fly, they could be completely the opposite and be like, get out of here, I don't want to use this at all. So it's this unique tension. You want to empower them to feel the full power and then they'll run with it. And you can expect them to become an expert, you can expect a lot from them, but at the same time it needs to just fly and it needs to be able to be something they can run locally. And it needs to be able to be something that they can easily weave into their CI CD pipelines and run with infrastructure as code at scale and all of the many things that you just have to think about when you're in this type of product.

Melissa Perry (Host) (29:07)

Yeah, my experiences with developers are they will definitely try to solve problems, but they will not be quiet about it if it's like frustrating. And I find they actually appreciate probably, you know, user experience and their tools more than anybody. Right. They're, they're in them 24. 7. Like we may open an app for banking once a day and be annoyed by it, but like they're literally using those tools 24 7. So if you think about what other people use, I know, like, you know, salespeople are in Salesforce all the time. That is like what we're talking about when we're Talking about platforms, APIs, like all these components, databases and stuff to developers. It's like they're a Salesforce what they use every day. And if you're mad at Salesforce, imagine what they're like if they can't get those components and start to build things. So I think that's a great parallel. And I think sometimes when people are new to platforms or developer tools or things that are abstracted away from an interface that we would think of in an app or an iPhone, they forget that layer of user experience. So I'm really happy that you talked about that. Like, what is it like to actually expand experience things and work with them? And in these enterprise companies, what I find is that we've got these platform components on the back, like we're talking about MongoDB, which is a company that one of these enterprise companies would hopefully bring in like your database and your tools and use them. But all that makes up this backend platform. It's been my experience that if we don't think about the experience of the developers internally using those platforms to make the, the user facing, the customer facing tools, and we don't think about what's the commercial aspect of that, how are they going to interact with it, how do we make it scalable, how do we make it efficient? And we don't make that experience great. I have seen them just design around platforms and not use those microservices and not use those APIs and they're like, I'll roll my own, I'll do something else. And then we end up in a mess.

Andrew Davidson (30:56)

Totally.

Melissa Perry (Host) (30:57)

I think that's a key component to why we need good product management around those things. Too.

Andrew Davidson (31:02)

Yeah, I think that's a good point. In terms of internal platform product management in enterprises, which oftentimes those types of people actually could essentially represent a customer for me, or sort of someone who's building abstractions above something like MongoDB Atlas to deliver a self service internal developer platform within the enterprise for their internal end customers who are building for the external customer. Let's say we definitely see that where sometimes one pocket of the enterprise will kind of build their own version of that and another group, another line of business or another center of gravity will do their own thing and you start having this kind of different approaches. Sometimes you have a part of the organization that's empowered to move faster. They're encouraged to be a bit, a bit more digital forward, cloud forward. Maybe they're consumer as opposed to traditional investment banking or xyz. And then you see these kind of culture differences emerge and team structure differences emerge. And I think a product role, both in a technology company like MongoDB but also in those internal roles, it's all about driving in the ambiguity and bringing people along on the journey and painting a picture of where we need to go, giving people the insight and also understanding where they are to understand how far can you go reasonably without trying to go a little bit too far too fast. And then you start seeing diminishing returns. This is the constant tension. I think for product managers, one of.

Melissa Perry (Host) (32:21)

The big debates we get into as well around this, whether it's with people who are like your customers in the platforms or technical companies like MongoDB, is do we really need product management when it comes to technical stuff, right? Like platforms, APIs or databases, what have you seen as being the benefit and what do you add to these types of developer tools, this kind of landscape as product management?

Andrew Davidson (32:50)

It's a good question because undoubtedly engineers building these types of tools have great intuition or should ideally, or in many cases do. And I think, you know, it's incumbent upon the product manager and a technology like this to actually harness that wherever possible. It's great to have that internal feedback, our insight or opinion or the ideas. But I think the other thing to keep in mind is as you get lower down in the technology stack, usually, not always, but it's often the case that you're getting into a focus on things that are more about mission criticality from an engineering excellence perspective. That is mission criticality, correctness, durability, like we talked about our big four security, durability, availability and performance. And so there's so much focus there as There should be in terms of just engineering excellence that you know that it's a lot of context switching for people who are focusing on that fundamental making sure that if someone's building on top that they can trust that what's happening below is really delivering as it should. It's hard to context switch between that and really going and spending a ton of time with customers. Now, to be clear, you want to, I think in a perfect world, all engineers spend some time with customers. And you have to find ways as a product manager to find those kind of one to many opportunities as well. Like it's super important to constantly be getting that access. But the reality is you're going to have people who are super deeply focused, like in the database. You're talking about writing something in C that could take really many quarters of development of continuous testing and rigor before. It might even be something that users are directly using. And product management is critical to being plugged in with the engineers, the traditional inbound aspects, making sure that together you're coming up with an execution roadmap that's really, you know, coming up with the right trade offs and really pursuing the right opportunities. But then on the outbound front out there with customers, understanding what's working, what's not, what could be taken to the next level and finding that virtuous cycle. And by the way, I'm a big believer that product managers should absolutely be 50, 50 on that. Inbound. Outbound. Like to me, the second you find yourself doing all inbound or all outbound, you lose the credibility for the opposite. And then without doing the other one, you lose the credibility to have the impact in the one year in. So I think it's critical to be balanced. And so I just think if you didn't have product management, you would find yourself drifting. Ultimately there's plenty of, again, plenty of engineers who have terrific intuition for developer tools. And almost every developer tool gets started of course by, you know, people hacking for the things they wish they had for themselves.

Melissa Perry (Host) (35:29)

Yeah.

Andrew Davidson (35:30)

And that, that makes sense early on.

Melissa Perry (Host) (35:32)

In that, that brings up a good point too, is that how do you, how do you as a technology company to make sure that you're not just building for yourselves internally, but you're also looking at the customers outside. Because I imagine it could be very easy to be like, it could be very inspiring and creative as well to be like, hey, we could do this, we could do that. But how do you keep that focus to make sure that you're like, hey, we might be users of this tool, but we are not paying for it. Like, let's make sure our paying customers are actually the ones who are, who are giving us some feedback here and we're incorporating that.

Andrew Davidson (36:05)

They hit the nail on the head. Some companies have the benefit of using their product a lot more than others. Depends, right? But dog fooding is great because it gives you intuition. Sometimes it doesn't happen all that much. Depends on the team perhaps. But that's where I think the product manager really must be coming up with ways of getting and inviting that insight manager to be, you know, not only doing things to make sure that everyone's getting exposed and hearing about what customers are doing, but the product manager needs to be out there finding opportunities to be talking to customers. And it sounds so obvious, but I, I think it's very easy, particularly in a company that, you know, gets large enough that it might have customer facing employees like sales or solutions architects or customer success managers. It's very easily one, very easy once you're at that level of scale to sort of wait until those people come to you to be a little reactive. But my philosophy on this is that similar to how salespeople are always doing pipeline generation, I think it is crucial for product people to be constantly finding new opportunities to just reach out to the customers directly. Because customers love it when a product manager is reaching out to them to learn about whether the product's going, you know, a good experience for them to really be building that human to human connection. So, you know, I think it's what I always encourage the team to think about is anytime someone's, you know, using you for the first time or any, anytime someone stopped using you, or if they're using you at a unique level of sophistication or scale compared to most others, you know, you should find a way to reach out to some of the people in each of those categories just routinely, almost like on a weekly basis, if at all possible, just to be building, getting that insight, getting that feedback back from them. And you know, you get those incredible responses sometime from a customer. We just got one the other day, someone who, you know, you couldn't make it up. The person said, our team realized what we could do with search. Just having search in the database and how much pain that saved us and we were just blown away by it. And like literally that product manager shared that insight with a bunch of colleagues in engineering and other places on the team yesterday. And it's like, that's amazing. Like, let's go build a relationship with that customer to understand do they still feel that way six months from now? Or did, you know, did we not continue to evolve in the ways they needed? You know, so just staying on the pulse proactively is crucial.

Melissa Perry (Host) (38:30)

That's really amazing there. When you were thinking about customers, you mentioned, like one way to look at it is people using things that are unique or at scale. Like how do you think about who are the right people to partner with and listen to is.

Andrew Davidson (38:46)

You can never invoice alone. Right. You're always synthesizing across many and you have to, you have to feel that you're, you know, you're hearing from some solo developers that maybe are a game startup in our world and some others that are in a bank. You want that whole spectrum and if you, if you were to go all in on one side, that would be a risk. And I think just the cast Internet kind of does that for you. But the great thing is those people kind of emerge on their own. The people who are going to share the feedback like they're passionate about it. It's amazing once you realize that there's a relatively small percent who just would love to share and engage and those are the same ones who will often be willing to come in and go meet all the engineers and share further and talk about here. I love this, this and this. But by the way, this, this and this can be improved. You know, you just find those people that has that have that enthusiasm. They're kind of the core of your community. And of course, if you don't have any people like that, then ultimately do you have product market fit at all? Right. It's like, are you really solving enough pains?

Melissa Perry (Host) (39:44)

That's a really good point. When you were thinking about MongoDB and the evolution, right. That we've been talking about a little bit. Tell me a little bit about MongoDB Atlas. You mentioned it's taken over five years and you replaced, you grew like crazy. What problem are you trying to solve with it? And how is that different from the early days of MongoDB?

Andrew Davidson (40:04)

Yeah, so, and by the way, it was five years into the Atlas launch for it to become the majority of our company revenue. Today it's about 73% or so of a company revenue. The, you know, the road to there's people in the early days of cloud adoption would do what we now derisively refer to as lifting and shifting. Namely, they kind of took what they traditionally did in the on prem data center world and they would just do that in the cloud. So you'd have like An SRE or an OPS person going in, figuring out how to deploy a virtual machine and figuring out how to, you know, configure the operating system there and upgrading the operating system and then deploying a bunch of other VMs and doing the OSS there and then doing distributed system management across them and network management and patching and, you know, auto scaling by replacing them in an individual manner. And while you could do that a lot faster in cloud than you could in a traditional data center, the reality was that it was the amount of surface area to become an expert in, and especially frankly, in the enterprise who did start out in the data center, they realized, wait a minute, I now have twice as much to worry about. I have to have twice as much expertise, in a sense, I have to learn how to do this in a whole new set of data centers, AKA cloud. So there was this realization that, wait, the real value of cloud will come from moving up a level of abstraction, from just saying, I want something, and a service will give me that concept. So instead of a bunch of complex virtual machines with operating systems and software that needs to be upgraded and a compliance patched and all these things, you. You just said, give me a database and an endpoint to connect to. And the service provider, like MOG would do all that backend complexity. And so it sounds kind of obvious, I guess, but because the database was the center of so much gravity for uptime and sensitivity around security and just control, like, it's kind of the. In the old. Maybe in like a trip of an application, someone might have almost thought of the application's front end is sort of like the gates to the city. And then the business logic layer is kind of like the inner part of the city. And then the citadel that's especially locked down at the very center of the city, that's kind of the database. And so, you know, I think database took a while to get comfortable, to be sassified because of that. You know, how can I put the citadel as a. As SaaS? That seems like all the more concerning. But the reason people started getting comfortable with it and realized it was actually a better model was by having all those layers be abstracted away by a service provider that had all the expertise in doing so, that could deliver all the great security defaults that couldn't be disabled and make them easy to build with. Essentially what you did was avoid a bunch of folks manually dealing with something so complicated that you could very easily open up a massive zone of risk by just doing it wrong. So you kind of you know, abstracted away, doing it wrong for the most complex layer of the stack, this distributed stateful database system. And so it was very compelling, you know, time to get people comfortable. But, but at this point in time I think this majority of builders in the digital native and the enterprise would get started on databases like MongoDB, Atlas.

Melissa Perry (Host) (43:40)

What I think is really interesting too and listening to you describe this is, I think a key to this is you guys saw this database not just as a thing that held data, but something that was core to a company where a lot of different actions happened, right? It was like the backbone of how you run your business and you've applied so many different types of tools and the way that you manage it and the way that you take care of it back to that. And I think that's like pretty much the foundation of thinking of product management, right Is like how do we think about something that might be simple but complicated in a way where it's not just this, oh, that's how we've done it all the way. Like you just use a database, you just use SQL, but something where we can actually make all of the processes around it and all the things that happen around this product actually better and grew from that. And to me that's really interesting when we take for granted, I think a lot about how we build software or what those components are and just kind of take them for that exists. We all use this, we all use that and like there's no other way to think about it.

Andrew Davidson (44:40)

This, you know, product management is obviously any number of interpretations of what the discipline is, but I think a big part of it always involves what I call kind of the, the mini gm, namely like making the business happen, trying to bend the market, bend reality. How do you do that? How do you change what's understood as possible so that there's a dip in the future? And it's, it's kind of audacious to be to do that. And if you go too, that's where if you press too hard you kind of start seeing people think you're out of whack, right? So you have to be kind of judicious. Like for example, if you're launching a database service as a SaaS, you're going to, I assure you in the first year it's probably a better, better to focus on, you know, getting people to trust that you can do what they need if they're a solo developer, than to go straight to a critical mission critical financial services or healthcare institution. Wait a couple years to go to them because you're not ready, right? And they'll know you're not ready. And you should know you're not ready. But how do you know kind of where the line is that you can go out there and really convince folks, look, I think I'm ready for that. I have an, I've got evidence to feel that I'm ready. I'm, I, you know, and I'm gonna prove to you that I'm ready. And you just keep moving the line and pressing forward. It requires you to sort of be proactive about choosing where to spend your time and energies. But I also think it's what's, what's beautiful about how much meaning you can experience from doing that is, you know, you just constantly are getting the feedback and you're seeing the kind of the, the space of possibility for yourselves grow and essentially by, by impossible to do something that wasn't possible before, you change what will happen. And this is something that's like, it's a reflexive, I don't know if you heard of it. It's like the G paradox concept where basically like in energy economics the, there's a paradox that people end up using more energy. Even when you make energy cheaper and more efficient, why weren't possible before are now possible and hence they're going to be done. You never see less used, you just see more things become possible. And so when you make, when your product makes things possible that weren't possible before, you're now making, you're essentially expanding the possibility space for what they're going to build on top. And that changes kind of the outcome and all of that levels up and over time you're really changing what's possible. And that's kind of exciting.

Melissa Perry (Host) (47:22)

That is extremely exciting. So Andrew, we've been talking a lot about databases and there's probably some product managers out there going why should I care about a database, especially new ones? If you had to explain to a brand new product manager who doesn't know much about tech why they should care about databases, why should they learn about it? How does it affect the products that we might be making on the front end to users and what would you tell them about it?

Andrew Davidson (47:48)

And foremost, the database is absolutely there behind every application. I mean, it's easy to just not realize it's there. Typically a software developer architect is deciding which database to use or it's, you know, they're just using the one that was already there and you know, the, their, that developer's ability to model what they're trying to show or to essentially keep up with a high velocity roadmap is intimately related to whether or not they feel like they're in quicksand using a legacy database, or whether they have a database that allows them to move quickly. They may not express that to you. You know, they may say things like, you know, it's really hard to deliver that, or we have a lot of tech debt or xyz. There may be many of reasons why, you know, it may not. The conversation may not be centered on the database, but the reality is database is kind of the center of gravity. Development software, software in general is very much the hardest part of software is the state is the data. You can change the business logic very quickly, but the data is what you're kind of stuck with forever. And so this is where so many of the fundamental computer solvents are found. And the database is this really powerful thing for the developer that they can push down to almost like an operating system, but for data that basically has critical how well they can build and if they can build efficiently and flexibly, that allows them to build those great software experiences that you and your product design colleagues and others are, you know, hoping that they'll be able to work with you to, to deliver. So that's all important. I think the other thing to keep in mind is database is critical to the uptime and the scalability. So, you know, let's say you have millions of concurrent users on your application, or you wish to someday, or you want to be able to, you know, run that incredible promotion on social and hope that 100 times as many people as usual come into your platform. You need a database that's really built for that elasticity, that can scale long term with linear cost economics. And that's what a database like MongoDB certainly is optimized for. Traditional databases, the relational databases, they would essentially involve scaling with exponential cost issues. So if you wanted to have 10 times as many people on your platform, you might have to pay 100 times as much. It's crazy because they vertically scaled instead of horizontally. So I think these fundamental design decisions like the database and how flexible it is and how it enables a cost at scale to deliver great performance, all of that of course, is critical to any product. If you think of the product as like a mini business, you think about the cogs of your business at scale and the ability to deliver a great customer experience. Database is all critical there something that often gets lost beyond just the database is, you know, a typical application these days at Least if It's not a MongoDB oriented application. What will often happen is that the application will have a relational database. Like, for example, postgres is a popular one that'll be used for kind of what I'll call the core guts of the application. And then what'll happen is the developer will realize that certain features or use cases require uptime or scalability that go beyond what you can do in that relational database. So they'll layer in a key value store, like a DynamoDB off to the side. And then what? What'll happen is you now have data across multiple different systems, so you need to make it searchable. So you'll typically layer in a third system, which, like a search engine, there's popular ones like Open Search and elasticsearch. And then oftentimes your app gets sluggish by virtue of being fractured across a bunch of different systems. So you layer in a cache, maybe like a Redis. So what we often find is, you know, we see people who, you know, thought they were just using a database, but actually they're using four different databases in different ways, and they're learning how to operationalize and manage those. And then they realize it's all brittle and complex, a lot of data synchronization between them. It's hard to change, hard to make. Basically, it's a lot of tech debt, and it's very much those four that we would kind of come in and point out. With MongoDB, you get the, you know, transactional capability and the rich secondary indexes that you might have loved from relational databases, you get the scalability and uptime that you might have loved from a key value store, and you get that search capability research critical for generative AI applications, just all as index primitives out of the box. And because you're not fracturing across a bunch of sluggish engines, you don't have to layer in a cache most of the time. So you get this kind of wonderful superset. Or as someone who, you know, a customer used the word the other day, that just felt like MongoDB kind of give gave the right, the right balance. The Rubik's Cube, where it's like sometimes, you know, you're adjusting, you want to find the perfect balance. This customer that I was speaking to used exactly that analogy for what MongoDB gave them to feel like they could just move fast and not have to be fractured across a bunch of different systems. So what a PM needs to know is the software engineering team's tech debt and ability to Move fast is intimately related to, to the platform on which they're building. And if they have something that allows them to push down and easily and natively and naturally build, they'll be able to build all those great capabilities on the roadmap that much faster, deliver a more scalable economic and high performance experience to the end users.

Melissa Perry (Host) (53:13)

And one thing I want to add to that, because I feel like this comes up with when I work with my developer all the time too, is that you're trying to change a user experience flow or the way that you're trying to sell things or package things. I think sometimes we forget that all that is tied back to a data model. And if it's not easy to change your data model, what might be extremely simple for you to do in design or be able to say, hey, like, let's just make it. This was ours. I was like, I want to make it possible to sell to people a different number of courses and let them provision out like who gets which, which course. It sounds like super simple. And my developer's like, well, that's not how we're structured on the back end though. We have like customers, companies, and the companies have plans and the plans are associated with the courses. So now you want to bypass the plan and then have the courses outside of it. And then we're going to have to think about is each grouping like a plan. So there's a lot more that goes into actually building this. And if you have the right type of database or when you're thinking about architecting this, if you plan to make those types of changes in the future, I think the choice of database, how you're actually architected with that database model, it actually determines how fast you can make those changes or if you can make those changes at all without disrupting a bunch of other stuff.

Andrew Davidson (54:23)

I love that, you know, can visualize like the use case you just described. You know, imagine a JSON style object or if you're a Python person, like imagine a Python dictionary that has structure to it with embedded documents and embedded arrays of sub documents. So like the use case you just described, you know, maybe I have a customer record and I have a sub or a sub field in that record of like plan types. And I have, you know, a sub document for each of the plans. And each plan might have a variety of different kinds of metadata associated with it. Is it an enterprise plan or an XYZ plan? When you realize that you could have all of that shape, all of that structure, just naturally be something that a developer could put into their object that they can then write natively to the database with that same exact shape. That's what MongoDB does, but it gives you the ability to have secondary indexes, which means efficient querying into any of those sub sub documents or fields inside of those sub document arrays. And so it allows you to model out exactly those scenarios that to your point, as a human, it's like I can, as a pm, I could say like, shouldn't we be able to do this? And to be able to more easily feel right, we lose credibility the developer if I ever imply that somehow data modeling goes away. No, it's always front center. In fact, it's more important perhaps than ever in MongoDB. But they're empowered to build the castles in their mind and have the database naturally store them exactly as they envision them. And that's extremely empowering.

Melissa Perry (Host) (55:51)

Well, I think that is incredibly important for all those product managers out there to know and to digest, especially when working with your developers. So thank you so much, Andrew, for coming on the podcast and talking Shop with me. If people want to learn more about you and MongoDB, where can they go?

Andrew Davidson (56:07)

Reach out to me personally on LinkedIn, but come to our website, MongoDB Atlas and get started. You know, I would invite every PM if you're not writing some code, if you're not, you know, using Python or programming language, the hello world experience of understanding what it's like to use a database like MongoDB is the kind of thing you can do in a small number of hours. We have great little, you know, online university courses for, you know, you to learn that in a real quick and efficient way. And it's one of those things where if you're not writing code, then it's hard to connect with the developers that you work with every day. And I want to be clear, I'm not saying you're going to become a software engineer necessarily, but it's so amazing if you could do like what Melissa saying, be able to go in there and pull some data back from the database, answer questions in real time based on what your customers are doing, no matter what kind of business you're in. It's just so valuable to do that. So have you in the mongodb community.

Melissa Perry (Host) (56:57)

And I would definitely suggest if you want to learn about MongoDB, to take those courses. I took them 15 years ago, so I'm sure they're very different now. But a great way to get in there and start understanding how to pull queries and what that actually means. So I, everybody asked me, should I learn coding? And I'm like, no, you don't don't really need to learn coding, but I would suggest learning how to query database. It could teach you a lot about data modeling, how it's structured, what that gets into. So fun for people to play around with.

Andrew Davidson (57:22)

Absolutely. And it's just so valuable what's going on inside my customer base right now. Right. I mean, it's just, it's amazing.

Melissa Perry (Host) (57:26)

Thanks. Well, thanks so much, Andrew, for being on and thank you to our listeners out there. We will put all those links that Andrew mentioned at our show notes@productthinkingpodcast.com we'll be back next Wednesday with another amazing guest. Make sure you like and subscribe this and submit any of your questions to me at. Dear Melissa, we'll see you next time.