From Software Developer to Product Manager: Meet Maria van Keulen

Maria joined MongoDB a bit over five years ago and recently transitioned from Software Engineering to Product Management. I had the opportunity to learn about what Maria’s transition was like and how her experiences as a Senior Software Engineer have helped her succeed as a Product Manager.

Maria was featured in a previous blog post that gives insight into her first three years at MongoDB and her experience as a woman in tech. Check it out here!

Hannah Friedfeld: Hi, Maria! Thanks for sharing your story with me. You’ve been at MongoDB for five years now; what encouraged you to transition to a Product Manager role?

Maria van Keulen: A couple pieces of context are necessary here. A couple years ago, I gave a presentation to my team, Storage Execution, to walk through the components of our code base. At the time, I was mentoring a new engineer rotating on our team, and I volunteered to give this presentation to provide some more holistic context on the work that we do and the tickets this engineer was working on. This was the first time I had given a presentation like this in my professional journey at MongoDB, and I greatly enjoyed the task of taking complex topics and distilling them into a story. Shortly after, my manager informed me that we would be hiring for a dedicated Product Manager role; he encouraged me to apply if I was interested, particularly given my demonstrated knack for communicating complex topics to a wide audience.

Although I enjoyed my Software Engineer role, I was interested in pushing my boundaries and undertaking a new challenge, especially given my positive experience preparing the presentation. The more I learned about Product Management, whether from colleagues or from literature, the more excited I was about making the shift. In the words of Marty Cagan in his book Inspired, "...behind every great product, there is someone—usually someone behind the scenes, working tirelessly—who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business". The crux of Product Management, in my view, is taking in various sources of data and using them to tell a powerful story. Great teams will design and build cool products no matter what, but when inspired by stories, they build solutions.

In the end, I decided to apply for the open Product Management position on my team. Although the position ended up going to another candidate, I had the opportunity to instead join as the first Product Manager in our company's Developer Productivity organization. I would be working with the Evergreen team, who develops our internal CI/CD system. In order to ensure that the role was a good fit, I'd have a three month trial period where I'd continue to report to my Software Engineering manager, but focus exclusively on Product Management. I was ecstatic at this opportunity - I'd be working on a product that I knew and loved from my prior experience, be able to work with a team of talented engineers and product designers, and begin to build out Product Management representation in a new area for the company. Now, having been with the team for one and a half years, I'm so grateful to have made this shift, and am looking forward to continuing to shape the future of Product Management on Developer Productivity.

HF: How did your experience as a Software Engineer prepare you for your new role as a Product Manager?

MVK: I feel very fortunate to have begun my Product Management career with the Evergreen CI/CD system, since Evergreen had been one of my most-used products in my previous role. As a Software Engineer, I would run and analyze tests on Evergreen multiple times a day in order to ensure robustness of my code changes. With this experience under my belt, I was able to make an impact on the Evergreen team soon after I joined. At the time, we were in the midst of releasing two critical projects. The first was a full redesign and implementation of a portion of Evergreen's web UI, in collaboration with our Product Design team. The other project was to create a pre-built virtual development environment for engineers to use to help accelerate onboarding by simplifying workflow setup. Given my prior experience as a developer of the MongoDB database, I was able to offer unique insights on this developer workflow and help do some final QA testing before we released the projects more widely.

More generally, my experience as a Software Engineer has been helpful in my ability to liaise between my team and our end users, relaying both user feedback as well as proposed solutions to their feedback. In order to offer guidance in a project, not only during definition but also during execution, I need to be able to understand where a solution is going in order to make sure it's in line with our original goals. In a similar vein, when it's time to advertise completion of a project, I need to be able to synthesize our end-to-end story based on the problems we set out to solve, and the way we tackled those problems.

Finally, one of the aspects of the role that I'm most grateful for, and is unique to internal-facing Product Management, is our proximity to our users. Even with my experience as a developer, I knew that I had only scratched the surface of what Evergreen the product could do, and the kinds of workflows that exist across the company. Thanks to my experience as a Software Engineer and my collaboration with engineers across the organization, I had a great starting point for users to connect with. In my first few months, I was able to enrich my perspective by learning from these users (and others whom I hadn't met previously) to build a more holistic understanding of the product and its user base.

HF: What new skills have you gained as a Product Manager?

MVK: Product Management has given me a new appreciation for the art of learning to manage my tasks. As a Software Engineer, I'd have a fairly structured workflow where I'd generally have a small number of large tasks I could focus most, if not all, of my energy on, and switch between them if any of them were blocked on something. As a Product Manager though, my task list has ballooned, and the tasks are of various different complexities, ranging from answering a quick question to giving a presentation. Additionally, I need to consider time spent in meetings when planning my day, and any context switching between those meetings and my other tasks. One takeaway that's come in very handy is something I learned from the book The Personal MBA by Josh Kaufman. Kaufman uses a "3-10-20 method" to describe task bandwidth in a given day: in this time frame, he has the capacity to do three major tasks, and ten minor tasks, where a major task is one which requires more than twenty minutes of continuous concentration. He combines this with Paul Graham's "Maker's Schedule vs. Manager Schedule", where the Maker's schedule involves large chunks of time for continuous concentration, and the Manager's schedule involves small chunks for meetings. Nowadays, I strive to keep all of my meetings in contiguous blocks where possible, and answer emails/messages at specific intervals to minimize interruptions.

Product Managers are constant learners - in order to make sure our stories are up to date, we need to keep a regular pulse on everything that's going on with our products. One invaluable skill to building an understanding of one's users as well as one's team is knowing the right questions to ask. I'm grateful to have had the opportunity to speak with many users in my experience, and I've come to learn what questions bring the most insight. It's something of an art to be able to craft a question that's sufficiently open-ended to get people talking, but specific enough that they have somewhere to start with. Asking the right questions is also invaluable for more quantitative forums, for example surveys and software analytics. I'm happy to say I have been able to hone these skills - and will continue to do so - while on the job.

HF: Why should a Software Engineer consider a role in Product Management at MongoDB?

MVK: Software Engineering and Product Management are both enjoyable disciplines for their own reasons. The dichotomy that was explained to me, and that I now explain to others, is that Product Managers focus on problems, and Engineers focus on solutions. Of course, this boundary is not clear cut, and there is some overlap, but it serves as a basic guide for what each role will spend the bulk of their time doing. In general, Product Managers are responsible for gathering quantitative and qualitative data from users, assessing costs and benefits, and making a case for what we should and shouldn't build. As a result, Product Managers end up building a large breadth of data points across different areas of their products and their business. Engineers, in contrast, take project specifications and build robust, elegant, and innovative solutions to the problems at hand. They'll build a much deeper understanding of the functionality, and be resident experts on each feature they're involved with.

If you're interested in getting involved with other areas of the business, and helping guide the strategic direction of a product, Product Management is the discipline for you. Additionally, since Product Management provides a window into various other disciplines across the business, it gives a great jumping point into any of those other areas.

HF: How were you supported in your transition to Product Manager?

MVK: As I mentioned previously, I was fortunate to begin Product Management for a product that I had already had ample experience with. The larger transitions had to do with acclimating myself to the new discipline and learning what working styles were most effective for that discipline.

Fortunately, I had (and continue to have) the support of MongoDB's Product Organization, composed of individuals ready to offer advice and perspectives from their own various experiences. Whether it was understanding strategy for conducting research projects, brainstorming ideas for task management software, or building success metrics for a product, I could always count on the Product team to offer honest and open opinions. In particular, I'd like to thank my colleague Rachelle, for offering to mentor me over the course of my first year in Product Management, as well as my manager Chirag. Their input has been invaluable. I'm also very grateful to my former colleague Oz, who I got to know at MongoDB and now works as a VP of Product at a rapidly growing technology start-up, for giving me my initial window into Product Management, and pointing me to great resources to learn more about the discipline.

Another valuable piece of my onboarding to Product Management was the opportunity to get hands-on in product research early on. I'm grateful to the Evergreen team's director, Brian, and the Developer Productivity team's VP, Cris, for all of their guidance and feedback on my research and contributions. Further, I appreciate all of the input that the Evergreen team as a whole has provided, including engineering context for feature complexity and additional considerations I hadn't anticipated.

Finally, I'm grateful to Ben and Lara from the Product Design team for allowing me to sit in on their research for redesigning elements of the Evergreen workflow starting early on in my role, and sharing with me all of the user context they had obtained thus far. These were great learning materials for me to review as I onboarded myself to Evergreen's user base.

HF: Tell me about your current team and its culture.

MVK: I'm currently working with two teams under the Developer Productivity organization: the first is Evergreen, and the second is our Performance Solutions team TIPS (Tooling and Infrastructure for Performance Solutions). I am very grateful for the opportunity to work with both of these teams, as well as the Developer Productivity organization at large.

Developer Productivity is in a unique position at the company, in that it is a team whose customers are also its peers. As a result, we are in many ways a small startup within the company. Rather than having dedicated contacts in Sales, Marketing, Technical Support, and so on, we end up providing similar services ourselves in-house. Although we're not making an official sale with our users, we do need to market and "sell" our products and features to users who may initially be skeptical or hadn't previously heard of the features. It's also up to us to take a pulse on our market, conduct user research, and do competitive analysis where appropriate. Additionally, if a service is down or our users are blocked, the team provides technical support and troubleshooting assistance. Finally, part of the "small startup" culture includes getting hands-on and helping out in areas outside of one's immediate to-do list, whenever an extra hand is needed. It's a great inspiration to be part of such a driven and multifaceted organization.

I started working with Evergreen last year in the midst of the COVID-19 pandemic, when offices were largely closed. Having previously worked mostly in the office, I relied heavily on happenstance encounters and lunch breaks with fellow coworkers to make connections. The fully remote setting, combined with the uncertain times of the pandemic, posed new challenges to fostering relationships. I'm very grateful to the Evergreen team for welcoming me into their circle, and for organizing various (virtual) happy hours and game nights to allow the team to bond.

Earlier this year, I agreed to help spread Product Management bandwidth across multiple areas in the Dev Prod organization in order to help build strategy in those areas. Around the same time, we formed TIPS, consolidating individuals from multiple teams working on various types of performance tooling into one group, in order to build a unified performance solution. We have a lot of powerful performance tools at our disposal, and a wide array of possibilities for where we can take them, so it's a very exciting time to be able to help shape the team's future.

The Developer Productivity organization is an amalgam of many individuals from many different disciplines, across Engineering, Program Management, Product Design, and now Product Management. It's been a great privilege to work with and learn from each of these individuals, and build exciting products together.

HF: What do you like most about your role as a Product Manager?

MVK: One unique aspect of my role on Developer Productivity that I greatly appreciate is the opportunity to help shape the future of Product Management on the team. I joined as Developer Productivity's first Product Manager, and in my first year I was able to bring back our monthly release notes newsletter, successfully experiment with a new means of feedback collection from our users, and share learnings from Product Management best practices not just to my immediate teams, but also to the organization at large. An exciting bit of news is that we recently hired our second Product Manager on Developer Productivity, who will help us continue to expand our product reach across the organization. This new Product Manager will ramp up to take over Evergreen product responsibilities as I transition more of my bandwidth to TIPS.

HF: What advice would you give to a Software Engineer who is interested in transitioning to a Product Manager role?

MVK: I recommend reading up on the role and talking to current Product Managers to better understand the shift and the responsibilities that go with it. The following resources were recommended to me by fellow Product Managers and have been particularly illustrative:

• The Art of Innovation by Tom Kelley and Jonathan Littman

• Inspired by Marty Cagan (mentioned earlier)

• The Mind the Product blog

Talking to Product Managers in your own company is a great starting point as well, and they'll be able to provide transparency on the different kinds of documents and processes they encounter day-to-day.

I'd also suggest asking if it'd be possible to have a trial period as a Product Manager within your company - if so, that'd be a great opportunity to get hands-on product experience and make sure the role is a good fit.

References

Cagan, Marty. “Behind Every Great Product.” Inspired: How the Best Companies Create Technology-Powered Products and Services, Wiley, Hoboken, NJ, 2018, pp. 5.

Kaufman, Josh. “Cognitive Switching Penalty.” The Personal MBA: Master the Art of Business, Portfolio/Penguin, 2019, pp. 266–267.