Product Leaders Should be Good People Managers with Jean McCabe, Chief Innovation Officer and Chief Product Officer at Agio

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. Today we are having Jin from Ajio. Jin is experienced and action driven product leader who has taken new products and business lines at multiple companies from zero to one. She has built technology products in both B2B SaaS and consumer spaces and manage teams for over five years bringing products through to successful acquisitions. And today we are going to deep dive into people management in product organizations. So stay tuned. First thing first, thanks for joining our pod today. I'm curious, can you tell us a little bit more about yourself and what you are doing right now? Because it's surprising in 24 hours how it's possible in general to take care of two positions, Chief Product Officer and Chief Innovation Officers at the same time. Sure, yeah. It's certainly more of a job than I expected to be doing. So I started out in strategy consulting and data analytics and sort of fell into product management, which I think is pretty normal to start out in something adjacent to product management. There weren't any product managers at the company I was at. I started doing a job that was sort of liaising between the software developers and the business and defining what we wanted them to do because nobody was defining them what we wanted them to do. And then after doing that for a little while I was like, oh, there's a name for this job. And so I asked them, can I have that title? And they said sure, whatever, that's fine. So I kind of became a product manager by accident and then my next couple of gigs were just, you know, pretty standard B2B SaaS PM jobs and started working on bigger and bigger teams, started managing people. And then in 2020, just after the pandemic hit, I moved to my current job which is at aio, which is a managed service provider for IT infrastructure, help desk and cybersecurity. And so I came on board as the Head of Product and then shortly thereafter kind of became the Chief Innovation Officer which encompasses product management, software engineering, platforms, data science, really the entire R and D function at the company, which wasn't my expectation, as you can see. I don't have an engineering background, so managing the engineers was not something I anticipated. It's something that I've really enjoyed. I've learned a lot from it and I think have learned A lot about product management from managing engineers because when you're a pm, you work really closely with engineers, but you don't have to think about how to structure an engineering organization or anything like that. So it's been really fun, it's been really interesting. And what's interesting about Agio is that it was really kind of a technical transformation project when I came on board. Agio has always been a technical company, of course, because the product is technical services, but kind of I viewed my role and my job as turning it from a technical company into a technology company where not only were there a lot of people at the company with technical skills, but the primary value that we provide through our product derives from the technology that powers it. And so that's been kind of the project of the last couple of years, growing the team, growing that technical kind of value prop. And it's been a really interesting challenge, but I think ultimately going pretty well. To be honest, I can't agree with your statements that you mentioned. You had I basically generic career paths because I checked your LinkedIn, I did my homework and in the last two companies that you work, you basically started as senior product manager and then after that in every company you ended up with C level product positions. I'm curious how it possible to move in such weak base. I would say because in every company you work for two years you started a senior product manager and then you are getting promoted to chief product manager or head of product. And amazed me because I'm really curious how to grow such fast. Well, the first time I've had chief in my title is Atagio. Before that I would end up like director. I think, to be honest, it's in large part because of my interest in people management, because I think a lot of really talented product managers are not necessarily talented people managers. And so it makes a lot of sense to when you're at that senior PM level, you're kind of at that fork where in some organizations the only way to move up is to be a people manager. And so a lot of PMs get stuck there either because there's no way for them to advance without managing people and they don't want to, or they wouldn't be good at it or because the organization isn't big enough or isn't growing fast enough to need more people managers. So that was something I very deliberately, you know, I chose organizations where I thought I would be able to make that move and start managing people. I also didn't mention this, but I've been acquired Twice. So the move from Simple Reach to Conductor was an acquisition. And then in my earlier job as well, that company was acquired and so I ended up brought into larger organizations as part of an acquisition that I was heavily involved in rather than kind of hitting the job market and trying to find something. Yeah, it's interesting. And also I see like in A Simple Reach you let the product and UX teams. Right. And is there like any differences managing product teams and UX teams? Because in terms of vision and goals, I think at some point everyone is facing like one goal or have owners mutual okrs or something like that. Can you share with us how it looks like from the inside? Yeah, it's definitely very different managing product in ux. It's different in terms of personalities. You know, not to generalize, but I do think the kind of driving factors in those two professions tend to be quite different. You get a lot of PMs who kind of super ambitious and want to do more and take on more and be in charge of more, prove themselves and measure themselves and very kind of like hard charging and ambitious folks. And typically speaking, the UXers that I've worked with, they're not ambitious, but their ambition looks a little more user centric, more like intrinsically motivated. Right. Like I want to do a better job. It's a lot of like very creative folks obviously in ux. You know, I want to know the customer better, I want to represent the customer better, I want to create better products that I can be proud of. And I think the motivations for the roles are quite different. There are some people who would do great at both, but I think they're kind of different. The other part is that I find it much, much easier to measure a PM than I do a UXer. There are plenty of ways that you can measure the success of like an individual change to a user interface. You run an A B test and you say, does this button work better than this dropdown? There's some kind of like very basic elements of measuring whether a design is successful at the stated goal. But measuring a UX or UX team on business outcomes I find very, very squirrely. It's very difficult to say this UX team contributed to this amount of revenue or improved our profit margin by this amount or prevented churn in this way or what have you, especially in the B2B space. B2C. It might be easier because you've got specific changes that reach individual users. You can kind of track that funnel a little better. B2B. It's it feels incredibly difficult. And so you kind of end up lumping them into the product organization and saying just going to kind of measure you all the same way. And then you get UXers who are like well that's not fair because the decisions about what we build and how we build it are all made by the PMs and so I'm constricted by the decisions they make and it's difficult to kind of pick out this is what you guys are responsible for specifically and show them appropriately. I totally understand you because I talk with a few chief product officers that basically came from product design background and they also mentioned even take into consideration that they had design background they still find that it's easier to manage product managers just because just simply if we would break down to just a motivation. Sometimes you can be like a gross product manager and you have like onboarding sign up flow and you as a pm you're really focused to increase conversion or something like that. But from the designer, just a designer perspective, it could be boring for a designer because they want to try different type of layouts, they want to try experimentation or layout or whatever and. Or they want to improve their figma skills, prototyping skills but they are not able just to do that because it's not directly product can directly benefit from it because sometimes it's just enough to change your form and then you would get some better conversion or something like that. So totally understand. And I'm just curious, you mentioned that it's still sometimes hard to measure UX impact. I'm curious how the structure what was responsibilities of the product manager because I feel that for example UX team can interview B2B customers for example, gather feedback and then based on the feedback you can come up with better features or better prioritization. Can I say that it's actually directly company can benefit from this research and then it's something that is measurable? Yeah, I mean I think those are two different things. Right. The company certainly benefits from it but I think this ties into kind of the broader problem of it's difficult to attribute activities of a product organization in especially in the B2B world because the sales cycles are so long and the renewals are so kind of complex and there's a lot of. A lot of renewals don't go through because of commercials, you know, because of pricing, because the account manager wasn't very good because the competitor came in and told lies. There's a million things that impact, you know, a 50k deal that you might have at the B2B level. And a lot of the time that doesn't. Either it doesn't have to do with the product, or there's really no way to know exactly what part of the product it has to do with. And I think this is a problem increasingly, as companies hit scale where you have. I've worked on some fairly broad SaaS platforms where there are multiple engineering teams, multiple product managers and pods that are responsible for different aspects of the platform. And so you might have customers who are very focused on one aspect of the platform and that customer churns or that customer renews. And with upsells, who gets the credit for that. Right. How do we know? Was it because the product launch that we did a few months ago was so great that it kept them around and they otherwise would have churned? Probably not. Maybe we effectively don't know. And sales teams aren't great at capturing that data either, because as far as they're concerned, you know, sales a sale or renewals, a renewal. So you just kind of don't get that direct visibility. And in my opinion, there are times when you can, especially when you're selling an individual feature rather than kind of a full bundle of a whole platform. But even in that case, you know, when you think about the contributions of ux, I think it's even less direct. Right. If the product manager's job is to decide what do we build and when, what problem do we solve, and therefore, you know, what do we build? And when you could argue, then that thing that they built, that solution being purchased, is a sign that they did it well, it was good enough for someone to buy. Was it well designed or was it just okay? Was the design actually an impediment to being bought or was it a selling point? Very difficult to tell, I think in a lot of cases. So I just think it becomes kind of a fuzzy. There's no direct science. I've never seen someone successfully say, especially at a B2B organization, this was the impact that design had on the bottom line or the top line of this company. I've never once seen it. I would love to see it. I think it would be great. I would love to be able to do it, but it's not something that I've seen. To be clear. That's not to say that design doesn't contribute. I think UX is really, really important. I think a lot of companies really suffer because of a lack of a strong UX capability. But I think that just goes to the point that things that are difficult to measure often get kind of under resourced because people say I don't know how to quantify how much I don't know what the ROI of my UX team is and therefore I'm just going to decrease my investment so that if the ROI is bad, I'm not losing as much. Of course that goes in the other direction. If the ROI is great, then your opportunity cost is much higher because you're not willing to invest in it because you can't precisely measure the roi. Yeah, I understand definitely. Also I have a design background so I would say it's like every async position if you know how to work with design, if you know why you having this design department it would be easier to manage. But also maybe the twins that you mentioned, it totally makes sense and I think it's the reason why companies usually doesn't require to have like, I don't know, a design on it. We don't have chief design officer position, something like that. Usually a chief product officer because. Yeah, and usually you as a product manager you just need to gather as much insights to make a decision and to build vision to the team. And it's one of the points where you can benefit from design because you don't need to do everything from your side. You can work with different teams and collect all the information needed and then you can work on the prioritization or as like Gerald word I would mention this buzzer word that there are no differentiators between specialization but more like one team focusing one mutual goal. And maybe it's a great point how to treat to make measurable impact. You're not measuring by each individual but more like measuring the team itself, how they are performing and when we do OKRs. I've done OKRs at my last couple of companies and varying levels of success fidelity. And I do find that it's much more effective to set an OKR for a functional team whether that's usually a pm, a UX designer and a group of engineers because it's so difficult to measure those functions separately. And I would much rather this is the stuff you own and you're all measured on it together rather than even if you like having okrs for the functional team. At least to my next question actually how to manage these okrs. I mean there are a lot of books, a lot of articles in medium but still every time I feel there are some issues or someone myself doesn't understand okrs. Right? Not using OKRS framework for the full force just because there Are a lot of dependencies, different teams. And somehow you need to make a big mutual goal and then decompose it into different teams. And then in general, different teams has different goals. Like for sales, it sells, for product input, retention. And there are some other business product metrics. And how to manage all this, I would say chaos production of different metrics. How to align these okrs. I think one of the key factors in an organization using okrs and one of the key characteristics is that nobody ever feels like they're doing it right. And I've read the books too, and I'm not convinced I've ever seen an organization do it by the book. And I've seen a lot of different attempts. I think most organizations end up using okrs as just a way to set goals. And I think that's fine if you just want to set goals and you want to call them okrs and that means you have measurable goals. Sure. I think the better way to use them as a tool of focus, so to say this is the thing that we care about most as an organization or the couple of things that we care about most as an organization or as a department. And anything that is not about that goal or not contributing directly to that goal is less important. And that doesn't mean we don't do anything else. But for some people it might mean that for some members of the organization, it might mean I will quite literally say no to any request to do work that does not contribute to this okr. And I think that's the ideal is that you can give everyone. The way that we do it at agio is we have one yearly metric that we care about as an organization most. So last year it was net recurring revenue because we really wanted to focus on preventing churn and increasing upsell. This year it's a gross profit. So we just want to be a more profitable company. And so as a business metric, that's what every department is expected to care about. And of course, every department can influence that in different ways. Sales has a different input to our profitability numbers compared to service delivery, compared to finance and HR compared to R and D. And so we start with that. And that's not an okr. That's our North Star metric for the year. And then underneath that, on a quarterly basis, we'll do OKR planning. And as an organization, we'll pick sort of a big three OKRs, which are typically each one is owned by a particular department, but they are big three because one, they're very important to the organization and two, they require some cross departmental focus and collaboration. And then we check in on those as an executive team and in various leadership meetings and in the all hands meeting over the course of the quarter so that the whole company is aligned around these being the main focuses that we need to pay attention to for the quarter. And then we will have kind of more individual, I'd say like sub team level okrs that may or may not pertain to the big three. Often they do and sort of feed up into those major goals. And again, you know, I'm less concerned with having kind of one primary objective and then filtering that down to everyone at the organization. I'm more concerned with everyone at the organization knowing what success looks like for their role or their team and being able to say no, I'm not going to do that work because it is not going to contribute to the way that success works for me. And you know, that doesn't mean we can't collaborate. If someone says hey, I need help with my okr, we typically have a culture where people will pitch in and help, which is good. But it's helpful to be able to say like this is what matters. This is the thing that I'm being paid to do. Right? This is my job. And part of my job is define what my job isn't and not spend time on the things that are not going to make my team successful or make the company successful. We've all agreed this is what success is. That's what I'm going to focus on. And yeah usually fit me if I'm wrong that team slide focusing on the also usually team success correlates to company success. But if we breaking it down into individuals. Usually everyone want to grow in their career and sometimes their goals are not aligned with company's goals. Right. How you work with that. Sometimes it happens. I mean as we discuss about designers, they want to, I don't know, improve their craft but working on onboarding flow and that's it. And in that case for them it's not really sometimes beneficial because it's not something they can share much. So I'm curious, how do you work with that? So I don't do OKRs at the individual level anymore. I think it gets too granular especially for you can do it for a pm but for an individual engineer who doesn't, it's too difficult to keep them all in alignment and everything just gets lost. I think one of the answers is compensation. I think something that we've been doing more and more recently is people respond to direct incentives. And not only do people respond regardless of how motivated they are by money, and most people are pretty motivated by money, but even for people who aren't, it's one of the clearest ways that you can signal what matters. So everyone on our leadership team, everyone who's kind of in any management type or leadership type position, has variable compensation that is tied directly to the metrics that are specific to their success at the job. And there's some component of company success as well. So if the company becomes more profitable, then obviously your compensation goes up. But also if you're someone who's creating dashboards for our clients, then if those dashboards get used more, and I'm happy to just say all usage is good usage, if the usage goes up, then your variable compensation goes up and it's that simple. And if you are doing something else and it's related to your own personal goals and it doesn't benefit the company's goals, then you're giving up some of your compensation. And it's nice because we do it kind of well in advance. So you're not kind of surprised at the end of the year about what the outcome is. You knew 12 months ago, this is what I'm going to be measured on. This is how it's going to impact my compensation. And much like a salesperson who has a quota and their whole job works like this, you can kind of track over the course of the year, here's how well I'm doing, here's how well the company's doing, this is what I can expect. And these are the things that if I'm not happy with that, here are the things that I need to change. I think that's the most effective thing you can do. If there's somebody at your organization who's just not going to play ball and doesn't want to do the things you want them to do, then they shouldn't be at your organization. And so you have to set up your incentives to disincentivize that behavior. Yeah, I think we already started collecting some insights and frameworks, how you work and how you structure the teams. And as you mentioned that you work in consultancy before, right? This service company? Yeah, I started out in strategy consulting. And is it applicable in general to consulting service companies or is it something consultancy and consultancy companies should target to have such way of working? Or it's even not possible to integrate such structures, such vision in a consulting companies. I mean, you know, clients are different. Sometimes you are not. Even if you're doing your job best, you don't know what is a client context. And sometimes just because of the client context you are not able to meet some goals even if you are working 150%. What do you think? So I think in every business you can define what success looks like. And so I think that's kind of where I would start is if success is if your business is based on recurring revenue and you want recurring engagements with your consulting customers, then something like renewals is probably a good success metric. If you want a leading indicator, you might have some kind of client sentiment or engagement measure. If you don't have a lot of recurring business and it's really more kind of one off episodic engagements with your clients, then you probably want to look more at client acquisition and kind of the top line. But I think regardless you have to start with like the outcome. Even if what you're talking about is measuring a PM who does you know who works on consulting engagements? The first question is what is the outcome of those engagements? Is the client happy? Is the client coming back and spending more money? Did we build something that brings in more customers or more prospects? I think that's always where you have to start. And then within that, if you have longer running projects, you can certainly build in project specific success metrics and measure people that way. But I think always starting with kind of the outcome that matters for the business is if you can't tie what your product managers are doing to some kind of financial metric for the business, then they're probably not doing anything very important in my opinion. And do people management practices differs from consulting people management consulting companies and people management product organizations? Is it like almost the same or tricky? I think people management has a lot of similarities across all companies and all roles. I think people management is an individual skill that is very undervalued and under resourced. And I think certainly there are managing an engineer is going to have different kind of aspects to it than managing an accountant or managing a customer support person. There are certainly going to be different personalities and different incentives and different skills that you have to manage to. But I think generally speaking, the ability to identify strengths and weaknesses and make people better at their jobs is a skill set that can be taught and can be studied and that most people take for granted. Both people who are people managers and organizations that want better people managers. And I think the clearest way that you can tell is that in hiring processes, when companies are trying to hire someone who will be managing people, I've found that it's very rare that the questions that you get asked in an interview have much to do with managing people. I think they usually have to do with the sort of thought leadership or experience that you have with the function of the team that you're going to be leading. So if you're going to be a director of product management, they'll ask you a lot of questions about product management. If you're going to manage an engineering team, they'll ask you questions about engineering. You get a lot of questions about the content. You do not get a lot of generic questions about how you manage people, how you make people better, how you interface with your team, how you make the team more cohesive. But I think that's the most important questions you could be asking. The most important aspect of a people management job is always going to be the people management, because you are only able to manage your own work product one to one. You're one person, you can only do one person's worth of work, even if you do it very, very well. But if you manage five or six people, you then have the opportunity to make five or six times the impact. If you make them, you take each of them from a 6 out of 10 to an 8 out of 10. That makes a much bigger difference to the company than if you just take yourself from a 6 out of 10 to an 8 or even a 10 out of 10. And is it, for example, if I would, I would like to land my first product management position, right. And I can. Is it possible to learn these people management skills? Because based on what I feel it's something like, it's a soft skill that you need to improve once you get the job and you start working, facing these challenges inside the company or organization, of course the best way to improve the skill. But is there any chances to taste this before you get the actual job? I think it's a good question. A couple of things. One, you certainly can learn people management on the fly when you start managing people, but that's kind of a high risk way to do it. I think a lot of new people managers end up messing up a lot of their early reporting relationships because they're just learning on the job and trying to figure it out as they go. And then the people who report to them end up being casualties of that learning process. And people have to learn somehow. And if you don't already know how to do it, you're going to make mistakes. And even if you do, I mean, nobody's excellent at people management. It's a Very, very hard job. I've made lots of mistakes as a people manager. Everyone will. So you have to be forgiving of yourself. But also it's better not to have to start from absolute scratch. And I would say one of the best ways to become a good people manager is to become good at being managed. And what I mean by that is not just be an easy employee at all. What I mean is pay very close attention to the way that you are being managed and the way that your manager is being managed and think about what aspects of that relationship are working for you, what aspects of that relationship are working for the other people, who your manager manages, how your team is structured and why that is, who's doing well and who's not, and how much time your manager is spending with each of those people and kind of what the relationship appears to be with high performers on your team, with low performers on your team. And then experiment with different ways of interacting with your manager. So if you want something or you need something, or you really appreciate something that your manager did, or you really didn't appreciate something your manager did, experiment with different ways of communicating that with your manager, of managing the situation, of presenting a solution to a situation, and see the kind of reactions you get. And as you kind of spend, say you spend seven years in your career before you start managing people, you'll probably have easily four different managers during that time, sometimes 10 different managers during that time. And you build up a bank of different approaches to people management and you see what works and what doesn't for different personalities and types of people. And you can kind of start setting up your own people management practices. You can think to yourself, half hour long one on ones are not long enough for me. And for people who are, who are very chatty and want to do a lot of personal connection in their one on ones. However, for a lot of engineers, half hour long one on ones are too long and you should maybe do a 15 minute one every week or two 15 minute ones every week just to check in. This person on my team just doesn't want to chat for half an hour. This person on my team could easily chat for a full hour. Let me think about how to apply that. When I'm a people manager, which is a simplistic example, I think there's a lot of things like that. I think one thing that I noticed before I was a people manager was how much more I trusted my bosses. When they told me what was going on at the company, they explained, you know, if someone had left My manager would say, hey, this is the context for why that person left. Or when I was dissatisfied with a pay raise, we would talk about where that number had come from and why I wasn't satisfied with it and what my market rate should realistically be and whether I was being paid according to it or not. And all that transparency, I noticed, was really a huge factor in whether I trusted them and whether I wanted to keep working for them. And so I decided that when I started managing people, that was going to be a really big part of my management approach was really full transparency and assuming, you know, you can. If you can handle this job that I'm giving you, you can also handle everything that I know, or more or less everything that I know of the operations of the company and about decisions that are relevant to your position and your livelihood. And if you. I don't like that level of detail, you can tell me, but I've never, in my years of people management had someone say, you're giving me too much information about the company or about my job or about my role. Can I say, just simply to sum up, that one of the keys in a people management is a transparency being transparent with your team members, no matter what managers they are or your team members in general. And so basically, can I say that transparency is key to build a healthy organization? Yeah, certainly. And I think a lot of people managers are hesitant to especially explain, like, say, this last year we had 10% inflation in the US and most companies, 20 in Poland. Okay, well, fair enough. Did most companies In Poland give 20% raises to all their employees? Probably not. Certainly in the U.S. you know, most companies didn't give, across the board, 10% raise to all their employees. And so when you have a situation like that, you're going to have tough conversations with people where they say, what, was my work not good enough? Or was the company not able to afford to keep up with the price of inflation? Should I be worried about the financial health of the company? Should I be worried about my individual performance? What does it mean that you gave me a 5% raise when inflation was 10%? Because that's effectively giving me a pay cut. And I think it's really, really important for managers to be able to have that conversation in a candid way. And I think a lot of managers are afraid to say something like, yeah, the company was not in a position to be able to afford a 10% pay raise across the board either because they're not kind of equipped with the information that they would need to explain what the financial position of the company is, or because they're just afraid that saying anything that isn't unequivocally positive about the health of the company will send everyone into a panic. And I've found that people are much more likely to panic when they have incomplete information. So when you say this is just the way it is, we couldn't give everyone a 10% raise and you stop there. People are much more likely to panic than if you say, okay, let me show you kind of the financials of the company. Let me show you our break even point. We were shooting for this level of profitability at the end of the year. This is kind of the average raise that we gave and this is where that got us. Had we given a 10% raise to everyone, then we would have ended up here instead. We would have missed our goals by this much. And we made the decision as a business that that was not going to be healthy for the long term, for the long term success of the business. And then people are like, oh, okay, they may or may not agree with the decision and a lot of them won't agree with the decision, but at least they'll be like, oh, this isn't because the company is like insolvent and I'm not going to be able to cash a paycheck or because the company is incompetent at financial planning and wasn't able to incorporate inflation into your forecast. It's because you looked at the numbers and you had inputs, you had outputs, you paid attention to what the business was going to look like on paper and in reality, and you made this decision and now you're communicating that decision to me. So I can trust that in the future when you make other decisions, you'll communicate about those as well and I won't be surprised or blindsided by the decisions that the company makes. That makes a huge difference all by itself. People are much more likely to feel valued and also feel stable and not kind of run for the hills at the first sign of trouble if they feel like they're going to get a full explanation and a lot of information about the company. Yeah, thanks for sharing your insight. To be honest, I have a bunch of more questions, but I know that you need to leave soon. Let me then jump straight away to our closing question. I would ask you this general one. What kind of skills product managers should have in general to start working within teams and starting to bring value to the company? So I would answer that in two ways. I think the most important attribute that a product manager needs to have is curiosity. I think if your impulse is to find out why something is the way it is or why people want what they want, that is the most. When I'm interviewing a new or an entry level product manager or someone who hasn't had the title before, that's what I'm looking for. Are you curious? Are you able, are you able to make sense out of things and are you driven to make sense out of things? Does it bother you when you don't know the reason for something? And what that means is that you can build the most important skills for product management, which in my opinion are problem definition and problem solving. So problem definition is the one that people skip. People go straight to problem solving. They're like, give me a problem, I'll figure out the solution to it. I think the most important skill for a product manager is identifying what the problem is in the first place and being able to put really clear parameters around what it is and what it isn't. People are spending too much time doing X. Could mean X needs to be faster. It could mean they shouldn't have to do X at all. It could mean they could be spending the same amount of time on something, but it could be more pleasurable or effective or fun and then it wouldn't be an issue anymore. It could mean the wrong people are doing it and different people should be able to do it instead. There's a lot of problem definition skills and techniques that if properly applied, almost obviate the need for problem solving. Once sometimes you define a problem so well that the problem itself becomes much smaller and becomes much easier to solve. And then I think the problem solving aspect is really in many ways a collaboration skill. So the best PMs don't come to the team with a problem and a fully baked solution. They come to the team with a really exquisitely well defined problem. And then they say, let's think about the tools that we might have to solve this problem. You know, is this an experience problem? Is this a technical problem? Is this a functionality problem? Is this a people problem or a process problem that we could assist in solving via technology? Is this actually a problem that doesn't need any technology to solve and just needs a reframing of some aspect of the platform or the product? There's a lot of what do we do that tends to be better served through teamwork and there's a lot of problem definition that tends to be less well served by doing it by committee. I found that when you try to define the problem by committee, the problem tends to expand. And when you try to solve the problem by committee, you tend to get that collaboration that you really want. So that's my perspective on good pme. Yeah, thanks for your insight and for your time. Basically your answer is all straight to the point. Thank you very much. I really hope that you also enjoyed our today's I did, yeah. Thank you. Awesome. Thank you again and wish you an awesome day. Have a nice year. All right. Thank you so much. Great to meet you. Bye bye. Product Leaders Podcast is brought to you by fireart. 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 simple and make their lives easier. Visit FireArt Studio. Search for 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 fireart, thanks for listening.