Product Management at MongoDB - Meet Rezwan Khan

When I joined MongoDB last year, my dad called me and in typical dad fashion, jumped straight to the point:

Dad: “So, my friend was asking me the other day, what you did at your job and I couldn’t really explain. What is it that you do again?”
Me: “You mean where I work?”
Dad: “Oh, I know where you work. Software right?”
Me: “Yes, broadly speaking...”
Dad: “Ok, but what do you do there? You are a programmer right?”
Me: “Not really...”
Dad: “But, you talk about things you are building all the time.”
Me: “Yes, I do build things.”
Dad: “Okay, so you are a software programmer.”
Me: “I mean, I work with programmers who build things, but I am...”
Dad: “And you build databases right?”
Me: “Yes...”
Dad: “Great. So you are a programmer who builds databases. Sounds smart. Very proud of you. Okay bye. And oh, call your mother!”

[phone disconnects]

Well, the conversation went as well as expected. I can see him excitedly calling his friend back and explain to him my database building skills. My dad was broadly right. I am a “product manager” and my job is to technically build things. But, then you add a huge asterisk to it. I think the image which most people conjure up when they think about product managers is someone who is “telling engineers what to work on.”

The reality of being a Product Manager can be more accurately described as, “help your team (and by extension, your company)** make the best decision possible**, while not ruining anyone’s life.”

Sounds fun? It is and in my completely unbiased opinion, it is one of the most interesting jobs in technology today.

So, what do I really do, day-to-day?

I am the Product Manager (PM) for the Insights and Telemetry team. My team’s mandate is to collect data on the performance of MongoDB, as a software, and use it to automate many tasks that users are doing manually today. The end-goal is to make the experience of using MongoDB as easy as possible.

If you have used a database before, especially at very high scale, we use the performance data we collect, for example, to ensure that the database is tuned to minimize query latency, while keeping the costs of running the database as low as possible.

Within the team, my job is to help my team make four decisions:

1. What are the customer problems which we should solve?
2. How should we solve those customer problems?
3. How do we make sure customers use our solution?
4. How should we do all of the above in the most ‘resource-efficient’ way possible?

All these decisions ultimately lead to the right products being built for the company. It is important to know that these are joint decisions that we are expected to make together as a team, at least most of the time. Sometimes, you can’t really do that but that is a topic for another time.

So, now that you know a little bit about what our objectives are, let’s talk through how Product Managers actually help make those decisions.

Decision 1: What should the customer problem be?

Normally, there is no shortage of customer problems that we need to solve. These problems come via a variety of channels at MongoDB - our customers, employees throughout the company, insights from research studies you or members of your team do, our executives, and more. The real work is analyzing all this information and figuring out what problems are actually worth solving and when. To do this well, the PM needs to understand the customer and their pain deeply.

In the trade, we call this whole process “prioritization.” Encyclopedia of books have been written about the topic. There are layers of sophistication involved from trying to estimate market size, to balancing long-term strategic objectives with solving short-term pains, but the simple goal at the end of the day is to solve the biggest problems that our users have and hopefully pay us a lot of money to solve for them.

The product manager’s job is to have a point of view on what the prioritized list of customer problems that need to be solved are, ideally backed by data; then drive a discussion around it and ultimately gain consensus needed for us to go solve it.

Decision 2 - How should we solve those customer problems

Okay, now everyone is onboard in solving the problems. Now, comes the interesting part of deciding how to solve it. A bunch of interesting questions come up, chiefly:

1. Of the various ways to solve a given problem, what should we pick?
2. How well do we need to solve it?
3. How would it look to our users?

At this stage, the product manager facilitates brainstorming sessions with the team, which may include engineers, designers, marketing, researchers - essentially anyone whose input would be valuable in building the right solution for our customers. The PM might have a sense of what the best solution would be, but it’s not a necessity, since better ideas might come from the team. The PM’s function is to vet each idea against their understanding of a customer’s pain.

Hopefully, you will discover a brilliant way of solving the problem that everyone will agree on! Then you can go and build it!

An interesting example which highlights how we figure out how to solve customer problems, came about when we were building a product which automatically scales the MongoDB database up or down, based on how much server capacity you might need in the future. This is actually a very hard problem on its own, since effectively we are trying to forecast how much an application built on top of MongoDB would be used in the future. But even before building the forecasting model, we realized that running the forecast all the time is very expensive. So, we had to build a way to forecast when we needed to forecast.

Decision 3: How do we make sure customers use our solution?

Once the solution is being built by the engineering team, the PM needs to start thinking about how we tell the world about your awesome creation, so that people actually use it and hopefully pay for it. We call this “commercialization” and it includes activities such as coming up with a plan to market the product (ex: should we buy ads for it? What do we talk about in the ads, etc?) and drive users to engage with it. The actual execution of many of the discrete tasks in the commercialization process may be done by other members of the team, but it is the PM’s job to make sure we are “doing the right thing”.

Decision 4: How should we do all of the above in the most ‘resource-efficient’ way possible?

Ultimately, you as the PM, and by extension the company, have limited resources to solve all the problems you want to solve for your users. The best company and the best teams are really good at maximizing impact with the limited resources you have. As a PM, this means a couple of things - you need to be hyper aware of solving a problem in the most efficient way possible (spoiler: it’s harder than it seems) and you are minimizing every barrier that makes your team less efficient. The former implies that you need to be very synced with the engineering team as they are building the product, to ensure that you are not unintentionally adding complexity, when none is needed and the latter implies that you need to spend some amount of time figuring out processes and systems that can help make your team more efficient, so that decision making is accelerated. Again, you don’t necessarily need to do all of this and a well functioning team should strive to become more efficient on its own, but as the PM, you need to keep your eye on the ball.

Hopefully, I have given you a “fifty-thousand foot” view of what the life of a PM at MongoDB looks like. Interested in learning more? Drop us a line or feel free to follow me at @rezwankh on Twitter. I hardly post anything, but I aspire to someday!