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.
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.
And so product management is critical to being plugged in with the engineers with traditional inbound aspects, making sure that together you're coming up with an execution roadmap that's really pursuing the right opportunities.
But then on the outbound fraud out there with customers understanding what's working, what's not, what could be taken to the next level.
And 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.
But it can scale long -term with linear cost economics.
And that's what a database like MongoDB 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 the database and how flexible it is and how it enables a cost to deliver a great performance, All of that, of course, is critical to any product.
If you think of the product as like a mini business.
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 think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
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.
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.
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.
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.
Sign up for a free account today at liveblocks .io.
here's this week's question dear melissa i'm a newer listener just started as the first product data analyst at my company 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 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.
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 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.
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.
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, 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.
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.
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?
You might be working with 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.
And what you want to do is work with your CPO to help them 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 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.
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 product and internal tools basically for them.
That's how your CPO can help you be successful.
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 who might 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 gonna give you the visibility you need in the organization to then roll that out into other places.
Hope that helps. If you have more questions for me, go to dearmelissa .com and let me know what they are.
Now, let's talk to Andrew.
Hi, Andrew. Welcome to the podcast.
Great to be here, Melissa.
How are you doing? 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 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.
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 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, 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 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 databases service offering, which is called MongoDB Atlas.
It's amazing. I remember to 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 sparked MongoDB?
How did it get started?
And why did they create another database company compared to SQL?
Isn't SQL enough? Certainly.
One thing's for sure.
It's not easy to create a new database company that challenges something that has so much inertia in our industry.
Something like relational databases, which dated back to the 1970s.
in which had just become so ubiquitous.
And 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 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.
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, their 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 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 of their objects.
It wasn't just that, which is the user space part of things for a developer.
It was also the backend.
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 were thinking about MongoDB in those early days too, if a company is choosing to use it, what types of benefits are they going to get from a business value perspective to do that?
The fundamental thing that comes 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 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 evolve 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 doing the schema migrations, which traditionally were very challenging in a 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, for example, 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, 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 the relational database at its core was so limited.
I think about MongoDB too, back in those days in 2010, since it was like, so new, and it's 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?
Is this the next cool, amazing 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 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.
I think it's been so many different factors one certainly the the market was ripe for something new and yet there was just so much inertia there was you know 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
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 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 have a commercializable business?
The thing I keep hearing you say like over and over here, too, is that you really care about the developer experience, right?
Like the people are actually using it and making sure that it scales and it's their mental model, right?
Rather than trying to put arbitrary frameworks or structures on top of not how people think, right?
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 in other companies too.
What got you excited about a database type company where you said, this is an interesting product challenge.
What led you here? My own personal story is a little funny in that 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 got to, not sure what I'm going to, 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.
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.
But But 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 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.
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.
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 office in 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 barely even know what a database is, but the door can be opened 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.
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?
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 at 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 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.
For someone to realize it, 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.
What I think is interesting here is that we're talking about a database here, which is one of the most basic 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, 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.
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 choose.
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 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 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 topped out, 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 a great application is one in which 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 backend 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, it 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 developers 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 delightful 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, 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 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.
and 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 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.
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 in 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 sales people 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 sales force what they use every day and if you're mad at sales force 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 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.
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 user -facing, the customer -facing tools.
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.
So I think that's a key component to why we need good product management around those things too.
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 approach.
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 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 at 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.
Then you start seeing diminishing returns.
This is the constant tension I think for product managers.
One of the big debates we get into as well around this, whether it's 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.
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?
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 at a technology like this to actually harness that wherever possible.
It's great to have that internal feedback or 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, 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.
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 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, 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 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.
By the way, I'm a big believer that product managers should absolutely be 50 -50 on that inbound -outbound.
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 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 and almost every developer tool gets started, of course, by people hacking for the things they wish they had for themselves.
Yeah. That makes sense early on.
And that brings up a good point too, is that 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 giving us some feedback here and we're incorporating that.
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.
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 think it's very easy, particularly in a company that gets large enough that it might have customer -facing employees like sales or solutions architects or customer success managers, it's very easy once you're at that level of scale to 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 is a good experience for them, to really do building that human -to -human connection.
So I think it's what I always encourage the team to think about is anytime someone's using you for the first time or anytime someone stopped using you or if they're using you at a unique level of sophistication or scale compared to most others, 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 sometimes from a customer we just got one 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.
Literally, that product manager shared that insight with a bunch of colleagues in engineering and other places on the team yesterday.
It's like, that's amazing.
Let's go build a relationship with that customer.
Understand, do they still feel that way six months from now?
Or did we not continue to evolve in the ways they needed?
Just staying on the pulse proactively is crucial.
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 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 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 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 could be improved.
You just find those people that have that enthusiasm.
They are kind of the core of your community.
And of course, if you don't have any people like that, then ultimately, do you have a frotic market fit at all?
It's like, are you really solving enough things?
That's a really good point.
When you were thinking about MongoDB and the evolution 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 yeah so and by the way it was five years of into the atlas launch but for it to become the majority of our company revenue
today it's about 73 percent or so of 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 auto -scaling by replacing them in an individual manner.
And while you could do that a lot faster in cloud than you could in the 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 extraction, 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 compliance patched and all these things.
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.
It's kind of in the old, maybe in like a tradition 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 SaaS -ified because of that, you know, how can I put the Citadel as SaaS?
That seems 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 at this point in time, I think the majority of builders in the digital native and the enterprise would get started on a database as a company to the Atlas.
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?
It's 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, 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.
Product management is obviously any number of interpretation of what the discipline is.
But I think a big part of it always involves what I call kind of 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 kind of audacious 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 better to focus on 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 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.
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 uh 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 uh i don't know if you heard of this 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 your product makes things possible that weren't possible before, 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 really changing what's possible.
And that's kind of exciting.
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?
First 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 they're just using the one that was already there.
And 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.
They may say things like, it's really hard to deliver that or we have a lot of tech data or X, Y, Z.
There may be many reasons why the conversation may not be centered on the database, but the reality is database is kind of the center of gravity.
Development, 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.
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, 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, are, you know, hoping that they'll be able to work with you 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 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, you know, people on your platform, you might have to pay 100 times as much as 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, 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 a typical application these days, at least if it's not a MongoDB -oriented application, what will often happen is the application will have a relational database.
Like, for example, Postgres is a popular one that'll be used for kind of 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 to go beyond what you can do in that relational database.
So they'll layer in a key value store like a DynamoDB option to decide.
And then 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 is like a search engine.
There's popular ones like OpenSearch 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, there'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 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, it just felt like MongoDB kind of gave 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 the platform on which they're building.
And if they have something that allows them to push down 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.
One thing I want to add to that, because I feel like this comes up 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, like, let's just make it possible.
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 who gets which course.
It sounds super simple.
And my developer is like, well, that's not how we're structured on the back end, though.
We have 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 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 a 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.
I love that. You can visualize, like the use case you just described.
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, maybe I have a customer record and I have a sub field in that record of plan types.
And I have 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 X, Y, Z 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, 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 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, right?
We lose credibility of 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, and that's extremely empowering.
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?
Reach out to me personally on LinkedIn, but come to our website, MongoDB Atlas, and get started.
I would invite every PM, if you're not writing some code, if you're not 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 online university courses for 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 can do like what Melissa and 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 how are you in the MongoDB community?
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 it's a great way to get in there and start understanding how to pull queries and what that actually means.
So everybody asked me, should I learn coding?
And I'm like, no, you don't really need to learn coding, but I would suggest learning how to query a 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, it's amazing.
Exactly. 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 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.
Thank you.
