How MongoDB Transformed From Sales-Led to Product-Led Leading to 20x Increase in Market Cap with Sahir Azam

Building processes and a culture that encourages cross functional communication and collaboration to me is fundamental. It's really easy to get stuck into talking to just your team or your leadership up the chain in a hierarchy of any organization. It's a lot harder to feel comfortable going across lines, but I think that's what makes the best companies great. Product managers in many ways are routers in an organization. They're communicating things across different functions of an organization to deliver a successful outcome. Engineering to finance, to support to sales. That horizontal communication and learning how to be good at that is number one. I need some traction. You need some traction. Let's get some traction.

Hey what's up innovators, entrepreneurs, visionaries and disruptors. This is your Traction Podcast host Lloyd Lobo We're a community of over 100,000 people just like yourself, on a mission to help you get the methods, the money and the madness to explode your business growth. Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more, this episode is brought to you by Boast AI. Each year the US and Canadian governments give out billions of dollars in R and D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits and receiving the money can take up to 16 months. Boast AI gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast AI software to maximize cashback. Check out B O A S T. This episode is also brought to you by Launch Academy, an international tech hub that provides mentorship, resources, network and the environment for entrepreneurs to launch, fund and grow their startups. Since 2012, Launch Academy has incubated over 6,000 entrepreneurs, of which 300 have grown their startups past Seed and Series A and have collectively raised over $1.2 billion in funding. To learn more about Launch Academy's programs, check out LaunchAcademy CA. Special thanks to our Podcast partner Content Allies From Podcast Production and Promotion content allies helps B2B companies build revenue generating podcast. We recommend them to any B2B company that's looking to launch or streamline their podcast production. Learn more@contentallies.com so exciting topic here today.

Because if you look at it, some of the fastest growing companies of the last decade have been product led companies. Slack, Dropbox, Zoom, you name it. And it's not easy to build a product led company. It takes a long time and our friend here has done the unthinkable. He's converted MongoDB from a sales led company to a product led company and everyone's trying to learn how to build a product led company. And a lot of companies today, SaaS companies particularly are sales led or they start sales led. It's not easy building Product LED and MongoDB did the reverse. And so we're excited to learn all about that. Sahir is the chief product officer at MongoDB and you're responsible for product management, growth and the whole GTM strategy across the portfolio. And you joined I think in 2016. You spoke at our event a couple years ago, the last in person event we did in Vancouver.

It was 18 or 19.

Probably it was 19. Yeah. You came to Vancouver in 19 and so you joined as the SVP of Cloud and GTM and you helped grow the business to hundreds of millions, which is amazing. And prior to that you were at Sumo Logic and you have a great history in tech and running products for hyper growth companies. Welcome to Traction Zaire.

I'm happy to be here Lloyd. Looking forward to the conversation.

So before we jump in, why don't you give us your backstory. You have a very interesting background from VMware to Sumo Logic, MongoDB et cetera. How did you get into all of it?

Yeah, I'd say early on in my career I was in pretty hands on technical roles. I was at probably SRE today but it was really more all bundled into sort of systems administration and support a long time ago. Then I got a real break in my career when I got reached out to by a recruiter to become a pre sales engineer. So this is technical engineer supporting the sales organization of a software startup out of Boston and that company called was called bladelogic and built enterprise software for large organizations to help automate their management of their large server fleets at that point and at that time in all honesty I had no idea what a pre sales engineer really was. I just knew it was a, it was a combination of hands on technology and the ability to get in front of people. But that was really a pivotal moment in my career because it helped me realize that what I truly enjoyed was the intersection of business and technology and translating sort of those things and that ultimately over the long term led me to role a career in product management and product leadership. But I spent time in pre sales engineering, sales product marketing. So I had a variety of different roles, some technical, some business oriented over the years.

That's a great experience. My first job was in solutions sales engineering and then I went into product and whatnot. But is that advice, I guess for most people is if you want to get into product, maybe get into the GTM side of things, understand how the product works and the sales side would that. Is that what you would say is you've had this unique.

Yeah, I would. Now does that mean that every single successful product person has to have had a full time role in one of those things? No. I know product managers on our team today at Mongo that have never been in the seat in a go to market role but have tons of customer empathy, know how to engage with the field, how to work through marketing and all of that. So it is certainly a skill you can learn. However, I believe quite heavily in a 360 degree product manager profile, meaning being able to work with sellers in the field and support and customer facing roles and support them effectively while while also working obviously inbound and managing sort of a, you know, sort of a product management process with engineering. I don't think you can be a really successful product manager today and be too weighted in one of those other domains. You need to be really balanced.

So you joined when you joined MongoDB because I know Megan Eisenberg, she's actually spoken at every conference of ours through 2018 and it was a very much a sales led company. She was a CMO at MongoDB at the time and we had Elliot speak.

In the first year of the conference as well.

You guys were a sales driven organization. Sales led organization. Why make that shift and what led you to it?

Yeah, this one's a bit nuanced and honestly I think the industry itself is still figuring this out and evolving. But from a MongoDB perspective, what's interesting is in a lot of ways we've always been a sort of product led company in the sense that the way organizations start getting going with our technology and learn about us is very much bottoms up. It's community driven, it's developers using our open source technology, building their first application on it, prototyping it and that's what even gets us an entree into large organizations. Now to your point, in the software side of our business, the monetization model is definitely much more outbound sales led. It's a really an enterprise focused product. And what I mean by that is it's really centered on large Global 2000 organizations, government, et cetera. And it's not really a product that scales down market from a monetization standpoint, but in terms of the go to market and what drives the funnel and how we acquire interest among going to be. In a lot of ways this has been like many open source companies, a product led motion from the get go. I think the big shift for us was starting in 2016 with the launch of Atlas when we started to really shift over time the majority of the company's revenue from a commercial software on top of our open source space to really becoming a full blown SaaS vendor. That afforded us the opportunity to really drive what today is called a product led growth motion in the SaaS context. Which is how do you drive a free or free trial experience, drive really efficient acquisition of customers at scale even when over time many of them might migrate over to sales. So that was all new for us and I think one of the more interesting parts about that transition is how it allowed us to really diversify our go to market strategy. Absolutely. We are still very much a really enterprise focused organization in the large top of the market. But what it's allowed us to do is drive high velocity inside selling to accounts that are not necessarily at that scale yet or and as well build a direct to developer B2C style self service business. Those are all off the bat of this SaaS transformation. We don't view sort of product led and sales led as in opposition to each other. Our CRO, Cedric and I spend a lot of our time thinking about how we think we call this kind of omnichannel go to market where, how do we meet the customer, where they are based on the profile and where they are with the journey of the company to make sure they have the right engagement model with us, whether that's touchless and product only or whether that's through a sophisticated enterprise sales motion.

And then prior to you guys going on this path of Atlas and maybe it's worthwhile describing what was MongoDB's, how was it sold before Atlas and define Atlas for us maybe in a couple of months here.

Absolutely. So on the software side of our business we like many open source companies have a the core of our technology is source available open source software with our core database. The majority of our engineering investment today goes into our free software and that in many ways is very top of the funnel or the outer sort of ring of our adoption. That's about community learning, building a base of users who love the technology and experiment with the technology and that powers multiple products in our portfolio, whether that be our commercial software version that we go sell to large enterprises around that or our SaaS version which is called Atlas and open source, that's adoption that it drives is crucial to powering the company's long term adoption in the market now over 10 years and certainly going forward hopefully for many decades. So that's the foundation. But then on the software side, we tend to really monetize by selling a subscription software license that includes proprietary technology that help large organizations adopt our technology. So management tooling, backing up the database, monitoring the database, upgrading it, as well as support from the company that builds the database. If something should go wrong, they know they have somebody to lean on as partner. And that's just to be clear. It's still a very successful and growing part of our business because there are many enterprise organizations that are not necessarily all in on the cloud yet or will get there in the future, but are still looking to modernize off legacy technology. So we want to make sure that they have an offering from us even in a corporate data center, not in the public cloud. So that's our software model. And as a reminder, that's really focused on the top of the market. And then on the SaaS side of our business, the product portfolio there is called Atlas, which is really a SaaS version or a hosted version of that database combined with a bunch of other services integrated around that database that simplify the data architecture of an application. And what that's done is it's allowed us not only to target enterprise, certainly large enterprises are driving a lot of the consumption of that service, but also scale much more effectively to kind of the mid market, get much broader global reach than we could accomplish if we were just trying to organically scale out our feet on the ground with the sales organization. So it's really made our go to market much broader than it were just off the backs of enterprise software.

What are the main KPIs you focused on when moving to this product LED or adding the Atlas model to the traditional sales LED model. And would you change these KPIs if you were to start from scratch?

I don't think there's one KPI. On one hand we were maniacally focused on just looking at the overall percentage of company ARR or bookings at that time coming from our SaaS product. Given we knew it was so strategic that if we got it right, it would be transformational for the company and provide a tailwind for a very long time. And so we were maniacally focused on clearly like the percentage and that was a proxy for are our sellers picking up this technology properly? Is our self service funnel growing? Are we learning how to become a B2C style marketing organization acquiring large volumes of developers coming into our funnel. And so that was an output metric clearly of a lot of underlying execution tactics and KPIs that we measured. But I think if I had to distill down, one of the most important ones, beyond just the aggregate revenue is the volume of paying customers we have is really important to us because in a traditional just outbound enterprise only sales model, there are so many accounts you can go after that are at a certain level of size and complexity. Where that go to market model is efficient makes sense just given the ASP of those accounts. But if we really want to reach the entirety of the market where you have customers that are spending nothing or ten twenty dollars and we have customers that are spending ten dol. So how do you reach and efficiently monetize that whole market that required us to have self service and product led models for acquisition and engagement and retention. And that to me is much more about the volume of customers we're bringing in engaging and retaining over time than it is purely about the aggregate ARR alone. And so we're always looking at that juxtaposition of the total size of business plus how diverse we are, how many companies we're engaged with and brands we're directly connected to.

Because prior to that probably at the limit, you're hitting limits of what your salespeople can find effectively.

Yeah. And don't get me wrong, from a revenue standpoint, the largest opportunities are by far still engaged with our very successful and kind of sophisticated enterprise sales team. But the idea is you were creating a flywheel. So today's large enterprises might be today tomorrow's sorry, large enterprise customer, large spending customer might be today's CTO on a Gmail account in our free tier. So how do we make sure we nurture that whole model? Because there's just so much turnover happening in the large enterprise segment because of that dynamic of disruption happening on the backs of software. So that in our eyes deems a go to market model that we must capture the wide net, get people engaging with our brand and then efficiently identify which ones engage with sales or which ones aren't ever going to start with the product but still need more traditional marketing tactics or outbound pipeline generation tactics with our sales organization to break into that established large enterprise brand.

And you said Atlas fundamentally changed the way MongoDB operated as a company from engineering roadmap to sales and go to market. Walk us through that.

Unpack that.

Because there's a lot in there.

There's definitely a lot in There I think I talked to a lot of companies that are thinking about transforming from a software business to a SaaS business or perhaps it's an open source company looking to build a go to market model and think through the trade offs there. And I the thing I bring up is it's quite easy for everyone to understand the sort of technology side difference of running a service and hosting, operating a product and what that means versus shipping software. I think that's a little more intuitive. But ultimately if I look at what drove our success thus far, fingers crossed, it's that we looked at it as a company wide transformation. And so if you look at support, we have support teams that engage in completely different ways now via chat or manage a long tail of customers that just wasn't ever really relevant when you're dealing with a small number of large customers that you're getting on the phone with once a quarter. We have our financial model of our business, our financial profile has changed as a fact of business versus software business. Our sales organization, the way we compensate them, the way they focus on landing a customer quickly and as frictionlessly as possible and scaling them over time versus necessarily only optimizing for that kind of big upfront transaction that has profound effects and forecasting and compensation model and profile of the sellers that we have. Our marketing organization is completely different than four years ago in terms of the breadth of engagement that we have kind of worldwide and directly reaching out to developers at scale. And so every sort of part of the organization in some way, shape or form has gone through a pretty significant evolution or transformation depending on where they were on that journey. For us to really become a great product led SaaS company, it's not just good enough to say hey, our engineering team hosts the product. Now for customers you have to really think through everything about that customer journey, which is as much about the people and the business side of the equation as it is to technical side.

As you're going through this journey or as people in the audience are going through this journey, what are top recommendations to think about for each of those departments? What are the kind of people you hired maybe or what are some processes, best practices you instituted? Maybe in the go to market side and also on the product side that would be a failure if you didn't have.

Yeah, I think one, I think that's agnostic to both parts of the product and parts of the go to market organization is a culture of experimentation and iteration. And what I mean by that is there's a very sort of obvious meaning of that which is you're optimizing your product experience, your funnel and the website, your web experience with AB testing and a very sort of data driven approach and a culture of trying things out, learning from that on a rigorous and repetitive basis. Because that's how you drive sort of consistent growth beyond just like the big ideas, new product launches, new features and whatnot. So building that foundation of data and analytics, the culture of how to do that scientifically and getting people comfortable, taking risks on experimentation, I think is one really important thing that on the technology side. But that same idea extends out to the go to market organization, our sales leaders and our marketing leaders. Like we have that same culture where we're piloting new programs, new ways of engaging with customers, new offerings. If we're talking about sort of of things like services and whatnot to help customers get successful. And we view that as fluid and evolving continually as our product does in terms of agile development or iterative development. Like we think of that our people side of our organization, our sales side of our organization, which is much of that sort of nature. This is not a fixed model that worked 20 years ago and somebody invented this is like we're inventing, evolving our go to market and the intersection with the product continually. So I think that's a foundational sort of cultural and best practice to definitely focus on and implement. The other is really making sure that there is, I don't think you can build a really successful product LED model if you don't have a really solid loop between the people in the organization engaging with customers. And that could be CSMs, support sellers, pre sales engineers, whatever it might be and bringing that feedloop back in a much more rigorous basis than the traditional just product management process of rolling that up once a quarter or whatever. It might be like getting a this cultural loop where those teams are operationally talking to each other every week and coming up with experiments together, figuring out what's what are areas for improvement or opportunity is huge. Because what we found is that the sort of product led folks and the analytics team and marketing, the analytics and product folks on working and AB testing different ideas in the product, they come at things naturally and in a good way from a very quantitative point perspective. But when you merge that with folks that are having hundreds of calls a week, potentially talking to end customers, you can't proxy the intuition that comes from that qualitative touch for the customer. So getting those two things to merge together ultimately builds a much better organization, a much better product. But it takes, I would say Intentional effort because it's very easy for organizations to stay in their little silo. CSMs talk to CSMs and support talks to support engineers and whatnot. But creating processes and operational models where those teams are horizontally talking to each other again, not once a quarter in a readout, but on an operating rhythm of every week or every day, I think is crucially important.

I want to dive into that because that is really fascinating and it's interesting for almost everyone in most organizations. And I find even at boast here sales does something, we sell it and then there's some feedback provided to product and engineering and it's just, it's, it feels siloed.

Right.

It's not like the way you talk about it. And so what are some tactics we can, and the audience here can put in place, measures in place to make sure that horizontal dialogue is happening weekly. There's that collaboration because traditional product and engineering guys, you come from a sort of sales and solutions engineering background, so you know how to work very closely. But traditional product people and engineers, they don't work with the GTM side. And so how do you bring them together?

Yeah, I think there are layers to that one. I think if you have a product organization that isn't spending at least 40, 30% of their time in front of the customer, somehow either directly or engaging with the field teams that are one degree removed, maybe something's wrong if you become a very insular product organization. If you're not, it comes back to that whole 360 degree product manager sort of concept I brought up earlier. So I, I look for very balanced skill sets and PMs that can grow into being just as comfortable in front of a customer supporting a deal as working on a stand up or meeting with engineering. And that takes time to develop. If you're a PM coming out of engineering, we're, we create exposure opportunities to learn those skills and vice versa. If we have somebody coming out of the field, we have to compensate and get them understanding our engineering process or documentation. Now we define requirements, all that type of stuff, you have to foster that. But I think that's like a, for me, that's a philosophical sort of foundation. For me you have to have a very outbound and inbound balance. So I think that's at a macro level in terms of skills and what we look for in product manager clearly, like making sure your product management process on the the big rocks is always anchored in listening to the customer, that you're using data, the field, the support organization, et cetera. Have A strong voice in that. I don't think this is like controversial, but many organizations aren't very good at that, even though it sounds like table stakes. So even in quarterly planning or readouts on a more I'd say traditional sort of cadence, making sure that baseline is there, that's really important. But then to get to what I was just referring to this more specifically of intimate operating cadence, we focused on really an operating rhythm with the leaders of different functions have cross functional operating meetings on a weekly basis. So we for example created a squad model for our self service business where we have representation from the various functions in marketing. The product manager, someone from developer relations and somebody from our sales assisted sort of part of the sales org where they interact with self service customers and nurture them perhaps before they're ready for a contract. That's all one team that meets weekly and does operational readouts of what they're working on, what they've learned from, whether it be an experiment or some customer interaction they might have had that they thought was indicative of a trend. So that builds trust, that builds relationships. So such that people are comfortable reaching out across the aisle and just like bouncing off a csm, an idea for a product capability or an experiment. But it takes intentional focus on one, creating that operating rhythm and then secondly also measuring people on shared goals that everyone ultimately knows what the North Star metric they're trying to drive is that changes depending on what their function is. And that team feels like it's a shared model, whether it doesn't matter whose idea it was, it doesn't matter if it was sales or marketing or product. Like we're all looking at the same overall growth of the business and success that comes with proper goal setting alongside that operational cadence.

When you say squad model, is it like a. A cross functional team like you described and they're accountable. There's a vision mission KPIs and it's not like they have their own separate KPIs.

Or maybe they do.

It's one team. Describe an ideal squad because you probably have multiple squads there.

We have multiple squads, but the idea is exactly what you're talking about. It's a cross functional team. All the Oregon parts of the organization have very top level business outcome metrics, but at a more kind of micro level. At the team level, each squad is responsible for some segment of the funnel or a customer engagement. So how many? I'll give a great example of this. Our activation squad or engagement squad is focused on how many people not just sign up for our product, but actually get people to experience what we defined as our aha moment and then ultimately develop habitual usage of the product because though we know certain actions are inputs to ultimately converting into a sticky paid customer over time. So that team has that goal and then they have a backlog of projects that and experiments that they're running in their domains to try to move that metric at a week over week or quarter over quarter. So that's one model. It's organized around engagement or operational metrics across the funnel and trying to move the needle on that consistently. Another model that we have is we have a bunch of new products in the company that we've launched over the last couple years, some of which target very unique audiences or have a different positioning and go to market motion in some ways. So we have certain product squads. We have one, for example, our mobile database and technology called Realm, which is a team of experts focused on that user base, that product, that Persona, and really trying tactics and experiments for the first time by and large to figure out what works for that audience before maybe it becomes evergreen and just consistently running by the broader core functional team. So these are not necessarily squads that are always going to be here three years from now. Now some of them will, some of them won't. But whenever we feel like we need a focus area and strong cross functional alignment, we try to create these virtual teams, assign a leader for it that doesn't have like necessarily everyone in that team reporting to them, but can focus on, hey, just I'm helping operate this squad. We're measuring our success together, week over week. And the other benefit of it is it puts autonomy and decision making down the organization such that like each squad should has a goal and a number they've got to ultimately try to move. They're going to come up with ideas and experiments because they're much closer to the ground across their functions than any executive sitting in an ivory tower on some idea that we came up with or just some product manager coming up with it in isolation. So it's about fostering and crowdsourcing, for lack of a better term, knowledge from every function in a way that can drive sort of the experimentation culture we have that drives ultimately the earlier part of our customer engagement.

What is the ideal paw sort of squad structure? Like how many people is a max? And then who are the. So you described as the squad leader? Yeah, I'm assuming that's typically a pm, or is it not?

It doesn't have to be a pm. We have squad leaders that are in marketing functions. If most of the squads work is upper funnel type stuff, we have areas where somebody from product, in other cases we've had someone more senior in the organization step into that role. I think it's more around around who you think has the ability to work cross functionally influence people without authority necessarily and also somebody who can think about in a cross functional way. I think that's another important thing. But we're not too pedantic around. It's got to be a PM or it's got to be a particular role. Size wise we try to keep things sub 10 people and that's not to say that we always meet that bar. But generally speaking, if you're going to create a cohesive team that can iterate quickly, we try to keep it at a manageable size that people can read out in a half an hour what the experiments are, what the learnings are, share that with the team and where there are others involved, like we lead it to those squad members to bring that back to their broader functional team. So if you have like a digital marketer sitting in one of the squads, they're hopefully sharing what their engagement in a particular area is driving back to the all the digital marketers functionally aligned in their reporting structure.

And then is there a format that you guys use to communicate? Is it a one pager? What are the key things? Because sometimes I see conversations in these squad meetings. Things can keep rambling and rambling and so on.

Yeah, so we tend to be big memo and Google Docs users at the company in terms of decision making. We tend to ask folks to write stuff down and it doesn't mean that they have to have the Queen's English so to speak. But I think it's helpful to have people put the rigor in and clarity of thought to document the point of view they have, the options, the gives and takes and the trade offs towards a decision that could be something small like an experiment. What the rationale for the experiment is, what the metric is we hope to move and then of course what we learn after the fact or it could be like this flows all the way up to the top of the company. The executive team. We tend to when somebody brings a new proposal to us or we have an issue, it comes in a memo form. So that's one thing that really has helped us I think drive better decisions and have you spend more time on the substance and not as much time on the fluff or preamble. Because people can read and understand a lot of context in written form. Pretty quickly. So I think that's one. And then in terms of rigor though, for the these squad meetings, those tend to be like an operational check in meeting where each team is giving an update on a current experiment, its state, when it's going live, it's running live, what the early results are and what the learnings are. And it's up to the squad leader just to keep that operating cadence going. And there's an art here because sometimes you want that conversation to potentially, if it's a valuable conversation, feel the same way about team off sites. If you keep things too structured to a particular every half an hour, you got to say stick to the agenda. You risk sometimes losing the goal of what an organic conversation can create. And so you have to have judgment to know, okay, we're past the line point of diminishing returns and let's get back to the agenda because we've got a lot to get through or no, this is really valuable. Even if it means we have to come back to some other stuff in the next meeting. This is really important conversation and let it flow a little bit. Even if it breaks the sort of operating model the meeting. I think that's just leadership skillset to know when to guide the that in other direction.

And I like this sort of memo style where you talk about the rationale, the problem, potential solutions, the metrics and the learnings. And that's something you guys talk about on a weekly cadence.

And in bigger meetings we definitely don't really make it a. You write things down and then you present it. What we do is we have everyone spend a few minutes in the beginning reading it, commenting and we only really go through the comments and we assume that if you don't have a comment or a question that it's not. You don't need to discuss it because you already read the context that was there. So that inefficiency gain, especially in a world with zoom, it's just. It creates a democratization of everyone in the conversation that's really powerful for an organization. You know what?

I really like this. You enforce people to read the Google Docker document and comment before the meeting and you spend maybe a minute or two summarizing and then you just go through the comments. I think it forces everyone to do homework. I think I'm going to institute that right away.

Now we do give reading time in the beginning of meeting and when, you know, when people join Mongo, it's a little weird because they're like why are we silent in the first 10 minutes of this meeting or whatnot. And it's like, no, we're reading and commenting and sometimes we ask that people come prepared ahead of time and actually read everything before. But generally speaking, we allow for that reading time because what we find is people are busy, they are in meetings day to day doing their day job. And so if you don't give that time, the side effect is you're eating into people's off hours and personal time. And we've decided that we're willing to have these, these awkward first few minutes of each meeting, allowing people to read through, consume, add comments, but that ends up having a much better sort of outcome in terms of the meeting itself, but also allows people to not feel like if they're behind on documents, they need to be always reading every Sunday to catch up on everything. They can kind of fit it in the normal cadence of their week.

That is great advice. I've been an institute that make people read for the first five minutes or so of the meeting, five, ten minutes, and then and go from there. Awesome. So a lot of this starts from the product, in which case starts also from the customer. What is your product development framework at MongoDB like? How did you, what does that look like? What is the whole framework? How did you, how do you prioritize ideas, validate it, get it into production, push it out? Walk us through that. There's a lot to unpack there too.

Yeah, I think. And this is again like a process that's evolved as the company has scaled and the product organization, our product portfolio and the different needs of different products has evolved over time. So at a top level, what we do is we have each product area which is a product manager, their leadership, the leads own basically a product strategy, a document that outlines the business goals for each product. Like what are we trying to accomplish for the customer, for the company in the business lens. And these are typically three to five things. And it could be build capabilities for the most regulated and security conscious enterprise. That could be an example of a business goal. Or drive conversion of learners and early users of our product at a higher level or higher conversion rate than we are right now. Like really business oriented goals that are custom to each product area and that varies. There are different things for our core database product than there are for some of our newer products that are earlier stage in their maturity and evolution. And that allows us to do two things. You define the top line business goals of what we're trying to accomplish. You break that down into a set of tactical goals. Like what are the actual sort of tactical things we're going to do from an engineering and product standpoint to try to address that. And that's ultimately owned by the product manager or product managers for a given area. And then it allows myself, our cto, others to basically weigh in on like how much investment do we want to put towards one goal versus another. And it's like a very high level kind of portfolio investment view to say, hey, we really feel like we got to put 50% of our effort in business goal three this next year. And that gives guidelines to the engineering leadership and the product leadership on which areas are most important. So as they build the granular backlogs and requirements and plans of individual products projects, they have something at a very high level, at a business level to align it to. And then of course those business goals ladder up to ultimately MongoDB company goals at the top of, you know, top of the organization that we set and review and a couple times a year. And so that that framework of having business goals by product line is an overarching part of our development process. And then product managers then own initiatives which are basically again a 2 to 5 to 10 page brief on big projects. This is all this is for long running projects that may span multiple quarters or in some cases multiple years. This is like large investments. For the average capability we're building, though you may not have an initiative, it may be something we can get done in a quarter that goes right to a lightweight product description which is almost like in customer terms, almost like blog format. What is it? What we want to deliver and announce as long with obviously more detailed product requirements. And then that ultimately gets handed over to engineering and product work that is scope, that's more engineering led and then that drives ultimately delivery of that capability. And it's a set of documents ultimately where some of which the product manager is the key owner, others that design and engineering are key contributors too early in the process. And then others that are more engineering driven where the product manager is answering comments and questions, where there needs to be more clarity about a requirement or we want some customer input on something so that's got a high level how our process works. But then the cadence of delivery changes based on the team and the product. Some of our products are shipping all the time on a almost a weekly basis, others are shipping quarterly. If it's more of like a couple kind of backend server oriented technology, but fundamentally it follows that same project, that same process and we hold the product management team accountable for the input of those Projects with supporting data and customer examples and all of that that they're sourcing from our customer or feature request portal, which is a public thing, inputs from our support organization or field organization. And of course just the intuition and judgment they build over time knowing their customer base and product that they operate.

What are some best practices when you're designing or developing go to market strategy for a product led company?

I think I touched upon earlier the idea, the mindset, culture and processes, the technology around experimentation. I think that is foundational and MongoDB had to learn that and build that as we started becoming a SaaS company. But I think somewhere there might have been a question around advice around that I would start early on that. And so investing in deep instrumentation, building the right kind of program management around how to run experiments and analyze experiments. Now funding an analyst team and a data science team that is side by side with the product managers and the engineering leaders on the success of the product I think are investments that sometimes early in a company's trajectory are hard to justify, but I would advise are crucial investments to really focus on if you want to drive a product led strategy because you want to know which activities ultimately correlate to the most the best success in terms of revenue and lifetime value of a customer. That is very data driven, data heavy experimentation, heavy sort of process. So I think that's one best practice. The other this is more generalized to product management. I think it's really hard to have product managers who are on one hand very close to the customer, know the market, know the competition, have great instincts, can engage with engineers and engage with sellers and anything across the spectrum and also ask them to be great program or project manager. And oftentimes I see companies underfund program and project management which is its own amazing function in terms of what it can provide in terms of efficiency and scale and rigor to an organization and just put it all on the product manager or the pro or the product marketer in some cases to manage the execution and rigor of the process of building and launching products. And I'm not saying your product manager is off the hook. I'm not saying like you don't want strong organizational skills and product managers. I'm not saying any of that. But I think if you want a successful product organization to represent your customer and be deeply knowledgeable, it's hard to have the skills and time in the day to do that and also be managing the process execution across engineering design, product marketing. So what we've been this was here when I Joined Mongo years ago. We've just scaled and evolved. It is we've got a really strong program management function that helps product design engineering operate in a fluid way so that the product managers can spend more of their time figuring out the right things for the company to be building in the right markets and technology to go after.

Yeah, holding the schedule. I think it's very important making sure and then what is the split like? Does one program manager manage across multiple squads or is it the squads is.

More on the go to market side? In engineering we've got engineering leads that manage different parts of the product and they have an associate of product manager and then leadership structure above that. Basically we tend to map program managers to and technical program managers to the domains themselves. So they that might be at a product level. If it's a relatively nascent new product or on our larger products like the core server or Atlas which are teams of dozens and dozens of people, we'll have multiple program managers map to them. But we do try to create alignment. So you have again that working relationship, the domain knowledge across, you know, a cross functional team. It sounds a lot like a squad but. But a program manager, a product manager, a designer, an analyst, an engineering lead or engineers themselves all in a structure, a pod, a squad that that ultimately own execution. We don't technically call that a squad on the product engineering side but effectively at a meta level it's the same thing.

Do you have product marketing and if so what is their role compared to product managers in respect to strategy and GTM?

At MongoDB we do have product and product marketing integrated into my organization. The and this line is a little bit fluid based on different companies I've been at. But in terms of how we look at it, product management is ultimately responsible for the product strategy, the direction of the roadmap and the pricing and packaging of the product and making sure it gets built and written out correctly. Product marketing is all about making sure that one they're bringing feedback from the market and customer base into product management. Not that that's a one way serial process. Product managers in front of customers too. But that product marketing has a seat at the table on the strategy and making sure we're serving the right customers. And then so much of a successive product is how well you can connect the value of that product to the end user or the end buyer. And so the core positioning, how we message that, how we create the materials that enable our sellers to be able to communicate the value and the why of what we're Building effectively that is ultimately owned by product marketing and is an immensely important thing. I've seen so many products that are good technologies but ineffectively positioned to the wrong segment of the market or just talking about technical features instead of talking about the why of the value that brings to an end customer. And great product marketers can basically connect that and then enable and get leverage out of the market, broader marketing organization or the sales organization by nailing and iterating on that effective message. And that's really what we want them spending their time on. But they work as a team, 100% work as a team. And we try to create a pairing relationship as much as we can between product managers and product marketers and designers as well in that sort of integration.

Was a decision already made to go down this route of atlas when you joined or how did that come about? How do you manage stakeholders where you got a CRO, probably selling top down elephant whale hunting and now going through this bottom up model where try and let users use it.

Decision to build a SaaS version of MongoDB was definitely made before I joined because I was recruited to kind of lead that for the company. And that was the part that was attractive to me. It was like, all right, the ability to help drive a transformation of the company. I already had strong conviction mongodb is everywhere. But I certainly believe that open source technology in general, the right business model is over time at scale as a SaaS business model. And not, it's not for us, it's not an either or, we do both. But I think that was clearly going to be the future of the company if we pulled it off. And so that's was the reason I think the company saw that, the board saw that and made the decision to go in that direction. Now what that actually meant in terms of the go to market strategy, this product strategy, at that time we didn't know ahead of time, we just knew that this, if we pulled it off could be transformational for the company and we knew that we had massive tailwinds behind us that could help that. But yeah, I think in the early stages definitely there was the normal anxiety of oh wow, if you can buy this on a credit card, then what is the how does the seller engage? Or those types of questions. But by and large I think by showing that a really strong bottoms up product led acquisition model is not at odds with sales, but an amplification of what we can do with sales more effectively at scale you win the hearts and mind and at the same time there are Accounts that we would never have using our cloud product if we just waited on a bottoms up product led marketing driven acquisition model. We have amazing enterprise customers because we've had a really amazing strategic rep be able to break in and wins the hearts and minds and land that first opportunity. So I think the market tends to categorize companies in these two areas because I think that's what we've seen historically. You've seen traditional, outbound, sophisticated enterprise selling and then you've seen the new age bottoms up great PLG companies, some of which you mentioned earlier. When I talk to those companies and they say they have enterprise sales, it's not what I think of as sophisticated enterprise selling. And I think that what we're hoping to do at Mongo is not make that in. It's not developer versus Enterprise, it's not PLG versus enterprise or sales led. I think that's a false juxtaposition. I think especially in a market like ours, when we're in a 70 billion dollar market going to $100 billion, companies are at all different levels of maturity buy in all different ways across that specific spectrum. So the real question is how do you figure out which customer is right to engage with which model at the right time along their journey. And I think we've done a good job figuring out a cohesion between PLG and sales led so that we can acquire companies at scale through a PLG motion. Drive efficiency for certain customers just doesn't make sense to have human touch but then use data and signals and ideal customer profiles to identify those those and move them quickly over to getting in front of a csm, getting in front of a seller that isn't even worried about a deal, that is just worried about customer success and growth. And then guess what, a customer is going to end up on a contract when they're ready and that they're at the right scale anyways. So it's a win win for the entire organization in terms of the economics and scale of the go to market. But that took us time, it took us building the right incentive models. So things weren't. We didn't have channel conflict. It had took some really great sellers experimenting on how to upsell the customers from self service effectively. It took us a lot of iteration around that idea of iteration within go to market to get that. But once it starts working now our sales organization cares as much about the success of what we're doing in self service as what they're doing in a more outbound motion because they recognize it's the early part of the customer journey for many of the company customers that will be large multimillion dollar sales customers someday.

And then when you launched Atlas, what were the key drivers of gtm? What was initially driving that flywheel? Because you need like a base or maybe you guys were maintaining it as you were doing the sales model and then funneling them to this. Like how did you drive that initial?

How do we drive?

See the seed, the flywheel basically.

Sure for us there was a little bit of context. One clearly we were already a successful enterprise software style direct enterprise sales business and we were, I don't know, 18 months or something prior to IPO at that point. So the idea of screwing up something that was working was definitely on our mind. Especially because you've got a very margin rich enterprise software product like any software is and you're potentially worried that those customers would move to a SaaS product that is unproven, that has way lower margins back then and certainly we're happy with where we are now, but this is all like that seemed risky. So there was a little bit of of and also frankly the product in the market. The idea of cloud databases being de facto in banking for example was like a pipe dream five years ago and now we're seeing that in many places. And so we felt okay, we knew it would be an enterprise product, the cloud product Atlas, but we didn't want to screw up something that was working in a market that we felt was still early days. And so we spent the early year or two really trying to nail what we think of as the product LED motion. So how do we get get developers to sign up, use the free tier, convert them into engage customers, get them into a paying usage over time and then how do we then also feed a sort of sales assisted model in particular at the mid market and SMB with our inside sales team identifying the right customers and upselling them or converting in our case open source users of MongoDB into our SaaS service. Because who would want to operate a database if you don't have to? Let us let the experts do it. And so the first motion was really get that self service engine built because that was a new thing for the company and then figure out the intersection of how that feeds in particular inside sales. That was those were the first two priorities and still are priorities today just to be clear. But over time what we saw is as the market matured, our enterprise team started figuring out how to sell SAS motion that became a higher and higher percentage of our total cloud ARR. And so now if you look at the Atlas business, it's the majority of our company's revenue and it's a nice healthy balance between customers that are pure self service, those that have some level of sales assistance that may not even be on a contract and then others that are, you know, multi hundreds of thousands or millions of dollars traditional kind of sales led customers and that diversity there in our base. But it took us time to build up towards that. And with sales it was a lot of the best sellers learning what best practices look like, us taking that back and scaling that to the rest of your tuning compensation models. As we learned where there were points of friction and really looking at the go to market organization is as much part of the invention of how we take this custom product to market versus something that we just throw over the wall and then they go sell. It was very collaborative and that's what ultimately got the buy in over time. But there are things we're still experimenting and tuning and evolving today. Like I said earlier, I feel like this whole model of omnichannel distribution for a SaaS company is really, there's a lot of invention still happening. I think we've seen what good looks like in a sales LED model. We've seen what good looks like in a bottoms up PLG model. I don't really know that we've seen what great looks like in a top to bottom model that integrates all those things in a fluid way.

Yeah, I think the future is always omnichannel and it's multiple touch points. You can't treat, you have to segment your customers. You can't treat your larger customers with the same way you treat your self service and vice versa. You've done a fantastic job here because you got two models firing. I think you guys is market cap has gone tenfold from the IPO already since then.

We've been fortunate to have success, but we are just getting started. We're a small player in a giant market. We're trying to build go to market engine and a product portfolio that really can sustain us for decades to come.

You guys acquired a company called M Lab way back when. Did that have any impact on kickstarting some growth or adding some growth or seeding the customer base for Atlas in those days.

It definitely has helped us by integrating in a long tail of really just touchless self service customers. MLAB done a great job building a business that had really no what we think of as traditional sellers. It was all self service, great support, even some very large customers in that model and so we definitely respected what they did there and we ultimately decided why compete with each other when we all sort of love MongoDB and see the opportunity for MongoDB in the database market as a, as our unifying force. So definitely that helped. And the idea that we were in many ways getting the all the developer community of Mongo onto really a first party product with Atlas and the teams together working on that was definitely a win. And we are very proud that the entire MLAB team is with us today working on either Atlas or other parts of the product portfolio or other parts of the organization. It's been an amazing culture add to the company as well.

How do you guys prioritize?

Thankfully there's a fair amount of overlap between the A team starting up in a startup company in the Bay Area and some very highly regulated enterprise that's more top down sold, maybe in, I don't know, Germany or something. There is a lot of overlap in product requirements so that's helpful. But absolutely it comes down to looking at the revenue opportunity, recognizing that we know which segments of the market have how much revenue database space and we know that if we can't do one or the other and it's a constant balancing act and that business goal alignment of how much investment to put in different areas helps us clarify in any given quarter, wherever we're seeing success or where we think we have to invest more, it gives us a guide to say, you know what, we're going to have to invest more in enterprise security capabilities for the next two quarters because we're seeing some new requirements come up because of the privacy regulations worldwide in the enterprise that happens and so we'll tune things up to build out some capability there. On the flip side, we might want to integrate with some flashy new frameworks that are really popular at the bleeding edge of the developer community but haven't really made it into the enterprise. And we know that's a really important long term investment for us that's just product management. What's making the trade off and judgment call of how to balance those and phase those in a way serves the entirety of the market.

Building this awesome Flywheel self serve Atlas and taking it to 23 billion market cap. What are your top two or three pieces of advice that you've learned the hard way?

Maybe, yeah, I think one of the important things I believe especially as a company scales Mongo is a moderate sized company now, but I think it's as important at a small company or even much larger Company is building processes and a culture that encourages cross functional communication and collaboration. That to me is fundamental. It's really easy to get stuck into talking to just your team or your leadership up the chain. In a hierarchy of any organization. It's a lot harder to feel comfortable going across lines. But I think that's what makes the best companies great. Product managers in many ways are routers in an organization. They're communicating things across different functions of an organization to deliver a successful outcome. Engineering to finance, to support to sales. That horizontal communication and learning how to be good at that is number one. I think secondly, this is no surprise to any product folks on the call. Learning how to work through influence is crucial. It doesn't matter if you're a product, just it's a requirement for product management, but it's an asset in the skill. In any function you have. It's very rare that you're going to have full on positional authority to make every change you want happen within an organization. So how do you effectively sell your point of view and vision with data, with convincing arguments, with well written arguments around that is a crucial skill if you want to ultimately drive success. And Atlas is exactly that transformation. The company was a lot of hard work and teaching to fish and showing successes and socializing those successes cross functionally. So I think those are the two things. It's the idea of fostering and promoting people who work well but through influence. Influence and very relatedly are glues between organizations and can go fluidly across functions of a company.

What are some books you recommend? What are some resources you recommend to others to stay on top of the game or something that's benefited you?

By no means is a surprising answer. I think there are a lot of people that love this book. But the Hard Thing about Hard Things by Ben Horowitz is great because I think it says a lot about grit and I think resilience and grit are are probably more important than just having the right skills or intelligence. So there's a lot of that in that book but many other books around that too. But I think that idea is well encapsulated in a lot of the stories and pretty colorful way. The other area I would say is I don't do a lot of these days much deep technical research or reading as a function. But I do look at just tech industry trends and technology trends. Whether it's listening to Kara Swisher and Scott Galloway's podcast or, or reading the information what's happening in the industry. I think just whatever layer of the org you are whatever the pertinent information is. I'm not saying those are the publications or podcasts. It all varies based on your role. I think just being a curious person about whatever you're working on is crucial, and it's an obvious statement. But it's amazing how many people aren't really naturally curious about the work outside of the hours they spend at work. And I do think that sometimes makes some of the best performers in your organization. When you just have a passion and curiosity to go read something about your some paper, an academic paper, read a blog, whatever about your, that isn't necessarily just your job, but it's something related to it that you can pull from.

I took a lot of notes. I never do, but I took a lot of notes. I'm going to share with our team. Thanks for joining us Ayer, and wishing you great success.

You need some traction.

Thank you for listening and we hope you enjoyed this week's episode of the Traction podcast. If you enjoyed the show, please please leave us a five star review and you can find more information and all the resources mentioned in today's episode at. Boast AI that's B o a S T AI blog.