Building a High-Performance Culture in Product Teams with Abraham Alappat, Product Manager at Georgian

Speaker A: Welcome to Product Leaders Podcast, a podcast by fireart. We are the defenders of usability, champions, product consistency and the emissaries of enjoyable human technology interactions. Don't play the game. Listen to the podcast where we share conversations in product leadership to help empower you to produce great digital products for your customers. Hi everyone.

Speaker B: Today we are having Abraham, an entrepreneur

Speaker A: with a passion for product finance and strategy.

Speaker B: He has skills in financial modeling, project management, Pandas, uh, Python, SQL, quantitative analytics and business strategy. Currently he is product manager at Georgian, a fintech company offering data driven platform for providing insights to solve the key challenges CEOs face as they grow their businesses. And today we are going to talk about how it's like to be a product manager leading AI ML products from 0 to 1. So stay tuned. Thank you for joining our podcast and would you like to take a few seconds telling us a little bit about yourself and about your background?

Speaker C: Thanks Oleg and thanks for having me here. A little bit about my background. I've had a life before product management. As with many other product managers, I spent some time in finance, sometime in consulting, in fact sometime in entrepreneurship as well before I decided to go into kind of product management for my finance side. I spend most of my time in equities research and in investment banking for consulting work. I actually did a lot of work on evaluating companies for large private equity groups here in Canada. And then I decided well, why not try and build a product around this? And that's why I jumped into kind of entrepreneurship and that's what kind of kicked off my interest in product management alongside my entrepreneurial background. I also spent some time on my MBA out of uft. And then roughly a couple of years after I started the startup I kind of realized that I uh, actually need some more experience working on product at a larger firm. I started looking around and landed at Georgian, which is a venture capital firm here in Canada, the largest one here actually. And I helped manage their internal quant investment engine, if you want to call it that. Like we use machine learning and AI to discover the next best startup to invest in or find the next best market to invest in as well.

Speaker B: Awesome. A little bit coming back to your background, tell me what basically motivated you to, to switch from being entrepreneur and being a founder to actually work as a product manager. Because based on my experience I talk a bunch of entrepreneurs and startup founders, usually they have the mutual trait. I would say they are kind of free spirits and they don't follow the rules to sabotage organizations structure and so on. And somehow I felt that for most of them, Skender sometimes could be tricky to switch back. Not I, um, wouldn't say like switch back, but at least to switch to work as a product manager or whatever, like in a company. What kind of things motivated you to make a switch?

Speaker C: That's a very interesting question and I like that free spirited analogy over there because that does describe me a little bit based on my history of jumping from career to career, because I'm just curious and I like trying following where I want to go. One of the things that I discovered pretty early on in entrepreneurship is that you need to have a rock solid team of data scientists, machine learning engineers and things of that to really make progress on a very technical product like the one that I was trying to build. And what I realized was that there's a big learning curve as well, both on the technical side, but also learning how to communicate with your stakeholders who are your own team. And I felt that Georgian was the ideal place to do that because they had a small team of, um, product managers. In fact there was only one and they actually had an enormous team of data scientists and machine learning engineers. So it was a ripe opportunity to jump into an organization that had a lot of upward momentum and you could actually build something great. They also had a culture of like, innovation and like disrupting themselves on a repeated basis. So I felt, well, why not jump in and let's try this out. Did not hurt that they already had a product that was kind of doing what my startup was doing anyway. So I kind of took it over and took it to the next level.

Speaker B: So it's awesome. And how basically your early days of your startup looks like. I mean, I know there are like a lot of books that you need to be lean, you need to spend as less money as possible, but in case of ML, I don't feel that it's kind of right way to do things just because in general it's costly and it's not something that you can just build in no code. It's something where you need to find at least an experienced CTO at that field. And not all the CTOs can complement your skills or help, uh, build the technology how it looked like in your context.

Speaker C: That's a very deep question. So basically the interesting thing about one of the toughest things that you got to get through is the, is the technical aspect. Regardless of whether it's AI, you will be under an enormous learning curve. It's not even vertical. It's practically like you're doing cliffhanger at that point in time, but what you end up realizing is that through iteration of working with people, it's not the product manager's job to come up with a solution. Your job is to understand the why. And it's the same thing for an entrepreneur. You don't necessarily have to know the exact solution. You do have to have a vision that hey, I want to solve this problem and I want to address these things. But you work collaboratively with your team and oftentimes it's about finding that right team that can bring you up to, up to speed. Hey listen, you know, this is how we do machine learning, so on and so forth. Now in terms of the lean aspect, which is the other aspect that you kind of mentioned, I would dive into kind of two things. First is machine learning. Back then, when I was doing it back in like 2017 was a bit of an earlier field compared to 2023. It's about five years. You know, a lot of the AutoML packages and things like that that we use these days don't really exist or uh, were pretty premature back then. In fact, some of the transformer models and everything else, Bert, and everything was relatively new back in 2017, so it was a little harder back then Today, if I were to answer that question for listeners today, I would say that it is very possible to pull up a MVP using you know, simple libraries like Sklearn, you might have heard of that, or something with TensorFlow for that framework and then use that to come up with an MVP that just provides a little bit of value. Right? That's what you really need to do. Show that hey listen, there's a little bit of value that's competitive with alternative methods of doing or solving this problem. If you can do that, that's when you can go to like someone like a pre seed company or like even like your early stage teammates and convince them to join or give money and then you iterate upwards, you say what's the next smallest bit of value that I can add? And you always want to do it in the smallest possible way. In Georgian we do increments every couple of weeks.

Speaker B: Right.

Speaker C: And it's been that way since the foundation of some of our products. So we don't start with like an 18 month gap where there's nothing. Right. And you build stuff like that. That used to be the case before you had all these kind of ready made libraries. But nowadays you can be agile.

Speaker B: Okay, cool. And um, okay, getting back to the mvp, you know how to find a balance. I mean, let me make an analogy. You want to sell pizzas and you don't have enough, I don't know, instruments to do that, but you want to try whether or not your pizza is good. And you can end up selling burning pizza. And at the end, once you get some users that are going to buy your burnt pizza, the only feedback they can, you can get that your pizza is burnt. It's not kind of something they would like to reorder. And I think it's the same with mvp. You kind of uh, thinking that you need to create something minimal and viable, but you don't. You always to take in mind that you need to also, especially in 2023, to create something like minimal but also lovable. And in that case, how to find this balance.

Speaker C: Yeah. So inevitably, whenever you're making your journey towards the minimal lovable product, you're going to hit the minimal product in between. The key is to make rapid progress and oftentimes, you know, one of the mistakes that I made when I first joined Georgian, for example, is trying to get things perfect on the first version, right? What ends up happening is the requirements that you elicit. Everything else like that are great, they're wonderful, but there's oftentimes a set of unlisted or unstated requirements that is hard to elicit ahead of time. And if you don't put an MVP out that's somewhat not lovable, somewhat not great, what'll end up happening is you won't discover those unstated requirements and what you think is the minimum level product will actually end up being the minimum viable product of burnt pizza anyways.

Speaker B: Right?

Speaker C: And if you earned a lot of time, you would have used up a lot of time doing this perfection and you would not have gotten what you really wanted on suing, how do you say, experiments at Georgian when we, instead of building up an entire pipeline and then showing them that machine learning score for startups or something like that, imagine just putting things into Google Sheets, right? Literally running a manual set of experiments, doing something in Google Sheets and coming up with a process to just go through the startups. We did that and it was a resounding success, right. We were able to collect, uh, very quick feedback. Hey, it's not doing well here. It's doing really great there. I really like this. We were able to iterate so quickly on the final design. By the time we actually started building the pipeline and doing things at the end, it was a huge success. Yeah, of course, that full pipeline, build that ML Ops infrastructure and everything to build up that does take a year to two years. But then what ends up happening is we were able to iterate from a very basic MVP model to MLP model. Right. And then that kept them, um, happy until we got the full infrastructure up and running. And now it's like a magical experience.

Speaker B: Right?

Speaker C: Uh, we like to talk about magical experiences at Georgian and we like to think that our products are now at that stage. But we had that burn pizza stage earlier on as well.

Speaker B: It's great. And you mentioned that you are like the only one product manager, right?

Speaker C: No, I'm not. So I was the first junior product manager, uh, Jason Bernier. And then now we have Kaid, who's also a product manager at Georgian. He's actually leading our outward facing product. So we took what we built for our own quantum investment engine and now we're repurposing it for outward, how do you say, use in our portfolio companies to advance their sales pipelines. So that's much bigger project and in fact about 50% of my time, 60% of my time is on that project or that product right now.

Speaker B: Cool. And how the structure looks like in your current organization? I mean probably all the department has their okrs. And also I check your website, you kind of uh, communicating a few things. I know that you're preparing like you have a solution for CEOs and startup founders, but also your other parts of your company also investing on a seed round, I believe. And I'm curious how the structure looks like and how you're dealing with some sort of okrs. Probably you have such things in your company.

Speaker C: Oh yeah. We just went through a, uh, finalization of our OKRs. Because when you're doing experimental stuff after you do the initial research, you have to rework the OKRs a little bit. Right. So that always happens. Yeah. So the overall organization is centered around investing. We are a VC fund. In fact, we are a growth equity fund. We actually invest in series B, C and D rounds. We uh, are a little bit later stage in our investment. What we tend to do is look at companies that have hit kind of product market fit and are kind of in that accelerating phase where they want to take over the North American region or European region and then we start investing in those. The main focus of our firm is to actually invest in AI. So what we ended up doing is to build a large applied research team initially and now a large product and engineering cohort as well relative to our size. In addition to that, we have the traditional VC departments, we have our growth team that kind of sources companies and markets. We have our investment team that does the kind of middle of funnel kind of investments like the really good investment bankers and former product managers that are now VCs who love investing. And then we have our administrative uh, staff as well. And then we have the customer success team that actually focuses on adding value like internal consulting group as well. All these different teams work with us to in the product side to determine kind of okrs both for like a portfolio facing product and of course for the investment kind of facing product as well. And it's kind of a collaborative effort. We kind of divide the business goals between the different teams best practices and how we kind of determine the okrs in our own team. Product team is largely around product stages, hitting product market fit, building out the same way that any entrepreneur would do kind of like for their early stage startup. The difference here is that we are probably uh, a little bit more focused on your cybersecurity compliance things of that because we are a financial institution so we have to do those things as well.

Speaker B: How being a product manager and AI, uh, ML M focused company and also as a company that actually vc it's different from being a product manager in a startup.

Speaker C: So there's a couple things. First is VCs don't grow as fast as a typical software company. So you had to be lean all the time. Right? That lean startup thing is how we live our lives every day. But that's the first thing, like VCs have a very steady but long term growth profile. So that's the first big difference. The second difference that we have is from a culture perspective we have a lot of attention to compliance reporting things like that. You know, we report to the sec, to other things like that, the OSC here in Ontario. So these securities commissions and financial institutions and regulatory bodies require quite strong regulations and we can't use insider information for example for any of our machine learning models. So we have to do a lot of that testing and that a lot of that falls on the product product team. So sometimes I wear the hat of you know, not just a product manager but the uh, compliance officer, a small data engineer, those kind of things. So it still feels like I'm part of a startup. So that's kind of the reason why I'm really enjoying it. And the other part that makes a difference here is that we get an enormous exposure to the product teams and the engineering teams in our portfolio companies. So we have invested in 30, 40 companies all with their own product teams and engineering teams. And we're forming these large guilds and ability to like speak to them and form best practices and a lot of them are AIML focused so we can learn the best practices from them. So that's a really huge positive in my mind as well.

Speaker B: For Jordan, based on our 15 minutes conversation, I would say that I assume that you're pretty technical. And do you see like technical background as a prerequisite for managing ML products?

Speaker C: I wouldn't say it's a prerequisite. It depends on the company and the culture that you're in. Like for us we take on a little bit more like a Google type approach where the product managers had to be slightly technical, where we not just decide the whys and the business case, but we also decide a little bit on the hows, we lean on the hows just a little bit. Final decision is always going to be in the hands of the machine learning engineer or the data scientist. But because we know our domain really well, like I spent years in investment banking, so for the finance side of things, how to structure the problem and things like that, they can lean on me a little bit. Right? So I have to know the technical aspects to inform that discussion a little bit better. That said, in general, if you're in machine learning, I would really strongly suggest that you get some courses done on Coursera or a datacamp or things like that or Udemy that'll actually bring you up to speeds. You know what an XG boost model is, you know what SK Learn is, you know how to spin up a Jupyter notebook and you know how to do some SQL queries, right? I wouldn't say that's necessary. On day one, I started learning most of that and I'm still learning most of that today, right. I'm not 100% data engineer or a data scientist. Right? But being that gap and the most valuable part is like being able to say like, I can see what you're working on, John, who's a great machine learning engineer. And then you say like, but this is how it adds value. This is how you should think about it, adding value. How would you make the decision today if this is the value? Right. But in order to connect what he's doing to value, you got to understand a little bit of how things work underneath the technical details of how to optimize value. I will leave to the engineer, right. Or the data scientist, they can then take it from there. But oftentimes that last mile gap to making them customer focused, that's my job. Like about 50% of the time, I would say. And that's why I need technical capacity.

Speaker B: Okay. And how you define and prove the value.

Speaker C: Yeah, that's an interesting concept because there's many layers on the very top. There's this qualitative feedback that you get from the users, the user delight and that in the end, you know, once they're delighted by your product and they want to like buy it or use it, that's a huge positive, then you have to kind of identify why. Why they delighted is it that saves them time, gives them better quality leads. If you're giving them leads in sales or marketing or investments, which is kind of what my product's about. And then other things like that, right. As you dive down that kind of issue tree into like quantitative metrics, that's when you can start from that qualitative base to write down quantitative metrics. That's when you can start really identifying the value levers that you want to pull as a product manager. Maybe it's nothing to do with the AI. Maybe 80% of the value has to be with the UX on how the AI is being used. That was definitely a use case internally. And you know, I think of like GPT3 and how the real amazing thing about that is how they set up the entire UX UI and feedback cycle on that front end interface. Right. If you really look at the back end, I'm like, yeah, transformers of that type and large language models have existed for a while, but being able to like save the context of a chat and then reenter that as a input on suing parts of the conversation, that's exactly what resulted in GPT looking like it was reacting like a human being on the other end. Almost. Right. It almost hit the Turing test in a lot of situations.

Speaker B: And, um, how much time you spend on preparing decks or some kind of presentation to communicate the value to other teams, other units or management, it is a lot.

Speaker C: If you're not doing that on a consistent basis and bringing all your stakeholders up to speed, then what ends up happening is when you need something done, you're going to have to spend the next couple of weeks or next couple of months educating them, bringing them up to speed. And then you'll have the situation where half your stakeholders view something in some way, half your stakeholders view it in another way. And that can cause problems for you in any organization where you're not the CEO or uh, entrepreneur. Right. Because you have no authority as a product manager, you had to influence. Right. It's all the responsibility but none of the authority. If that's the case, stakeholder management should be the biggest thing. And it's probably sometimes the biggest lever that a product manager can pull.

Speaker B: Right.

Speaker C: I'll give you a practical example. Because I was able to create all these decks and like, bring senior leadership and the team saying, my data budget went up almost tenfold in the last year.

Speaker B: Right.

Speaker C: Because I was able to convince them of the value of, uh, machine learning and the signals that come from it. But it took a while and that took a lot of decks and a lot of work.

Speaker B: Yeah, exactly. Also, I know that a lot of product managers hate the things that sometimes people promote product management role as a product manager, mini CEO of your team. But in reality, it's like if your team doesn't perform well or doesn't meet the expectation, then you, as a product manager, it's your fault. But if your team succeeds, then it's like a, uh, team success. And usually it looks like this, right?

Speaker C: Yeah, I mean, I'm actually a big fan of that, to be honest. I like that servant leadership model. In the end, if you're the leader in spirit or in some companies, the product manager is also the GM of that particular product, right? Like the general manager as well, then it's the buck stops with you. In the end, you're the one who has to take responsibility because you set the direction, you set the vision. Right? And that's true in my case. Whenever there was a success, I would always let the engineer and the data scientist try and present as much as possible. It's something that I've learned from our head of product, and I, uh, really like his approach. You know, Jason's approach as well. It really builds the team camaraderie and it, in the long run, it builds that culture of like, hey, listen, we're doing this as a team. You know, some of us gotta put in the extra hours. Some of us have to, like, take a step back and put our egos aside. And that's a lot of times that happens because when you're passionate about an area, right? Whether you're a data scientist, an engineer, or even like a product manager, sometimes you're like, oh, I think this is the right way to solve things. And then you have to take a step back and be like, nope, that's not right. The customer feedback was pretty terrible or wasn't the way that we wanted to be. And then, you know, having that saying, oh, we're, but we're a team. Our losses are together, our wins are together.

Speaker B: Right.

Speaker C: That kind of ameliorates that up and down rollercoaster cycle, especially in early stage products. For a later stage product, I would say that you can't be the CEO anyways because oftentimes if you're junior product manager or intermediate product manager, you're part of a much larger organization and you're just taking care of your small part of the product and your, your component is tying up with like all the other ones. Right.

Speaker B: So, all right, getting back to your background, you have an MBA and tell me how having an MBA help you to pursue your current career, what kind of thing you think were useful or you have learned that help you grow even faster than others.

Speaker C: It's a great question. So one of the interesting things that the MBA gave me was actually exposure to even more startups and good understanding of the overall. Like how do you say, how do, how does marketing work? How these different areas of business work that I never really had as a person who specialized in finance only. Right. What it also gave me in a big way is connections. 80% of the value of an MBA comes from the network that you build there. Other students as you go there. My job here at ah Georgian was largely a result of one of the classmates that I had there who worked at Georgian referred me in and got me this job. That's essentially how the value works. But from a academic standpoint, knowing how marketing works, knowing how product and marketing work together, those kind of things added a lot of value because it made sure that I didn't actually make silly suggestions on the day one of my, of my work here at uh, in the product team. Oftentimes entrepreneurs go in thinking, well I've had a uh, marketing team and everything else that. But that's oftentimes a very different way than you know, a large organization with its own established practices kind of works. And going to an MBA and getting exposure to these startups or these even large organizations and seeing how these different departments and everything work together, you kind of get a feeling of like, okay, here are how the different components and these concepts all kind of like line up and I can help you practically in the job quite a bit.

Speaker B: Okay, cool. And as I know we Talked before on LinkedIn and you mentioned you have been bummed with a lot of work the last weeks once this uh. Can you share with us all the kind of things you are working on right now?

Speaker C: The kind of things that I'm working on right now? Yeah, sure. Right now I'm actually working a little bit on building our time Series modeling kind of infrastructure a little bit. So we actually pulling in a lot of data from a lot of our customers and we need to run kind of predictions on that data. Oftentimes, like I mentioned, we need to go towards that formalized ML Ops infrastructure. So I'm designing with, co designing with a lot of the uh, engineers and data scientists that particular set of infrastructure. This involves working with kind of standard off the shelf libraries, but also working with some new components and some new things that we design in house as well.

Speaker B: I Also check your LinkedIn of uh, companies that you're working at right now and I feel like you have everyone like in house. Have you ever tried to work with freelancers or outsourcing teams to speed up your delivery process?

Speaker C: That is a very good question. We have worked with some um, contractors for, let's say UX UI design stuff because our main wheelhouse is the back end systems. Right. Like that's where our specialty lies. So what we'd like to do is we double down on our specialty and where there isn't that much talent or we don't have that much experience, we bring in the external contractors and external companies to actually work with us to build that side of the product eventually. Will that always be the case? If you're an established company or in a startup ideally, you shouldn't be relying on anybody outside for these things. You should be getting to the point where, uh, everything should be in house because if somebody else can build it for you, then what exactly is your differentiator? Right. This is probably centered off the shelf, customized, but off the shelf, kind of like components, right? In that case.

Speaker B: Yeah, exactly. And tell me a little bit about your culture in your team or in your company. You mentioned that you're practicing servant leadership. It's awesome. And also seems like as you have, I would say, most of your team members are internal team members. They're working in house with you. And I'm just curious to know more about how culture in your company looks like.

Speaker C: Yeah, so the culture in Georgian is very much a team culture. Right from the very top of the organization down, we kind of had this attitude that no one person is a superstar. We try not to like have that. Everybody is a team member. We work things together, we climb up together or we fall together. Right. And that's kind of permeated our product culture as well. We tend to be inventive, we tend to be have fun with experiments. Right. One of the things that Jason, the head of product, was an entrepreneur himself, so he loves doing this MVC, throwing out a whole set of MVPs just to test different hypotheses and product hypotheses. Right. Whether it's a feature, whether it's an entire product of its own. And what that allows us to do very quickly is to kind of validate our ideas, you know, our hypotheses. And I found it a very inventive, freedom loving culture, so to speak.

Speaker B: And yeah, I also uh, saw that. And you so mentioned that you were in consultancy before, right? How consultancy is different with what you're doing right now?

Speaker C: Well, that's a decent question. I think there's a lot of people who think that product management is consulting and it's definitely not. Mainly because in a consulting gig you throw the idea out and you say you should do X, but you don't actually have to implement. If you're a strategy consultant, if you are an implementation consultant, you tend to, okay, I'll work with someone who's actually in the end responsible for the day to day organization. I'm there for like three months to help quote unquote implement a process or a technology that I'm out, I have to go on to the next product or next thing. If you're a product manager, 99% of the time you're sticking with your product. You're the client, you're the person who the, the uh, consultant used to talk to. Right. Because after that consultant disappears, after that contractor disappears for the UX UI for example, I'm responsible for that UX ui. I have to keep it alive. So there's this longer term focus. When you're a product manager you tend to have a vision and you tend to think things like two to three to four years down the line, where do I want to go? North Stars, Those kind of things, at least from my personal experience. Yeah, I would say that's the biggest difference right there. You're a lot more long term focused

Speaker B: in terms of work itself. I know that usually people say that in consultancy they always need to usually their overtime or they work a lot and also they burn out just because as you mentioned that projects are uh, usually like short term. If we compare in terms of work life balance, your current company you're working at and you are experiencing consultancy, how your work life balance look like and is it like better?

Speaker C: Now I might not be the right person to ask for this because I'm a workaholic, okay. I actually love my work. My wife will literally tell me that you work too hard all the time, but that's okay. That's just my personal preference. I think from a requirement standpoint, if you're, let's say the average person who wants to have like a little bit more of a balanced work life balance product manager is not too bad to be honest. Depends on the culture and the company that you're coming with. But at least in Georgian, I'm um, working less hours than in consultancy. I was working 80, 90 hours a week plus. Now that's not to say that there are not times, weeks on end in product management where you will not be working those hours. You will be working those hours at some point in your career because you have a big release that your company is committed to and something has gone wrong and you will be pulled into an emergency for like three to four weeks. That is inevitable. Every product manager that I've ever spoken to has talked about that. But overall work life balance is slightly better here, like in Georgian and I think in across product management as well. Because you have a longer term timeframe, you can space things out. If you're smart to build out like small increments and each increment has like a small degree of work, you can balance those things out.

Speaker B: Okay, cool. Thank you. And I, um, know that we do have a lot of young product managers listening to our podcast and I think like we need to also wrap up a bit. And for the closing question I would ask you, maybe you can spend a few minutes and build some kind of a roadmap. If I am, I don't know, want to start my career in product management, what should I have, what should I learn before start applying to the product management position?

Speaker C: Yeah, sure. I think there's a couple things. So number one is learning the processes, uh, and how to work with the people because you always start with the people that you're with. You need to know a little bit about agile methodology, things like that. Kanban pick one. You don't have to pick all of them, but just figure out one of those and take a course and take a small udemy course or something like that. Figure out how it is to work in app. Ah, in an agile environment. That's something that you could do as a student quite, quite rapidly. Second thing is kind of your technology, that technical aspect that we talked about, you don't have to be perfect at it, but you should be able to know a little bit about what's the difference between a front end, back end system, um, things like that, some common things. Right. Spend a couple of weeks reading. It's not that much more than that, if you're a very junior apm, that will be required. Third is really become an expert at critical thinking. Right. Because in the end, a product manager's main role is to discover why a product needs to be built. And that involves how big is the problem. This is a real problem. Can somebody else solve this problem better than we can?

Speaker A: Right.

Speaker C: Those are all a little bit more about critical thinking, market research, those kind of skills. And those kind of things are more general.

Speaker B: Right.

Speaker C: Learn how to think critically. Learn how to be kind of free of constraints and of biases. Oftentimes when I was hiring an APM to work for me for like, you know, on a contract basis for a little while, I would look for that, that ability to be agile on their feet, think about problems in like an agile way. I don't mean agile in the sense of the structure. Right. I mean like a sense of the like, uh, being quick on your feet. That's probably the third thing that I'm looking for. The most. Last thing, learn how to speak to people. Right. Learn how to be professional, be courteous. There will be times where you will be frustrated. Your hypotheses will always be wrong. You will go down a, uh, garden path. You will not get the answers to your questions when you do interviews. In fact, you will find that some people will never want to interview you. If you're a customer, right. Your customers may not, ah, just want to talk to you. They're busy, they have money to make. And those things you got to learn how to navigate that stakeholder management and learning how to speak to people, that's probably the most valuable, I would say, of, uh, all the things you can have all the rest. But if you can't speak and get somebody to buy into your idea or to like give you an interview or dive really deep into a problem that they have, then you're not going to be a good product manager. Because that's like 90% of the value that you bring to the table. Right. 10% is like learning how to like talk to an engineer and in the day. Right. But 90% is identifying the why. And like maybe a little bit of the why, but mostly the why.

Speaker B: Yeah, it's awesome. And I agree with you that all the technical things you can learn based on courses, but the most complex part and most tougher parts to learn is, uh, actually to learn how to listen and how to speak. It's really complicated things, I would say. Yeah. And also, I know I said it's a last question, but you also mentioned interview and I know that for any type of founders, any type of startups, um, product managers, whatever, for everyone it's really important thing like our uh, interviews. And maybe you can also tell us a little bit more about how you structure the interview, how you prepare to the interviews so you can make sure that you're asking the right questions.

Speaker C: Yeah, so because of my consulting background, I tend to break down the interviews very much like a consulting firm. I tend to have behaviorals in the beginning, a little bit of the technicals in the middle, and then right at the end I will ask a little bit more about like a case study. Right. I'm a big fan of take home case studies. I don't believe in the instance answers. I've seen personally, like people who are great at giving like in the moment kind of like answers. But then you know, when you think do a take home or do something, there's a much better understanding of how they work in real life because you're not going to solve a problem in a minute in real life. You're going to solve the problem over the course of a week or two or even three weeks.

Speaker B: Right.

Speaker C: If it's a small problem. So those are the kind of like the large structures within the behaviorals. I look for a lot of the same things that a consultant looks like. You know, ability to be poised, staying calm, those kind of things that I just mentioned earlier for the technicals, because I'm an AI specific product management, I need to know that they at least know what the basics of AI are, what is machine learning, what is a predictor, those kind of things. I don't expect them to know the details of the Sklearn library. Like that's not something that I need them to know. They can learn that over time. That's okay. And then um, on the last side, kind of like the ability to think critically and things like that that I find is oftentimes the harder aspect to kind of land on for a new grad or someone who's relatively junior because that involves being able to like take a step back and say that hey, listen, what is the real problem here that I'm trying to solve? Oftentimes the question is structured in like a little bit of a tricky way because we want them to think like two or three levels deep. Right. And those are the kind of things that I would like to look for also when they come in for the case study presentation, sometimes I grill them and I look for that same thing that poise, you know, trying to Understand like, hey, listen, do you really think critically about this? Did you think about that? What if I pressure you on something, Right. Are you able to stand up and defend your ideas?

Speaker A: Right?

Speaker C: Because in product management, oftentimes you will find challengers to your ideas. Either because there's always one person who's skeptic, right? There always is. Or because in an organization, sometimes you come across these people who are competitors who have their own ideas and they need to get funded too. So there will be a little bit of back and forth. And it's healthy. It's not never a negative thing. It's like a healthy skepticism that comes up. But you got to be robust in your confidence. And I like to see that in my juniors as well and my teammates. Yeah, sure.

Speaker B: Also, I would say that everyone who I speak with with a consultant background, they're always confident. I don't know what is inside, but when you're just looking at them, you can see like, they're confident.

Speaker C: It's all the scars from our guidance having consulting. Uh, yeah, we have to be confident. Otherwise we get like, on a review, we get said, well, you know, you need to be more confident when you present. So they're like, okay, yeah, you even

Speaker B: need to be confident when you are not. You don't even know like, what you are presenting.

Speaker C: That happens a lot in consulting, a lot more than consultants like to admit, to be honest.

Speaker B: Okay, cool. I think like, we can finish our podcast episode and thank you very much for joining our podcast and I think it was very insightful, especially aiml. Um, it's something that everyone would like to learn and I think we can just break up this podcast into notes and I'm sure that user can just use it as a checklist on how to start their career in product managers.

Speaker C: Makes sense. Thank you for having me. And hopefully it'll be useful for all the MPMs out there, I'm sure.

Speaker B: Thank you very much.

Speaker A: Product Leaders Podcast is brought to you by Fire Art. I was your host Tolik. To find out more about Fire Art and how we aim to build a brand that will contribute to the world with useful products to empower people and make their lives easier. Visit Fyart Studio. Search for Fire Product leaders in Apple Podcasts, Spotify and Google Podcasts or anywhere else podcasts are found. Make sure to click subscribe so you never miss any future episodes. On behalf of the team here at ah, fireart, thanks for listening.