Episode 209: From Databases to Developer Platforms: The MongoDB Story with Andrew Davidson
In this episode of the Product Thinking Podcast, I talk with Andrew Davidson, Senior Vice President of Products at MongoDB. Andrew has been instrumental in transforming MongoDB from a traditional database company into a comprehensive developer data platform.
As MongoDB evolves, Andrew shares insights into managing technical products and enhancing user experiences, crucial areas for product managers working with complex platforms. Join us as we explore the nuances of product management in the world of databases and developer tools.
Andrew sheds light on maintaining a balance between technical excellence and strategic management, offering valuable lessons for product managers. Tune in to gain actionable insights on how to approach product management for highly technical products like databases and learn how this can impact broader business outcomes.
You’ll hear us talk about:
09:29 The Spark Behind MongoDB
Andrew explains the motivation for creating MongoDB and how it challenged traditional relational databases, emphasizing the need for a system that aligns better with modern computing demands.
24:32 User Experience in Technical Products
We delve into the importance of user experience within technical products, highlighting the layers of user and developer experiences that product managers must consider.
35:50 Balancing Internal Innovation and Customer Feedback
Andrew discusses the importance of balancing internal innovation with customer feedback, stressing the necessity for product managers to engage directly with users to refine the product.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Episode Transcript:
[00:00:00] Andrew Davidson: 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.
[00:00:07] 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.
[00:00:15] And so, 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 road map that's really pursuing the right opportunities.
[00:00:27] 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. 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. So I think it's, critical to be balanced.
[00:00:47] that can scale long term with linear cost economics. Thanks. And that's what a database like MongoDB optimized for. Traditional databases, the relational databases, they would essentially involve scaling with exponential cost issues.
[00:01:04] So if you wanted to have 10 times as many, you know, 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, you know, These the database and how flexible it is and how it, you know, Enables a cost to deliver great performance All of that of course is critical to any product if you think of the product .
Intro
---
[00:01:25] Andrew Davidson: as like a mini business
[00:01:27] PreRoll: Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you find your way.
[00:01:55] Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.
[00:02:05] Melissa Perri: Hello, and welcome to another episode of the product thinking podcast. Joining us today is Andrew Davidson, senior vice president of products at MongoDB and a transformative leader in the world of data platforms. Over the past decade, Andrew has played a pivotal role in evolving MongoDB from a traditional database company into a comprehensive developer data platform, redefining how modern applications are built and scaled.
[00:02:28] Today, we're going to be diving into the evolution of MongoDB, how product management works with technical products like MongoDB, how user experience is just as important in these types of products, and what product managers should know about databases. But before we talk to Andrew, it's time for Dear Melissa.
[00:02:44] So this is a segment of the show where you can email me all of your burning questions about product management or technology topics in general, go to dearmelissa. com and let me know what they are. I answer them every single episode.
Liveblocks
---
[00:02:57] Melissa: Today's episode is brought to you by Liveblocks, the platform that turns your product into a place that users want to be. With ready made collaborative features, you can supercharge your product with experiences that only top tier companies have been able to perfect. Until now. Think AI co pilots like Notion, multiplayer like Figma, comments and notifications like Linear, and even collaborative editing like Google Docs. And all of that with minimal configuration or maintenance required. Companies from all kinds of industries and stages count on Liveblocks to drive engagement and growth in their products. Join them today and give your users an experience that turns them into daily active users.
[00:03:34] Sign up for a free account today at liveblocks. io.
[00:03:38] Melissa Perri: Here's this week's question.
Dear Melissa
---
[00:03:40] Melissa Perri: Dear Melissa, I'm a newer listener, just started as the first product data analyst on my company.
[00:03:46] There's so much missing in the product organization. I gave my chief product officer, your book Product Operations to start. How can my leadership help me be successful? So if you're just starting out with product operations, you're not alone. Many companies are where you're at, where they don't have a lot of infrastructure.
[00:04:02] They don't have many things stood up as processes or standardizations or tools in product management. So if you are a new product data analyst, your most important job is to help solve problems and answer questions for product managers and product leaders. And you should do that as quickly as possible.
[00:04:21] So what you could do is work with your chief product officer to understand what their biggest needs are when it comes to being able to set strategy, understand, uh, what's going on in the organization. What are you building? How is it rolling up the strategy? What the progress is, and to be able to monitor that and communicate back to leadership.
[00:04:39] So that's one of the biggest gaps that are usually existing in organizations. Having transparency into what we're doing and how that's actually going to amount to driving business results and customer value. You as a product data analyst have big shoes to fill here. Now, what's good is you should start with working with your CPO and talking to them about what questions that they have, but also what the rest of the executives have.
[00:05:03] A good place to start is by solving their problems. Help the executives answer the questions that they need out of product to be able to do their jobs and their jobs are going to be able to align the rest of the teams, uh, make sure that you're roadmapping correctly, make sure that you're projecting and understanding the business trajectory, what you're delivering, when you're delivering, how things will grow.
[00:05:24] All of those questions usually come back to something that you can help with as a product data analyst. You're going to take those questions and you're going to try to figure out what's the best way to display this information. And then this is the most important part. How do I make that repeatable? So you might go in there and do this all very manually, pull things out of systems, make all these views the first time around.
[00:05:43] But then you want to make sure that you're automating it. So you can check that off your list and say, I now have a repeatable way to get these people information. I solved their problem. It's at their fingertips and I can move on to the next problem. Other problems you're going to be looking at. How do I streamline data across the organization?
[00:05:59] You might be working with, um, other data capabilities. Maybe you have developers who have a data team. Maybe you're working with sales ops and looking into their data, go around the organization and try to figure out what's the type of data that our product managers need to be successful. And think about how you build repeatable systems.
[00:06:18] And what you want to do is work with your CPO. To help them to help, to explain to them that these types of systems, these types of databases that you're going to implement, these types of tools are going to help the product managers make decisions faster, which will ultimately allow you to deliver on those strategies faster.
[00:06:37] And to correct course, if you're going in the wrong direction. So your job as a product data analyst is to think about how do you scale this successfully? Not just how you do one off queries for people, but how do I solve these problems for these teams in a repeatable fashion? You want to make sure that your chief product officer understands that, that you're there to aid them.
[00:06:57] You want to make sure that they're giving you the time to bring transparency to you about what types of questions people have. And then you want to go back and forth and make sure that you're building great products And internal tools, basically for them, that's how your CPO can help you be successful.
[00:07:12] And they can also help take those things that you are building and level them up to the executives, right? Show them the good work you're doing. So you get more buy in to go do this further. So they should be advocating for you. They should be using your work, hopefully, and they should be talking about it with other executives.
[00:07:29] You might found it, find it useful so that you get more and more buy in to go out there and do good work. Definitely start with solving the executive's problems first. That's going to give you the visibility you need in the organization to then roll out into other places. Hope that helps.
[00:07:45] If you have more questions for me, go to dearmelissa.Com and let me know what they are. Now let's talk to Andrew.
[00:07:51] Hi, Andrew, welcome to the podcast.
[00:07:54] Andrew Davidson: Great to be here, Melissa. How you doing?
Early Days in Databases
---
[00:07:56] Melissa Perri: 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, OpenSky was like one of the, the companies in New York where our developers were obsessed with MongoDB. They were like, we're, we're doing it this way.
[00:08:13] 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.
[00:08:30] Andrew Davidson: I love that. There's so many great things in that story. On the one hand, lower Manhattan at that time, which is exploding, starting to see the rise of what we then called, the alley corp 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.
[00:08:50] But yeah, MongoDB, 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 this kind of a shadow IT type of people starting 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. Then make it something that you could really build mission critical applications on top of. And, we're privileged today to have 70 percent of the fortune, 100, 50, 000 customers around the world, building on our flagship databases of service offering, which is called MongoDB Atlas.
[00:09:29] Melissa Perri: It's amazing. 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?
[00:09:51] Right? Like, isn't SQL enough?
[00:09:53] Andrew Davidson: 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?
[00:10:17] It was because they were optimizing for the key cost bottleneck in 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.
[00:10:37] 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.
[00:11:02] And those. For developers were extremely rigid, essentially for 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 those tables had a series of problems. It was inflexible, but perhaps more importantly, especially that boom time in 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 of 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?
[00:11:54] And they 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 the user space.
[00:12:12] Part of things for 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 were a developer in 2010, you could use AWS in those early days. It was just EC2 and S3.
[00:12:31] 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.
[00:12:52] I think that's a part of the story that's told less.
[00:12:55] Melissa Perri: So when you 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?
[00:13:08] Andrew Davidson: 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.
[00:13:30] 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.
[00:13:54] Strongly 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 evolved them. I could evolve the actual data models themselves with the flexibility of the document model, meaning I changed my software based on the needs of my end customers rapidly all the time and I don't have to deal with the complexity.
[00:14:16] Of doing the schema migrations, which traditionally were very challenging relational database. And if he's going to continue that trend, over time, the expectations, the velocity the personalization, the scale, the needs for proximity, for example, the rise of mobile, I find someone nearby geospatial capabilities transactional capabilities, critical, for example, and the 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.
[00:14:51] 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 was so limited.
[00:15:16] Melissa Perri: I think about MongoDB too, back in those days in 2010, since it was like, So new, I know I've been out for a little bit we always have 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.
MongoDB’s Longevity
---
[00:15:39] Melissa Perri: 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.
[00:16:00] Andrew Davidson: Think it's been, so many different factors. One is 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 a particular way, which in computing is mind boggling when you think about how much turnover we see in technologies.
[00:16:22] 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.
[00:16:37] And we started seeing this early 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.
[00:16:58] It needs to be available everywhere. It needs to be free forever as an option. And then separately, it continued 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.
[00:17:20] 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 were, 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, it requires really focused efforts.
[00:17:43] 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?
[00:18:01] Melissa Perri: The thing I keep hearing you say like over and over here too, is that You, you really care about the developer experience, right? Like the people who are actually using it and making sure that it scales and it's, it's their mental model, right? Rather than trying to put arbitrary frameworks or structures on top of not how people think, right?
[00:18:18] Like, 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 and what led, what led you here?
[00:18:42] Andrew Davidson: 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 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.
[00:19:07] 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.
[00:19:21] 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.
[00:19:35] They wear suits in New York and they were like, yo tech, we really don't typically wear suits and I felt so, I got it wrong,
[00:19:43] Melissa Perri: That was a big thing.
[00:19:45] Andrew Davidson: 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 the 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.
[00:20:00] 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.
[00:20:18] 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, Palo Alto, San Francisco, but it is very unique to have found it here.
[00:20:37] 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.
[00:20:55] Melissa Perri: 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?
From Database to Developer Data Platform
---
[00:21:13] Andrew Davidson: What 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.
[00:21:35] 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?
[00:21:57] 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's 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.
[00:22:24] I think that was the metaphor that we've long used to think about What
[00:22:27] we're trying to do with the database at MongoDB. 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.
[00:22:47] For someone to realize that you could have, fuzzy search, geospatial capabilities, time series capabilities, and vector search. All on 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.
[00:23:03] They just wouldn't expect that from a database. So this kind of led us to this. We, we should feel confident that putting that value in there and empowering the builder, the developer to discover 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.
[00:23:18] 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.
[00:23:48] Melissa Perri: 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 are working on APIs or, you know different components there.
[00:24:10] 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, then. They would say like user facing ones, but in their mind, user facing is like an app, right? Something I access on the web or an app, a banking you know, a banking transaction, something like that.
[00:24:32] I 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.
[00:24:49] Andrew Davidson: 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.
[00:25:10] 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. And 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.
[00:25:37] 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, an 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.
[00:25:56] 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 naturally used as a human. And what's amazing is that application somehow on the back end is structuring what is being expressed in a database.
[00:26:15] And I think not all PMs actually realize this. Certainly regular folks on the street don't realize this. 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.
[00:26:40] 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.
[00:27:02] 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.
[00:27:19] 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 the 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 delightful experiences.
[00:27:37] 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.
[00:27:53] 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.
[00:28:21] 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'd give them But on the flip side, they're the, 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.
[00:28:39] 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 could run locally.
[00:28:56] And it needs to be able to be something that they can easily weave into their CICD 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.
[00:29:07] Melissa Perri: Yeah, I, 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.
[00:29:30] 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 their Salesforce, what they use every day.
[00:29:44] 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, 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, what is it like to actually 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.
[00:30:25] 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, you know, user facing the customer facing tools, and we don't think about, you know, what's the commercial aspect of that?
[00:30:42] 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.
[00:30:56] So I think that's like a key component to why we need good product management around those things too.
[00:31:02] Andrew Davidson: 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 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.
[00:31:29] 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 more digital forward, cloud forward, maybe their consumer, as opposed to traditional investment banking or X, Y, Z.
[00:31:47] And then you see these kind of culture differences emerge and team structure differences emerge. And I think, a product role, both in a, a technology company like MongoDB, but also in those internal roles, it's all about thriving 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.
Ensuring Product Strategy in Technical Tools
---
[00:32:21] Melissa Perri: One of the big debates we get into as well around this, whether it's, you know, with people who are like your customers and 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.
[00:32:38] 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.
[00:32:49] Andrew Davidson: It's a good, 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 insider, opinion or you know the ideas but I think the other thing to keep in mind is as you get lower down in the Technology stack.
[00:33:20] 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 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.
[00:33:57] 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 to find those kind of one to many opportunities as well.
[00:34:12] 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 at 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.
[00:34:31] 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 road map that's really coming up with the right trade offs and really pursuing the right opportunities.
[00:34:45] 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.
[00:35:05] And then, you're without the credit without doing the other one, you lose the credibility to have the impact in the one you're 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.
[00:35:22] And, almost every developer tool gets started, of course, by people hacking for the things they wish they had for themselves. So that makes sense early on.
[00:35:32] Melissa Perri: and 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. Cause 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.
[00:35:50] 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.
[00:36:05] Andrew Davidson: They hit the nail on the head. Some companies have the. Benefit of using their product a lot more than others depends, right? The dog food is great because it gives you intuition. Sometimes it doesn't happen all that much. Depends on the team, perhaps. But that's why I think the product manager really must be coming up with ways of getting and inviting that insight.
[00:36:23] 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.
[00:36:33] 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.
[00:36:52] Wait until those people come to you to be a little reactive. But my philosophy on this is that similar to how sales people 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 got a good experience for them to really be building that human human connection.
[00:37:21] 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 anytime someone stopped using you, or if they're using you at, you know, 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
[00:37:51] sometime from a customer. We just got one
[00:37:53] the other day someone uh, who you know you couldn't make it up the person said Our team realized what we could do with search is 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 and engineering and other places on the team yesterday And it's like that's amazing.
[00:38:16] Like let's go build a relationship with that customer and 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 need it? You know, so just staying on the pulse proactively is crucial.
[00:38:30] Melissa Perri: That's really
[00:38:32] 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?
[00:38:43] Andrew Davidson: is you can never voice alone, right? Yeah. You're always synthesizing across many and you have to, you have to feel that you're, you know, you're, you're, you're hearing from some solo developers that maybe in a game startup in our world and some others that are in a bank, you want that whole spectrum.
[00:38:59] And if you, if you were to go all in on one
[00:39:02] side. Uh, that would be a risk. And I think just casting net, it 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.
[00:39:17] 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 could be improved. You know, you just find those people that has that, have that enthusiasm.
[00:39:34] They're kind of the core of your community. Of course, if you don't have any people like that, then
[00:39:39] ultimately do you have product market fit at all? It's like,
[00:39:42] are you really solving enough things?
[00:39:44] Melissa Perri: That's a really good point.
[00:39:46] When you were thinking about MongoDB and the evolution, right. That we've been talking about a little bit.
The Rise of MongoDB Atlas
---
[00:39:51] Melissa Perri: 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?
[00:40:01] And how is that different from the early days of MongoDB?
[00:40:07] Andrew Davidson: years of into the Atlas launch for it to become the majority of our company revenue today. It's about 73 percent or so of the company revenue. The. You know, the road to years, 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.
[00:40:36] So you'd have like an S. R. E. 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 OS is 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.
[00:40:59] And while you could do that a lot faster in cloud than you could in a traditional data center. Uh, the reality was that it was 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.
[00:41:19] 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, cloud, the real value of cloud will come from moving up a level of abstraction. Thank you very much. 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 You know software that needs to be upgraded and compliance patched and all these things you just said give me a database and an endpoint to connect to uh, And the service provider like do all that back end complexity.
[00:41:57] And so That's what we're doing It sounds kind of obvious, I guess, but because the database was the center of so much gravity for, for, you know, uptime and, you know, sensitivity around security and just control, like it's kind of the, in the old uh, maybe in like a of an application, someone might've almost thought of the applications front end is sort of like the gates to the city.
[00:42:26] 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 sit, to get comfortable, to be sassified because of that, you know, how can I put the Citadel as a sass?
[00:42:45] That seems all the more concerning, but, 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 was had all the expertise in doing so that could deliver all
[00:43:01] 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, the distributed stateful database system. Uh, and so it was very compelling, you know, time to get people comfortable, uh, but, but at this point in time I think the majority of builders in the digital native and the enterprise uh, would get started on a database as a service like MongoDB Atlas. like MongoDB Atlas.
[00:43:40] Melissa Perri: But think it's really interesting too. and listening to you describe this is,
[00:43:44] I think a key to this is
[00:43:45] you guys saw
[00:43:47] this database, not just as a thing that held data, but
[00:43:50] something that
[00:43:50] was core to a company where a lot of different actions happened,
[00:43:54] 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.
[00:44:02] Back to that. And I think that's
[00:44:04] like
[00:44:05] pretty much the foundation of thinking of product management, right? Is like, how
[00:44:09] do we think about something that might be simple, but complicated
[00:44:13] in
[00:44:13] 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.
[00:44:26] 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
[00:44:37] that, and like, there's no other way to think about it.
[00:44:40] Andrew Davidson: this, you know, product management is, is obviously any number of interpretation of what, what, 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.
Navigating Market Perception and Growth
---
[00:45:04] Andrew Davidson: How do you do that? How do you change what's understood as possible? Uh, so that there's a in the future. And it's, it's kind of audacious to be, to, 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.
[00:45:23] 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. That's a go straight to a critical mission, critical financial services or healthcare institution.
[00:45:41] Wait a couple of 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 haven't, I've got evidence to feel that I'm ready.
[00:45:56] I'm, I, you know, and I'm going to prove to you that I'm ready. And you just keep moving the line and pressing forward. It requires uh, 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.
[00:46:24] Uh, and essentially by, by possible to do something that wasn't possible before you change what will happen. And this is something that it's like, it's reflexive. Uh, I don't know if you heard of it. It's like 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 uh and more efficient to Uh, 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. Uh, and that changes kind of the outcome and all of that levels up. And over time, you know, you're, you're really changing what's possible. And that's kind of exciting.
[00:47:23] Melissa Perri: that is
[00:47:23] extremely exciting.
[00:47:24] So Andrew, we've been talking a lot about databases and there's probably some product managers out there going,
[00:47:29] why should I care
[00:47:31] about a database? Especially new ones.
[00:47:33] If you had to explain to a.
[00:47:35] Brand new product manager who doesn't know much about tech, why they should care about databases, why should they learn about it?
[00:47:41] How does it affect the products that we might be making, on the front end to users and what would you tell them about
[00:47:47] it?
[00:47:48] Andrew Davidson: and foremost, the database is absolutely there behind every application. I mean, it's easy to just not realize it's there. Uh, 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.
[00:48:03] And, you know, the, their, that developer's ability to, to, 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 to deliver that or we have a lot of tech data xyz There may be many of reasons why 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.
[00:48:47] You can change the business logic very quickly, but the data is what you're kind of stuck with forever. Uh, so this is where so many of the fundamental computer problems 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 uh, 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 deliver.
[00:49:19] So that's all important. I think the other thing to keep in mind is database is critical to 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 a hundred times as many people as usual come into your platform.
[00:49:41] No, you need a database that's really built for that elasticity that can scale long term with linear cost economics. Thanks. 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.
[00:50:02] So if you wanted to have 10 times as many, you know, 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, you know, These fundamental design decisions like the database and how flexible it is and how it, you know, 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 And 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 databases You know, a typical application uh, these days will, you know, 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.
[00:50:59] And then what'll happen is the developer will realize that certain features or use cases require uptime or scalability to go beyond what you can do in that relational database. So the layer in a key value store, like a dynamo DB off to the side. And then what, what will happen is you now have data across multiple different systems.
[00:51:16] So you need to make it searchable. So you'll typically layer in a third system, which like a search engine, the popular ones, like open search and elastic search. And then oftentimes your app gets sluggish by virtue of being fractured across a bunch of different systems. So you layer in a cache. So maybe like a Redis.
[00:51:32] So what we often find is, you know, we, 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.
[00:51:47] 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 uh, and you get that search capability search critical for generative AI applications, just all as index primitives out of the box.
Balancing Speed and Stability in Tech
---
[00:52:16] Andrew Davidson: And because you're not fracturing across a bunch of sluggish engines, you don't you don't have to layer in a cache most of the time. So you get this. Kind of a wonderful superset or as, as someone who uh, you know, a customer used the word the other me that just felt like MongoDB kind of give, gave the right, uh, the right the Rubik's cube, where it's like, sometimes, you know, you're, you're adjusting and 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 the platform on which they're building. And if they have somebody that allows them to push down easily and natively and naturally build, they'll be able to build all those great capabilities on the road map that much faster, deliver a more scalable, economic and high performance experience to the end users.
[00:53:13] Melissa Perri: And
[00:53:13] One
[00:53:13] 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,
[00:53:31] what might be extremely simple for you to do in design or be able to say, hey, like, let's just.
[00:53:37] This was ours. I was like, I want to make it possible to sell
[00:53:39] To people a different number of courses and let them provision out
[00:53:43] like who gets which, which course. It sounds like super simple.
[00:53:46] and my developer is like, well, that's not how we're structured in the backend though, we have like companies and the companies have plans and the plans are associated with the courses. So, now you want to like 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.
[00:54:03] this. And if you have the right type of database or the, 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
[00:54:19] can make those changes at all without disrupting a bunch of other stuff.
[00:54:23] Andrew Davidson: I love that you know, can visualize like, 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.
[00:54:46] 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
[00:54:58] enterprise plan or an XYZ plan? When you realize that you can have all of that shape, all of that structure just naturally be something that a developer could put into their object.
[00:55:08] That they can then write natively to the database with that same exact shape. That's what
[00:55:11] MongoDB does. But it gives you the ability to, have secondary indexes, which means efficient querying into any of
[00:55:17] those sub, sub documents or,
[00:55:20] or, 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?
[00:55:31] Uh, and to be able to more easily, trivial, right? We lose credibility with the developer. If I ever imply that somehow data modeling goes away. No, it's always front and 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.
[00:55:48] and that's extremely
[00:55:49] Melissa Perri: Well
[00:55:49] Andrew Davidson: empowering empowering
[00:55:51] Melissa Perri: I think that is incredibly important for all those product managers out there to 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
[00:56:05] go?
[00:56:06] Andrew Davidson: Well, reach out to me personally on LinkedIn, but come to our, uh, 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 uh, 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.
[00:56:27] We have great little, you know, online university courses for, you know, you to learn that in a real quick and efficient way. Uh, and it's one of those things where if you're not writing code, then, you know, 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. Uh, but, 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
[00:56:53] business you're in uh, it's just so valuable to do that. So have you in the MongoDB community.
[00:56:57] Melissa Perri: And I would
[00:56:58] 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,
[00:57:04] but it's a great way to get in there and start understanding how to pull queries and what that actually means. So I,
[00:57:10] everybody asks me, should I learn coding?
[00:57:12] 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. Absolutely. And it's just So valuable what's going on inside my customer base right now. Right. I mean, it's just amazing just, it's amazing for a project.
[00:57:28] 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 at product, thinking podcast. com.
[00:57:36] We'll be back next Wednesday with another amazing guest. Make sure you like, and subscribe this and submit any of your questions
[00:57:41] to me at dear Melissa.
[00:57:43] We'll see you next time.