JJ Rorie
- 1 min read

Becoming a Data / ML Product Manager with a Non-Technical Background

Episode 018: Raj Muhar

" ...this {myth} disproportionately affects marginalized groups, especially women of color, when they're applying for these roles. We've seen studies that say men are qualified for 30% of the roles, yet apply quite boldly versus women need to feel like they're qualified for 100% of the role before applying. So I think this is a really important conversation to have. And hopefully by sharing my journey, we can debunk some of these myths. "

Episode Transcript

JJ: Hello and welcome to Product Voices. Today's topic is one that's near and dear to me because when I first started in product management, I struggled quite a long time because I didn't have a technical background and I wasn't struggling because I lacked that technical knowledge. I actually was struggling because of a lack of confidence. I believed that I had to have that technical background and that engineering or science knowledge to be successful in product management. And I was intimidated by my partners who were technical experts. And the truth is, I didn't need that deep technical acumen, not the way that my engineering and development partners needed it. I simply needed to know how my value was understanding the customer, understanding the business, and bringing that to the table. It took me a while to really mature and learn that I didn't have to be a technical expert in order to be successful in product management.

And so today's conversation is with someone who's really flourished in data and machine learning product management, even without having that technical background. So I'm really excited about this conversation. Raj Muhar is Director of Product at Innovid, an ad tech analytics platform at the center of disruption of the streaming TV industry. She was the founding product manager of the measurement and analytics team there. She's passionate about using technology and data to unlock personalized experiences for consumers at scale. She's also dedicated to creating inclusive environments fueled by diverse voices, and she mentors young women of color interested in Stem fields. Raj, thank you for joining me today.

RAJ: Thank you for having me. I'm extremely excited to talk about this topic today.

JJ: Yeah, I think it's really important because again, I think there's this misunderstanding that, you know, engineering and development and technology background is going to make you a better product manager, but that's not always the case. So I'm looking forward to this.

So tell me more about you and how you became a product manager in Data and ML without that technical background.

RAJ: I resonate with everything you say because I have had a similar experience. And I'm here to say that I am proof that you do not need a computer science degree or have experience as a full time engineer to become a PM, including a data science and machine learning product manager. And the reason why I just want to say that at the outset, I think, is because this disproportionately affects marginalized groups, especially women of color, when they're applying for these roles. We've seen studies that say men are qualified for 30% of the roles, yet apply quite boldly versus women need to feel like they're qualified for 100% of the role before applying. And this especially on the technical aspect of being in product. So I think this is a really important conversation to have. And hopefully by sharing my journey, we can debunk some of these myths.

That being said, as for my own product journey, I worked in analytics in the content advertising measurement industry. And the way I got into product was by making an internal transition. So the analytics role, I was essentially on a team that incubated early stage offerings before they became officially productized. So as part of that role, I talked to customers and users, especially our leading edge ones, really dived into their needs, help them come up with different creative solutions for their problems based on their key KPIs. And because I was so familiar with their needs, the rapidly changing entertainment industry and the competitive landscape, and because it allows frequently in communication with the product team recommending a lot of suggestions and prioritizing incoming requests, based on my own framework and based on what I knew of the objectives of the company, the product strategy and our constraints. And so this happened so often that I eventually got an offer to join the digital content product team. And that's how I officially became a product manager.

And I say officially because when I was in school, I went to Berkeley in California. I took the first two product management classes that were offered, and they were under of the School of Engineering. And so way back then there weren't as many opportunities or well publicized opportunities if you didn't have an engineering background to go into these product roles. I remember at the time there are very few programs. I think Google's APM program was one of the few, and for those programs, they only recruited for the top CS candidates. And so the message was just kind of like, if you don't have that background, just kind of forget it. And figuring out what I love to do is completely in line with product management. And so as I mentioned, I was able to join an internal team. I was interested in technology and how we can use technology to solve problems.

So I had this love of learning and especially being at Berkeley Engineering and Technology, where we're very top of mind. So I imbibed so many resources. I took online and part time courses and did side projects and listen to podcasts and articles on everything technical from like web, mobile app development. I focused on specific languages like Python and SQL. And looking back, a lot of that was, yes, due to my hunger of learning, but also imposter syndrome. I thought I needed to be an engineer in order to work in the tech industry, even if I wasn't going after engineering roles. And so looking back, I did a lot of that when the reality is the most relevant technical skills for Product Manager that I ever learned was actually on the job. It was asking my engineering, data science and data architect teams on what is relevant. Like, what should I be learning? What is our tech stock, what is our architecture, what is the data flow? What are the things that are are actually important from a technical perspective that I need to know.

And I'll say there are two main things. One is just learning the lingo, the terms that you're able to communicate and collaborate efficiently. The other thing to understand is what are the technical implications of different decisions and what are the trade offs that will be required. Those are the two main things, I think, that are really important in terms of technical skills as a PM.

JJ: Yeah. It's really interesting. I love everything you said and shared a couple of things I want to kind of dig into a little bit. The last thing that you just said, I think that's really important things. About a technical perspective that are important. Number one is just the lingo and the language and semantics. And you don't have to get deep, but you do have to have just a little bit of understanding and speak the same language, if you will, or use the same lingo, at least generally high level. I agree with that. I think that's really important. And frankly, it's something that you may just have to learn as you're getting in there. I like how you said there are some things like the tech stack, for example, that may be of value for you understanding, but it's really in my experience, it's because it can have an impact on the user and the ultimate user experience. Right. Even though it's behind the scenes. And then also some of the trade offs that you may have to take. So some level, very high level, but some level of understanding of that tech stack or some key things about the technology are important, and then the language and semantics of it are important just so that you can collaborate. Well. Right. I think that's a really important point you made without having to get deep into can you actually do the coding or could you actually do all of that? You don't need that, but you do need to be just kind of surface level understanding. I think that was really important.

RAJ: Yeah. And I will tell you, you probably will not be better at coding than some of your engineers if you don't have that technical background. And you know what? That's not why it's there.

JJ: Very true. The other thing I want to just kind of bring up and then that'll take me to my next question for you is I like how you talked about the fear that I had starting out and that you had starting out and kind of that imposter syndrome that is natural is because we thought we had to be experts on that solution or the solution space. Right. And the truth is product managers have to be experts on the problem, not the solution. Of course, they need to know something about the solution and how it impacts or solves the problem. But our value to the team is to be that kind of expert on the problem, the market, the customer. And so I loved how you talked about how in your non product adjacent role, you started to learn some of those skills and some of those tasks and the abilities to talk to customers and understand needs, which was very transferable over to product. Right. I think that's one of the things that was important of your story that I took out of that. That's exactly the takeaway there.

So let me follow that up with kind of a segue to if you were advising someone on becoming a data, specifically a data and machine learning product manager, what are the skills that someone needs? And can you get those skills elsewhere in other adjacent roles?

RAJ: Yeah, I would say first and foremost, the core skills of product management is necessary. So specifically, empathy for your users and customers, being able to articulate a strategy and vision and creating a collaborative culture with all stakeholders, including engineering, data, science, design, sales, marketing, legal, kind of whoever you work with. And so kind of included in that are all of these soft skills that a lot of people take for granted. So things like communication, leadership, influencing, problem solving, being data driven, getting results, and building an inclusive culture, all of these things are necessary in order to be a great PM. And exactly to your earlier point, being able to really understand the problem space that you're operating in, all of these are just kind of core requirements to be a product manager, period. And it's definitely required even if you are machine learning PM.

The second piece of that, especially on the more technical side, is like I mentioned earlier, is being curious and continuously asking questions is key. And that's how I learned the most in my career being a more data driven, machine learning product manager. Thankfully, I've had the good fortune to learn from some really smart and generous people in my career who've been open to sharing their knowledge. And so it's really important, especially earlier on in your PM career, to make sure that you're just soaking up everything, even if you don't understand it right away, is important. Just making sure you're making the effort to learn, especially things specific to your product and what are the tech stack that is important to your company, your team will be critical. This essentially helps form your mental model of how things work and the implications of various tradeoffs in order to have those meaningful discussions with your Dev teams. And so I would say this is also an opportunity to discover hidden assumptions and risk and clarify needs. So as you're asking these questions, I think things will come to light that a lot of engineers or maybe data scientists had assumed were already knowledge or information that we already knew about the problem when that was actually a key risk. So asking those questions helps not only you for your knowledge knowledge to understand the implications, but also it's a two way street being able to provide even more clarity to your Dev teams.

And then also I've always found that when I'm the one asking questions, there are other folks that are not technical. They could be other PMS designers, even executives. As soon as I answer a question, like nodding their heads or they tell me afterwards, thank you for asking that, because I didn't know the answer to that either or vice versa. Sometimes one of those will ask the question that I had in mind. So it's good to just clarify things with everyone. So it helps not just you, but just everyone on the team to make sure that you have a clear goal and that you're driving towards that goal in a collaborative manner. I love that advice. I think that's so important to be able to share the knowledge and learn across the various functions. I think that's really, really important. So what does the day to day of a data and machine learning product manager looks like? Similar again to typical product management. There's a lot of working collaboratively. I work with engineering, design, marketing, sales, legal architects. So making sure that everyone is clear on our strategy and vision, making sure there are no blockers or moving ahead. It also varies day to day. So I could be one day focused on translating requirements for the technical teams. Or a lot of the times I'll be talking to customers and users to try to discover their needs and pain points. Other times I'll be working with product marketing on some competitive intel that we can put out for our sales teams to make sure that they're very well versed also when talking to our customers. But the thing I would say that is different than typical product management specifically for data machine learning product managers is I heavily work with the data science team and that includes very research heavy projects. And these types of projects, they have a longer lifecycle than your typical straightforward software products. Specifically with data science, making sure that we're very clear on the goal.

This is even more important than in classic product management just because, again, I think a lot of data scientists, they're very focused on innovation. They want to push the boundaries of what we're able to do, both as a technical function, but also in service of our clients. And so I think it's really important for the PM to really be always bringing it back to the goal. Why are we doing this? And then also with data science, even on the more technical aspects. So evaluating data, what are some of the data samples? What is the experiment that we're looking to do and what will it help us solve? Like, what are we derisking and what are the different models that we're evaluating? And if we get if we reach these metrics, what is our outcome? Like, what are we going to do based on these results and how do we translate this into a productionized, customer facing product? And so there's a lot more of methodology and working with data.

And so it's really exciting. But yeah, it just is much more of a longer life cycle. But it's very rewarding to be working on very innovative products with data scientists, but also with everyone.

JJ: Yeah, it sounds like really fun work. And I at one point in my career was head of product for a data and analytics product line, and I also loved working with the data scientists. But you do, like you said, have to kind of get back to the goal at certain points because a lot of times the data, it is research based, as you said, and you're finding patterns in data that you didn't even know it exists, know existed. And you're finding almost problem, you're identifying problems from the data. So it's actually quite interesting work.

So thank you for sharing kind of that day in the life, getting back to kind of the fact that you're a non technical PM, at least from background. For those folks out there listening who also come from a non technical background, what advice would you give them to be successful as a product manager.

RAJ: The number one thing I would say is ask questions of your technical teams, make sure you understand your tech stack, your architecture like I mentioned before, just to understand what are the trade offs that you'll have have to make and that will help determine how things are built and affect product and business results. So for example, I think here it could be good if you're not comfortable asking, maybe in front of the whole team, make sure that you identify someone like maybe like the lead engineer you have a friendly relationship with, and maybe even in a one on one setting, ask them like, hey, why did we build our tech stack this way? What were our options if we did XYZ instead? How would that change the outcome? Things like that. I think being able to ask those questions gives you a lot of credibility and encourage appreciation from the technical teams that you're willing to do whatever it takes to understand the ins and outs of your product in order to ultimately achieve your joint goals. And so I think it's really humbling to keep asking questions. I think there are sometimes stupid questions. There are things you can Google, but then there are things that are really specific to your product that I think it's totally fair game to ask someone, especially in a more comfortable setting, one on one. But I think just honestly being humble and just making sure that you're always having a learning mindset is really important. So that's one, two. I would say another way to build trust with engineering and technical teams is by bringing clarity through a crisp strategy vision and how the initiatives that all of the engineers are working on, how those tie into our strategy, the value that they bring to our customers lives, the success metrics, and what is our game plan for testing and experimentation? Just making sure that you're extremely clear so that they can focus on what they're good at is really important.

And then also, I think it's part of that. Using data as a basis for any hypothesis you might have also goes a long way in instilling confidence in your technical counterparts. And so just bringing clarity any way you can, I think is really appreciated. The third thing and this is product management. One on one is evangelize your customer needs. Make sure you're an expert on the problem space, the needs, the desires, the constraints, and continuously communicate that to your engineering and Dev teams. Make sure that everyone is on the same page on what the customer needs. Include how this ties in with your company and team strategy and how you're positioned in the overall competitive landscape. There should be no confusion on that front like, why are we building this? You should be able to have very frequent discussions on why are we building this? What is the latest customer feedback? Making sure that you're able to bring it back and close the loop. There is extremely important engineers. Some of them are very heads down. So making sure that they understand why they're doing what they're doing. And then I will say as part of that, for some, especially my engineering lead and counterpart, it's important to also bring them into those discovery sessions with customers and users directly and collaboratively set the strategy so they are part of that process, not kind of an afterthought.

And then lastly, I would say be the link with all other teams, as I mentioned before, including sales, customer service, marketing, operations, legal, just everyone to make sure that everyone is working in tandem and driving results. Make sure that the technical teams have they don't need to worry that the goal is being achieved just because they're always a million moving parts and pieces of the puzzle. And it's really your job as a PM to make sure everything is coming together in a cohesive manner to make sure that the product is successful. Yes, I think that's tremendous advice just to reiterate those asked questions, really understand the stack, the architecture, et cetera. Build your trust with your engineering by having a really clear strategy envision and making sure that's communicated evangelize those customer needs, which is key. And then being that conduit to the other teams. I think that's such good advice to any product manager, but certainly ones in a technical field who come from a nontechnical background.

JJ: I think that's awesome. You mentioned earlier that you're always kind of on a learning journey. Are there certain resources that you have found that have been very helpful in learning how to work in this space.

RAJ: Yes, as mentioned, other than leaning on your teams and learning and soaking up knowledge that way, there are other external resources. So in terms of on the more technical side, you can always if you know you need to take courses on YouTube, Coursera Udemy depending on what text languages your team uses. I've personally taken courses on the basics of web and app development, SQL, Python, Machine Learning just to familiarize myself with some of the lingo. For example, like Andrew ING's famous machine learning course has been pretty useful. But again, the most value you'll get on the courses is putting the learnings into practice, either as a side project or like a personal website, things like that.

Outside of the technical aspect, I would also recommend the classics on product management, but also business strategy design and leadership books and resources. A few of these include Lean Analytics, Continuous Discovery Habits by Theresa Torres, The Lean Startup, Good Strategy, Bad Strategy. I love blogs like Deb Lui’s Substack, podcasts like How I Built this and Founders Journal. In order to be a well rounded PM, it's important to learn about analytics and strategy and how to talk to customers and all of that in order to make sure that you're bringing high leverage skills to your team as a PM. And I think something that's really important to mention here is it's important to take inspiration from all of these resources. But feel free to adapt the best practices to your situation because not everything is relevant. So if some metrics don't make sense for your B2B SaaS platform, it's okay. You're not a bad PM. It's just it isn't relevant. Feel free to use what makes sense for your team and your industry.

JJ: Yeah, that's such great advice and great resources. Absolutely. We're definitely on a learning journey. And so I love the advice to not only learn some of the tech side, but also just the strategy and business side. So great advice, great conversation. Raj Muhar, Director of Product at Innovid thank you so much for sharing your wisdom, your expertise, and for being here with me today.

RAJ: Thank you so much, JJ. I had such a blast talking about my journey, and I hope people can relate and find value from this conversation.

JJ: I'm sure that they will. Again, thank you so much for sharing your wisdom, sharing your journey with us. And thank you all for joining us on Product Voices. Hope to see you on the next episode.

Resources

Connect with Raj

Ask a Question

Becoming a Data / ML Product Manager with a Non-Technical Background

Episode 018: Raj Muhar

Recent Posts