 So if everyone's ready, we can start the panel now. So hi, my name is Rachel. I am one of the co-organizers of Junior Dev. And welcome to our panel here. We have a very distinguished guest here with us today. We have Itch, we have Minxi, we have Akina, and we have Alfonso. Yeah, so just to quickly introduce, Itch is a general technologist. He specializes in health care and agri-tech, and he also manages the Group Product Management Singapore, which is a tech community focusing on product managers and owners. We have Minxi, who is the principal product manager with consumer experience at Grav. And she has been helping to shape consumer experience at one of our Southeast Asia's leading decorants. And currently, she's based in Seattle, and she has worked with many talented developers in her eight-year career across consumer and fintech. And she also has learned that with free food and stickers, magic can happen. And also with us, we have Arjuna Ravikuma. She is a lead consultant at ThoughtWorks. She's a tech lead with experience in retail, microfinance, India Stack, and IoT domains. And she's also proficient in facilitating product and design, architecting applications, leading teams to deliver solutions and coaching individuals and teams. She has worked across different technologies, such as .NET, Java, Ruby and Veil's, Golang and Clojure. She's an avid reader, a board game geek, and a coffee addict. And if you wish to follow her on Twitter, it is Arjuna, ARCHA, and AA underscore 88. And also last but not least, we have Alfonso Fiora, he is head of product for travel packages at Air Asia. And he has a master's in science and computer science and an MBA from London Business School. So after a long career in telecommunications, across Europe, he moved to Asia and started a new career in product management, quickly raising through major Southeast Asian multinationals, and now hits all package products at Air Asia, the largest Asian airline outside of China. And so, yeah, it's welcome everybody. We would be, thank you so much for joining us. And so as I will kick off the session with a few questions that no, since we are talking about product development, right? So for a panel, we just want to say, no, could you briefly explain what is product development and how is it different from product management, which is probably what more people hear in the industry. Does Alfonso, do you want to start first? Yeah, sure. Can you guys hear me? Yeah. Okay, well, so I think product development is actually the actual work that mostly done by engineering and sometimes that's a science system to actually develop the actual product. So the app or the website you guys use have been developed by a team of dedicated product specialists, engineers, data analysts, data scientists, right? Versus product management is basically what is more like my role, which is basically understand what type of development will bring value to the product based on business requirement, based on feedback from customer, based on looking at competition and based on experience and understanding of where the business is going and what are the latest trends. So business like product management is more about the definition of the scope of the work and product development is the actual work that takes place to actually make the idea of the product manager reality in the actual app. That's kind of my experience and my idea, but maybe other people in the panel might have a slightly different opinion. Yeah, I think product management, I've heard this two terms used interchangeably before, right? So to me, product management is actually a much bigger scope and product development falls under debt. So it's like a subset. And of course, this concept is applied differently depending on which company you go to, but basically product management refers to the whole life cycle, right? So whereas product development is just a part of it. So if you think about it, product management is about, hey, you know, getting the business justification, you know, doing forecasting and planning, even before you start work on developing the product itself. So that's all that work involved. And then you go to the development process and even post-development process, you know, there's got to be a go-to market, you've got to launch product, you've got to think of how to market it and eventually maintain it. Or, you know, if it takes too much to call the city to maintain, you retire it as well. So I would say to me, product development is sort of one of the small views in which product management covers. Cool. How about itch and Arjuna? And do you have anything else to add to what Minse and Alfonso said? Yeah, I think it's definitely, it's a really good summary of what they've described. So in essence, product management to me is always about the dollar side, right? So what brings in the money? Development is having that dream and then making it a reality. So there are occasions whereby there could be a cause of a conflict whereby product managers are dreaming up for flying pigs, but technology could take around 20 years to reach flying pig status. So it's not really possible. And there is some pushback. So most of the time for full PM teams, they could have a designer at PM and then engineer. I think no one party really should take more authority over the other. It depends on the realm of where they are at. If it comes down to feasibility, to me, the engineer takes precedence. They will make the final call to say go or no go. But if it is a product that is amazing engineering-wise, fully newest specs, and then it doesn't make money, then the PM gets to make the decision to say, it's not making money, kill. So yeah. I think all three of you have covered most of what I had to say, but from the other perspective, like from the perspective of a developer, I completely agree with what Eats said. You have to go like product management and development folks have to go hand in hand. A developer has to understand the priorities of the business and what is the market like and what is the solution that will help us turn things around quickly. And similarly, business has to understand the importance of good technology backing, the importance of a good platform. And they have to go hand in hand to be able to build and deliver a successful product. Yeah, so I think also at the same time, it's only two fields. The designers also need to be brought into the picture as well. So I know straight times they'd say artists are not important and non-essential, but they are a very critical part of how a product gets formed. Right, yeah, I agree also. I've done some product management work. I previously was a QA, so I kind of have been on both sides of the spectrum. And I do agree is that you, the product management kind of there's the captain of the ship in a way to sort of directly where you want to go. But if you want the ship to move that way, you still need everyone else to be doing the rest of the work to maintain the ship and make sure the ship actually moves. So yes, I really agree with all of you. And also, I think this is more for the archer now. So it's like, when you talk about things like product development, making sure that it works, right? So we've gathered questions from the audience. Before, of course, we asked them, what would you like the panel to speak? Some of them actually brought up something about technical debt. So it's like, how do you balance I know, technical debt for say, features that have been built previously and how they integrated into like building new features or building new products? Because I mean, it's like in a company you'll be working with the same pool of engineering resources. So as a tech lead, how do you speak with like product managers to integrate removing technical debt from the cycle? Yeah, that's a great question. So technical debt is like a massive baggage to carry and it's really important to make sure that we pay it back in time. Otherwise, it just accumulates and you pay like a lot of interest over time. So in my experience, typically what I've done is usually when I start like work on a new engagement, I set time with the product folks and we reach an agreement of a certain percentage of time set aside for every sprint or every other sprint where we would spend time clearing up our tech debt. So that means that every other sprint, we'd have like 20% of our time just to clear up tech debt. And this does not just mean we are going to just like, finish off all the tech debt and that's it. But as a part of this effort, we also continuously look at what are the new tech debt that has been introduced. We continuously prioritize it. Maybe something that was really important way long back is no longer that important. So we continuously prioritize things. We classify them into sort of a quadrant, right? Where we talk about what is the effort to clear the tech debt and what is the benefit we get out of it? And we try to get things that give us the most benefit, maybe with the least effort first and then we take things as much as possible. But the first and most important thing is to talk to the product team and the business team to make them understand why it's important to clear off the tech debt. Because without that, we'll never be able to like, get the buy-in to clear it off. And after that conversation, it is on the engineering team and the development team to continuously prioritize it and clear it up. Very cool. So for Edge Minty and Alfonso as product managers, I'm sure you've heard from your own, from the tech leads you've worked with in terms of like technical debt, when you have to balance introducing new features on improvements and new features on new products and then you have the engineers who say like, oh, I found this bug. So how do you strike the balance? Yeah, I will first. I think debt usually happens when you need to go to market fast in a very high velocity environment where you just need to build and ship it. And so it's built in a way that's not sustainable or hard to maintain. So there are scenarios where we already know sometimes that what we're gonna build is troll way, right? It's hacky, it's gonna be a one-time thing and we're gonna revise on it. So then we make sure to get out the tech manager that it's isolated and that we do remove. Otherwise, if in this cases, I think what previous because it was absolutely right, we try to pop time in every sprint. So making sure that the product and engineering owners both understand the trade-off on both product engineering if we accept this debt or not. And then parking time to really look at it sprint on sprint and to either refactor or pay back the debt over time. I think that's the mature way of looking at it. You have to incur it sometimes, but it's how you pay it back. That sets you up for success later. So I have a different philosophy to this as well. So let's just say if we go with MVP, we go with a no-code solution. At the end of the day, like what Mincey is saying, it's gonna be throw away code. I would not allocate any time to deal with it at all. It will just run its course and die. The other item is also, if I'm looking at the bigger picture, my company is gonna be acquired. It gives a shit how much tech that there is. I'm selling off the company, right? Okay, I see I could have like, what the hell is going on? But you know, in the grand scheme of things, if you know down the road, three to six months down the road, it's gonna get acquired by, say, some big-ass corporate company. Why keep the product in a way such that the big-ass corporate companies are not gonna spend effort to develop the product any further and it's gonna die anyways? So this is my really bitter experience from the past. But at the same time, I think for most engineers, they also have the pride whereby they will clear up the debt on their own. So I do think that most of the time I'll try to just let them be. They set up their own schedule and they run their course. I would have new features or user stories that I'll load onto them and then they'll let me know if they can finish it off. I think the other thing is, debt is not necessarily a bad thing. It's like the US. They can have $20 trillion in debt and there's still the richest country in the world. So sometimes it's okay. So it's okay, I want very each day. It's okay if someone is gonna buy it. That's exactly it. I think another way to look at it, it's basically, to me actually, when I hear about this, I find this is one of the perfect examples that tells me that it's very, very important for an organization to be successful, to have product and tech very much at the same level. Because I don't think it works when product reports into tech and I don't think it works if tech reports into product. And I think it's because it's really like this kind of trade-off, right? Like Minzi correctly said, right? It's really about trade-off. And I think I'd like to add on top of what Archana said is that I think it's important to understand the value of what the clean the tech that we bring, right? So I know that sometimes some companies, especially in moments of trouble, they kind of set this kind of metrics of like 10%, 20%. But honestly, I kind of challenge that, right? I wanna really understand what is the value that it's gonna bring? And is it gonna make us faster or are we gonna do it just because we wanna do it? Or just because engineers have a certain kind of, like we said, they are proud of their work, which is great, right? But at the same time, we are here to make money. We are not here to create a fantastic architecture or we are here, like at least in normal businesses, right? Unless you're working for Google with $300 billion in the bank and you can afford to do some things just to make them beautiful, right? But normally 99% of businesses, they really have to compete with a lot of competition. So it's very difficult for a company to justify a certain investment if there is no return on that investment, right? So the idea is really understand what are the trade-offs? What is it that we are gonna pay down the line if we don't fix it? And to be honest, I think in reality, when I look at the experience I had in the past, there has always been much more tech debt than everybody wanted. But at the end of the day, sometimes you have to go down that path just because you have competition, you have a lot of pressure. And this is often time we have to roll in the competitive environment that we're facing in the market. Yeah, absolutely. And I think sometimes it's very hard I need to convince business, right? That, hey, we're gonna start work for two weeks because we need to fix this debt. And if you don't understand tech, you don't understand what has to be done. So I would say as product owners or engineers, if you want to help solve this problem, and help what we've done good is communicating and quantifying in a way where it affects efficiency and hence our business profits. So really putting that dollar value on it, I think that's what product owners have to do as well. So I think to make it a bit more tangible as well, right? It's like the Trace Together app. Previously before Apple and Google open sourced. Now that they've open sourced, will they go with the option to take the open specs or will they go down the path of developing their own? Right, so this is definitely some consideration that I think of tech is discussing. I haven't gone through the full GitHub repo myself, but I know my friends are like, oh, the fast life. Oh, there's open standards already, why are we still wasting time? So, you know, there will be incurred cost to migrate over to open standard as well. So would that be justified and would the product owner want to make that call after sinking in so much money? Interesting that you brought it up. So it's like, you mentioned about things like migrating of technologies, especially for software engineers, since most of the time software engineers usually they have more in touch like know what's the latest technology, like advancements, whether certain things, like example the Apple and Google open sourcing so that governments can use it in the COVID-19 situation, right? So, like for Argentina, isn't it very difficult as a tech lead to bridge the gap between the engineers who are working with and under you and product or other aspects of the tech business, say those in sales and marketing or the UX designers? Is it very difficult for you to bridge the gap? It's definitely a challenge, I'd say, but it's usually because people have come from different places with different contexts and as long as the goals are not aligned, it's always a hard sell. So as an example, as other panelists mentioned, sometimes the business is always chasing the numbers and we have like really strong market pressure and we want to launch new features and deliver stuff. And for whatever reason, we might have chosen a technology stack which might not be as new or cutting edge as the developers would like it and developers and engineers on the team are often quite interested in learning new technology and keeping themselves up to date. And very often I see that as a point of conflict, even though it doesn't really directly involve a conflict because many times business or product teams wouldn't understand what the fuss is all about and developers wouldn't understand why we can't go and trial out a new technology. So oftentimes it's because people come from different contexts and a lot of the times it comes down to sitting down and having a really open talk with people, but many times I have seen that as long as, so as a tech lead, my principle is usually to give certain high level guidelines and boundaries and as long as people operate within that, it's still okay. If you give a choice of three or four technologies to your team and if you're okay with those three, four options, if they are still safe bets and if they chose to go with one of the three or four, it's still okay. It's not too much of a gamble. So they get the experience of choosing what they would like to work out of those four technologies, but still you've chosen something that's maybe relatively safe. The flip side of this is to make sure that you don't kill innovation in your team just by being rigid and strict about what to use, what not to use and just always chasing the goals and numbers. You have to make sure that you don't kill innovation in your team. So as a tech lead, it's really important to balance between the two to make sure your team's learning enough, growing and their career, they are growing in their career while also contributing effectively to the product development. All right, I understand. So yeah, I mean, speaking of the technology stacks, right? I mean, even things like a Kobo is still very much in play with banks. It is a super old technology. So would that be considered tech debt? Probably, right? For most sane people, they should have migrated out the code long ago. So that can be argued. So newer FinTech banks like Monzo, they're fully building it on Golang, which is great. It's fast, it's got the speed and efficiency of Kobo and Seacode. So I think in that aspect, how the company grows and how they grow out the product is as important as the tech stack. And over time, it will be legacy. It will be old, but it will still work. So it's also very important to gauge what is considered tech debt in that regard. Is all the technology stack considered a tech debt? In my view, probably not. It was to work. I think it depends on the context, right? It's just exactly like what you said. So if it's a product that's going to be sold or if it's a product that's going to, that we are not going to add any features to, it's just going to stay there like a piece of furniture, then we'd probably not change it at all. We've not upgraded. We let like the sleeping dogs lie. But usually in my experience, there's a couple of things. One is more and more companies are beginning to realize that technology is also an asset to the organization. So it's not just what buildings you own and what vehicles or resources you own. Technology is also becoming a part of the assets. So when you sell the technology that you own, actually becomes a huge part of the deal, right? The negotiation, like do you own a platform? Do you have like an open source platform? Do you own like an in-house platform? Is it like in a plug and play model? Can it be extended? All those questions come into play. The second question is, so in my experience, I worked 11 years as a software developer. And in my experience, I have not met like a single client who said, you know what, this platform, you're done with it. We don't want to enhance it anymore. We're going to throw it away. Let's build something from scratch. Everybody almost always wants to enhance the existing platform. So that's why the question of tech debt becomes really important because nobody really thinks of their platform as something. Like in very rare cases, they think of it as throwaway, but it's really in early stages. If you've invested two or three years into a product or a platform, then there's like very low chance that you're going to throw it away. And that's why it's important to keep it like well-grown, fit and robust. So maybe Akina, I'll just raise a question as well. If there is a legacy product, take for instance, Lotus Notes, all right, wouldn't it make sense to even bother clearing out the tech debt or just build futures on top? Right, so it depends on where your business is heading. So let's say you have a solution built on top of Lotus Notes, and it's something that you want to continue keeping alive and delivering new features too, but it's also not scalable and you're not able to like add more users. You like just struggling to meet with your competition. Then we would talk about how we can migrate features from the Lotus Notes setup to some new setup while keeping both things alive at the same time. And it's like a really complicated process. So what people compare this, the analogy is like performing a heart surgery when the patient is still alive and awake, right? It's like that, right? You're moving like an existing business, you're transplanting it. But if it's something, in some cases, it's like the business has decided that they want to change their business model. They want to try something completely new. In that case, there is no point in like replacing the old one at all. You just like invest in building a new one and then you just like decommission the old one. So I guess it depends on the context. Okay, Alfonso, do you have anything to add? I think it's, basically, I think there were made, they were very good example made of edge cases of situation which are a bit extreme, right? And there is also the situation of the opposite, right? I know of businesses that have failed just because they refocused on changing their technology stack and they kind of lost touch with the market and lost touch with what actually was going on, right? With the competition. So it's everything, right? I mean, it's never, nothing is ever black or white, right? It's always a scale of gray. And now you have to really realize what's the right answer for your particular business, for your particular situation. You know, in my past, for example, we had a situation where we had to kind of build, rebuild a new technology and new stack and it was very painful. I mean, the business owner were very much, you know, not like Minzi was saying, right? You know, it's difficult for them to understand what is it really there? They want to have numbers. So you have to come up with certain ideas of what can be, what would be the results of this change, but you don't really know. And so you just have experience that tells you that, you know, for example, a very fast performing page will actually have better conversion, let's say, for example, of a slow converting page. But at the end of the day, right? You basically still face all these issues of convincing all the stakeholders to actually allow you that kind of two, three months, because sometimes when even a small rebuild kind of costs a lot of time, right? So I think, again, what Chana said is correct, right? You know, you have to find a way to bring those two things at the same time, kind of leave like the old one alive and maybe being able to kind of do a short, a simple MVP to show that the performance and the potential of the new technology and moving it on a little bit at the time. So I think as in many, many things in product management and in product in general, I think one of the big skills when we talk about technology and technology cost stack is how can we make this smaller, right? Now we can probably have a conversation for the next two hours about the meaning of minimum viable product, moving it to minimum lovable product. We have like a lot of like a thousand articles being written on these arguments, right? So hopefully we're not gonna go down that path. But I mean at the very high level, right? The logic goes that what can you do to move to something else without rebuilding the entire castle from the foundation all the way to the pinnacle and the flag at the top of the pole, right? What can you do to make something move to the new technology without having to pause the entire business for six months or one year because that would be a cost that the business would not be able to pay and would more likely fell off the cliff compared to competition. Customers would not understand why nothing is changing for so long and why their needs are not answered for so long. And so eventually the business will pay a big price, right? Yeah, that's true. Rinsu, anything else to add? Yeah, I think the other partners have really covered this topic quite well. I mean, I would say, you know, tech steps. Does trends come and go, right? I would say they're trends. And the same way I look at design trends as well, you know, like you have different navigation principles introduced by the OSS like time and time again. It doesn't mean that if it's trending, it's working. Like you got to figure out really what's best for your company and your business, right? So I mean, look at the whole react-native thing for a while, you know, I was going into it and then Facebook did a major turn around. They have a very good blog post on it. So, you know, we went through a menu version of it ourselves and I've also been in that position where we had to, you know, re-architect an app from the entire all over again and re-wrote it in Kotlin. Afterwards, you know, we really looked back and said, hey, you know, what's it worth it? Right? So I think it's really, you know, regardless of trends and what comes out, it's really figuring out, hey, at the moment in time for your business and your audience and, you know, where you're hated is that the best option. Right. And if I can add something that means to your mind to me, right, is it's a comment that I've heard from a fellow problem manager a couple of years back and I think it's actually very apt when we talk about technologies, right? And she said to me, you know what I do? At the beginning, I was like, you know, a blue-eyed product manager always want to make everybody happy, always thought that it would possible, it would be possible to make everyone happy, which is actually the first, you know, life lesson of a product manager. Everyone will hate you, no matter what you do. And basically she said like, at the beginning, you know, when my tech team, my engineers, my developer would come and ask me about new technology, I would always be like, oh yeah, yeah, we can, because of course they would always sell it like the next thing from sliced bread, right? So we'd be like, oh, this would be so of all our problem, it would be so much faster. And then basically she did it a couple of times and she quickly realized the price, means she was mentioning, for example, with React Native, right? And so basically she came up with this kind of mental algorithm, which I think is actually quite interesting and quite, I mean, it's probably whatever the product manager applies, but she made it out, she said it out loud, which is like, you know, never be the first, never be the last, right? Because being the first to move to something new, you're gonna pay all the price and you're gonna be the one like finding all the problem and all the pitfalls. If you're the last, you're gonna pay all the price of not having support and having few people to help you out in a certain things, just be snuggle in the middle with a big chunk of people moving from one thing to the next and then you're kind of in a safe place, right? That's kind of the way she put it and I think it's actually very smart. But I would think that that is definitely for more incumbent industries. If you're in cutting edge industries, it may not be a luxury that you can afford. It might need to push the envelope or more cutting edge technologies in my view. John, I completely agree, right? I mean, if you hear like, I think that there is a very famous quote for product managers from Marty Kagan, right? And he said that, you know, if you only use your engineer to code, you use only half of their capacity, right? Which I think is very true and it's amazing. Like, I don't know if you see, for example, certain technology that was developed by Airbnb when they had some technological problem that nobody had solved before, or I mean, of course, the Googles and the Facebook of the world, but even Airbnb developed some new frameworks that were not available because nobody has ever faced those problem and probably nobody in Silicon Valley has ever faced a problem. Because I don't think that Airbnb faced any problem different than all the, you know, Agodas or Booking.com or Trip.com of the world, right? But because they were the first one of this kind in Silicon Valley, probably they kind of also had a different approach to it. And it's true that you're totally right, right? They really build new ideas, new technology, new frameworks that were not available before. So I'm sure depending on where you are in the basically the lifetime of your product, the lifetime of your competition, you can always do something more, right? It's just about, you know, is it a company or is it a product that is like you said, right? Is it trying to be on the cutting edge of technology or is it more of a product that is trying to answer a specific need of a customer in the cheapest possible way to maximize return for investors? And then you simply want to be a little bit more safe with your technology solutions. Thanks so much for sharing everyone. So Zaheer, we've actually have a few questions that are coming up on Pigeon Hole. So, pardon me, I'm just trying to... You're looking at a top voted question and now I have to see you guys have some questions. Oh, it's a product owner one. That one I'm really happy with, yeah. Yeah, okay. So Zaheer, we have a few questions that we would probably do, the one that Jenna has asked. So since technical capability or understanding is the concern for PM and engineering teams to come together to an agreement on the development process, do you see a possibility of a merged role? For example, like PM and software engineer combined? I would actually challenge the premise of this question, right? I don't think it's true that the product manager is particularly worried about the technical means, right? The mantra is that the product manager talks about the what and the engineering manager talks about the how, right? So I honestly don't believe, in fact, actually, I think the product manager role should be split in five different roles because it's so much work, right? So definitely I'm not gonna take any more work on top of that, right? I don't think it's realistic, right? So, I mean, it doesn't make any sense, right? It's so much time, so much skills different. Of course, I'm sure that there are some unicorns which are able to do multiple things, like for example, where I work, the CTO that was just a colleague was just moving to the CTO role and it used to be a head of product, right? So that's clearly like a talented person that has both product and technology abilities, but I don't think I met that many people that would be capable to do those things. So I don't really believe that this is a good idea from my perspective. So I think from my point of view is that there are technical PMs. They have a much better ability to discuss with engineers the type of technologies, type of technology stack, architecture. Coding-wise, I haven't seen the guys who can really do it that well for a technical PM but they're able to speak the same lingo. Minimally, they can open up terminal and look like a legit programmer, right? That being said, I think it's also trends. So maybe a few years ago, data science was the big thing, right? Everybody rushed into it. They all knew how to code in Python and R and then R has kind of died down. Now everybody's in Python. Now with product management, it's kind of picked up hype and steam and in the Gatner curve, there's a lot more hype around it and just waiting for people to die off. I think at the end of the day, depending on whether you're looking at it from a career perspective or from an individual standpoint to come out to do your own company and your own startup, it doesn't hurt to pick up new skills. It doesn't hurt to learn new things and increase and scale up in different areas. But at the same time, what the market is going to pay you in terms of the skills? If you are a technical person that is better at doing PM and there are more PM jobs, your tech skills will not be paid. If you are a tech engineer with some PM skills and there's more need for engineers, your PM skills may not be paid because of market conditions. So unless market conditions dictate that there's going to be a need for super technical PMs, if not like what Alfonso says, there may not be a shift in that particular job scope or job title. Great. Is there anything to add? Well, I think I've uncovered it well. So I do interact with my, that's actually the same premise as Alfonso. I interact with my engineers the same way in where I'm responsible for articulating the why and what and then I rely on them for the how. And we come into discussion when the how doesn't really meet the why or the what in terms of timelines, et cetera. So, but to what you said, there are already roles that exist like this today where fields that are so specialized and so technical that it would be best to have a PM with that technical expertise and background driving it. So I would say it really depends in on the scope and the field, but there are roles that exist like that today, but generally for the most part, they look after different sites of the equation. Great. Arjun, anything else to add? Yeah. So I think there's like two parts to this question. So the first part is for developers and engineers to be successful in whatever they're trying to implement, they have to understand the business and the product side of things. They have to understand it. So many times, like when we are coding and we don't know what's the right name to give to a variable or a service or anything, we actually ask the product managers, what do you talk about this as, what is this used for? And we try to make sure that we use the business terms to define our variables in our code. So that everybody, the engineering team product and everybody's talking the same language and they're talking about the product as one. So that's one part. The flip side, I think, and might be slightly controversial is that I think it is helpful for product folks to understand like the really bare building blocks of technology. So you don't have to be able to code. I think it's okay. But you know, to understand what the service is and what the front end is and what an API call is, because that way you'll be able to understand the cost of making changes, right? If you want to push something new to production and you understand, okay, it's a change in the service. So it's slightly more costly or we have to upgrade the app version. So it's more expensive or it is a database call. So it might take a slightly longer time. I think that understanding also helps and it's useful. But I don't think it's mandatory. Like I've seen VMs slowly pick this up and if they have that understanding it's definitely very useful. Yeah. I will add to that and say that. So the example I was going to bring up was Stripe, right? So Stripe is a very engineering outlet company and actually they are lead engineers take on the role of PMs, right? I think they only started hiring PMs in the last year or so. So you talk to them, you know, they are like, looking at distance cases, they are like figuring out which direction, what tag to build next, which product feature to build next, right? And some of them, you know, if I look at that, wow, that's a super power, right? Because it can do everything. But it doesn't mean that they're happy doing that, right? It's a, some of them are like, hey, this is not the role I signed up for because product management also requires a whole different set of skills, right? Stickholder management, you got to, you know, influence. So it's, I mean, I think those roles do exist, but it's about whether you see yourself fitting into that. Right, thanks so much for answering this question. So we will, we'll be moving on to a question that was asked by Anonymous, which might be a bit controversial for the PMs. Very controversial, yeah. Very normal. So the question by Anonymous is, what can I do if my product owner is not performing well? For example, not forgiving unclear or shifting requirements and not articulating a vision. And I think it also, in a way, it ties in with a separate question that the different Anonymous has posted, which is like, what should the skills that a developer, what kind of skills does a developer need to know when communicating with product managers? So I'll just combine these two questions together into one and then whoever is ready to answer can just speak first. Yeah, I'll take the first one. I think this is quite straightforward, right? And it may be hard, but to me, whether your product owner is not performing well, whether engineering manager, whether your peer is not performing well, the approach is the same, right? It's to give them honest and active feedback. So we're all humans and we're all learning and the only way to improve and better ourselves is to know from someone else. So in this case, it's just a matter of sitting down if you're a PM 101 and saying, hey, I'll just calling them out for it, right? And saying that, hey, this has shifted or you keep changing or you keep adding new scope, it's not gonna work well or I don't see where this product is going. Can you share with me the roadmap and vision? Put the owners on them to resolve that because that's their job. So I will really emphasize this because I'm only as good as the engineering managers I've worked with, right? And they have sat down with me and they have pushed me and they have given product feedback and it helped me to think about things from a different perspective and different path and in that way really, you know, really honed my expertise as well. So, you know, this is the best favor that you can do for them and for yourself. So I would say just, you know, really being very transparent with your feedback. Well, I think a PO versus a PM, especially with regard to, this sounds like something out of the government in my view, all right? So I don't know who the hell anonymous is. I think it's best safe to keep it anonymous, but no. And the PO in itself, especially for bigger organizations that I've been through, most of the time control the budget to pay for the whole team. They are the client. And yes, there are times that they seem like incompetent people. And if given a choice, Mr. or Mrs. Anonymous, if you don't need to work for the client, time to go because it could be very difficult and very frustrating in the long run. The other thing that could be done is of course to force, prioritize features and backlog. Because a lot, like at least from my experience, a lot of times these folks come from a waterfall implementation. The way they run agile is rapid for lack of a better word, right? That is the best they can do. And there's no fault in that, especially in healthcare, I think I would still prefer a waterfall approach whereby things are quite fixed. I know when I'm going to push things in the production. I know what the technology is, I'm very comfortable. And if the PO, like in the case, I think I did this two years ago for the Middle East respiratory syndrome, it was a temporary code that's still sitting in hospitals today. The PO just came up to us like, we needed two days ago, right? What do you expect me to do, right? So it does happen that they don't have clear or shifting requirements because their bosses are also unclear and shifting. And it's just trickling down from the top. And in cases like that, one, running a workshop to align everybody once a month could be useful to make sure everybody speaks the same lingo like what Archana was saying. Everybody has the same context. Everybody has the same lingo. Everybody understands the same word the same way, right? There's no ambiguity as to what is being asked for. That is extremely important in these cases because the unclear or shifting requirements could just essentially be the same thing, but in different words. And that causes a lot of confusion. And if, like I'm taking this as a PO and not the PM and I agree with Minzy, if there is some conflict within the team for the PM, the designer and the engineer, there's weekly retros for most teams. And that should be brought up in a safe environment to discuss it openly. But the PO may or may not attend these retros all the time. And if this is the case, I think it would be advisable for the PM to have a comfortable coffee session in a safe environment. The book I would strongly recommend is something called Crucial Accountability. I think that has helped me and it was recommended to me by my mentor. It's been very useful to build a safe space to discuss very uncomfortable topics, especially when it comes down to the PO not taking charge of what they're supposed to do. Right, right, yeah. I think for Alfonso and Archana, right, since Alfonso you have been a software engineer previously and Archana you're still being a tech lead. And so it's like, what kind of advice would you give like to the junior devs in the audience? Yeah, so I actually wanted to cover that part of the question when you said that you wanted to kind of merge the two, right? I think one challenge is that obviously problem managers and engineers and developers are hired for different skills naturally because they do different jobs. And so naturally problem managers are a bit better at explaining their arguments or their opinions. And in my experience for certain engineer that could be a little bit sometimes challenging. And so definitely I think it's important for engineers to really, you know, try to make clear exactly what their point is. So I totally agree with what was said earlier. Give direct feedback, try as much as possible not to kind of have a public scene and just try to kind of directly talk to the problem manager. And but I would say like every story is a little bit different, right? Now, if you allow me to quote, like to miss quote actually Anna Karenina, right? All happy product managers are happy in the same way but each unhappy product manager is unhappy in his or her own particular way, right? So what I'm trying to say here is that there could be million reasons why you see shifting priorities because the most common reason is that to be honest, we talk about product management. As we said, it's really a hype title nowadays but in reality, in my own experience for in large companies, I've worked in a few, I only work in a single company that I could really say it's a product driven organization, right? So a lot of time, you know, there are companies where you have a lot of stakeholders sometimes behind the scene sometimes they're kind of like gray in the background and then they pop up at a certain point just to dictate what they want from a product even though you never even knew that they were there. And so basically sometimes the product manager against his or her will, right? They have to kind of make last minutes change because they are not really in control. If you talk about a product driven organization, then the product manager is really accountable for his or her own KPIs and really drives the product forward. But a lot of times, you know, we pay lip service to product management but in reality, we have all sorts of business leader, business manager, product marketing managers, all sorts of weird, strange other roles that seem to be or believe to be accountable as well for business KPIs. And so it becomes very difficult for the product manager to really have a clear unified vision and really bring the product forward. So I think this is also part of the problem and, you know, let's be honest. So I think the audio is a bit choppy on your end. Oh, sorry. Can you hear me now? Yeah. Yeah. So yeah. So anyway, so what I was trying to say is that there are many, many reasons why this can happen. And sometimes, like Minzi was saying, right, we are all humans, we really need to learn. But in terms of like the development, in terms of the developer, right, it's really important, I think, to try to be as clear as possible and to have, like we said in previous points that we discussed, right, trying to really bring it back to the return on investment, to the impact to the product, because for the product manager, it's gonna be really difficult to understand, or, you know, you have to, you know, like if we tie it back to other answers, right, when we talk about product debt, that kind of stuff, right, it's gonna be difficult for the product manager to understand, you know, what's the impact, so what, right? So as we mentioned in other questions, in other answers that we had previously, I think the most important thing from a developer perspective is try the best you can, as much as you can, to speak the language of the product manager so that the product manager can really understand why you're concerned and how can you, you know, how can he or she incorporate your feedback into the roadmap? Because at the end of the day, the product manager just wants what's best for the product, given the feedback, given the business KPIs and given the feedback also from the engineers, right? So unless you're really working with a social part and then I'm really sorry for that, but ideally, the feedback you get will be heard and will be improving the product that you're working on. Thanks for sharing. Archana? I think most of the points have been covered. I just have like a couple of things people can try if giving feedback and other things are not working out. So assuming that the person has the right intentions and the changing or shifting requirements are something that's not in their control, some things that have worked for me in the past are, first, you could try to get like a clear product spec help, which everybody looks at and everybody gives like the verbal agreement to, okay, this looks right, this looks about right, so that at least like the bare bones of the feature that you're building is somewhat agreed upon. And if that's not possible, you could simply start tracking what is the delta, how much is the change that we're talking about. So typically the functionality that you're building would be in like a JIRA card or like somewhere on like JIRA or ASAN or Trello or somewhere. So you start recording every change to that as a separate card. So usually what happens is the functionality gets put into a JIRA card maybe and somebody gives an estimate saying it's a two point or a three point to implement this. And then let's say the requirements are changing or something changes, you don't do it as a part of the same card. You record it separately, estimate it for it separately, so that when you do a retrospective, you will be able to retrospectively look back and see how much is the change and what is the effort that you've lost because of this. So maybe that allows the team to have a conversation about how to make things better and what can be done to avoid this. Maybe that gives the product owner things to think about in terms of cost, okay? This is the developer effort that was lost because of this and maybe there are better ways to do this. Yeah, I really echo that. It's like keep your PM on us, right? So sometimes I'm guilty of it myself. I try to slip stuff in during the stream. My engineers don't let me do it at, you know, digital communicates and we're like, okay, fine. And then that's perfectly fair because we need to protect our renowned chat as well. All right, I see. So, okay, we'll be moving on to the next question. So we have, maybe since you mentioned that product managers and product owners are a bit different, maybe we can just sort of quickly explain this question just to make it clear before we move on to another one. What's the difference between a product manager versus product owner versus project manager? So sorry, because even for myself when I speak with different companies, I also realize that certain company's definitions are a bit different and then some, the title is A, but the job scope is actually someone else's definition on B and so on and so forth. So maybe we can just briefly explain what are the differences? Yeah, I think, and this is actually the answer right there is that they are definitely used across various companies, right, from Microsoft to Google to Facebook to Grab or to wherever it is. I think they all have their own definitions of what product is in these companies and different roles to fulfill on that, right? So for example, the Grab role in product, you know, the, sorry, the Grab product role is, there's also a TPM, there's also a product marketing person, there's product analytics and all of that together is sort of make up product management. So different companies break this up in different ways. So I've been, I'll try to tackle this. I've been both on a product management side and also a technical program manager side. Conventionally, the difference between the two is that, you know, a product manager really does all of this, you know, that we're talking about, right, looks at product KPIs and performance, you know, you know, ship's features to improve that data and bring business value. Whereas a technical project or program manager looks more at meeting the timeline. So coordinating between teams in a very big company, like they're not responsible for the metrics or the success, right? You know, it's like, as long as you meet the deadline, the product fails, that's on the product manager. But the project manager really looks at, hey, how do I unblock all these barriers? How do I bring teams together? You know, how do I keep everyone on track and according to the milestones that were identified? So at the core, there's a difference between a product manager and a project manager. And I know this is really confusing. A lot of our engineers ask all the time, what's the difference between the work that we do? But the product person really looks at overall success, whereas the project manager tracks to a delivery given deadlines. And as for, you know, between a product manager and product owner, again, use interchangeably in different places. The most, the usual distinction is that, you know, in companies where they say you are a product owner, you actually do have control or ownership of the PNL, right? So the business side of the product, whereas in product management and conventional, you know, you have some direct impact to some metrics, but you don't actually own the PNL and being able to, you know, play around with the numbers or the revenue it costs as you will. So that's the difference that I've seen so far. Anything else to add from the rest of the panel? Maybe echo what means to say that. And I feel like there are as many definitions are there are companies under the sun. And I know for example, a company that one day decided that all their product owner would then next morning be called product managers. So honestly, I think it's, I think you should be more, you as in you a potential person that is joining the company, you should be more concerned about what is the definition for the company you're about to join rather than kind of understanding an overarching difference with two roles because many companies treat those words, those names interchangeably. Many company change their definition and many company use the same word for to mean different things. Great. Yeah, so I think for project management, it is quite clear cut. So there is a project management institute and you can get a nice PMP title by paying a certain amount of money and taking the crappy test, right? So you can put it at the end of your name. So that's, I think that's definitely quite clear cut. Deuze of time, finance as well as a resource and scope. PMYs like product management wise, I think the terminology in itself is not as important like Alfonso says, it really boils down to the culture of the company and how they run it. Because if they can't even agree upon something as simple as say how you define agile, it just becomes quite tough, right? And how they run the backlog. Yeah, I think there has been cases whereby some corporates because they want to go agile. And then they're like, okay, everybody just becomes a product manager. And then after that, okay, functional specs are now be cut into user stories, right? Why? But it's still gonna be delivered and then repackaged into a functional spec again. So to me, that is just insanity. Like, you know, have some respect as to what the original philosophy was meant for and then stick to your guns. If you think waterfall is great, yeah, it's okay. It will still run, right? But I think there's certain upper management or senior managers that feel that, okay, I need to take the new management flavor of the day and then turn this out as the new culture. And I think that's very, very dangerous. Right, okay, if there's nothing else to add, we can move on to the last few questions. So now that we've already defined what like a difference between product manager, product owner and project manager, right? So we would also, for those who are like tuning in and are curious, right, we can, some of them have also asked, I know, how do you become a product manager? Should product managers come up through the engineering side or the business side? Because for a lot of the fan companies, so for those who don't know, FANG stands for Facebook, Amazon, Apple, Netflix and Google. So these are the tech giants. Usually a lot of those who become product managers, they usually start off with like an MBA. But then cause a lot of us, a lot of the audience here are junior developers. So all very curious is like, if let's say I start off as a software engineer, should I continue this path towards becoming a PM or should I study something business related and then become a PM? So I think there are a lot of boot camps whereby after three months, you become a PM. Of course, I don't really agree with that sense right on that route. It's just like, if you want to become a CEO, you can pay Acura 300 bucks, register a company and you're instantly a CEO. So the term in itself is not important, but the ability to deliver on the skillset is. So what does it entail to become a product manager? Especially for the organization that you tend to join. And I think a lot of the younger folks that I've spoken to is that they'll say, oh, there's this requirement, I need to have five years of product management experience, but if I can't even become a product manager, how do I get five years? My general advice is to find somebody to mentor you for two reasons. One, they can guide you through all the jogging that's required, all the things to say in the interview if you do end up getting the interview. Secondly, they would be able to open the doors and connect you with their network of product managers to allow you to bridge the gap to get into the job because there will be certain product management roles which are a bit more junior that is looking out for cheaper labor. It sounds crap, but that is the case. There will be companies or startups that have a tighter budget like, okay, we'll just try this guy. And it'll be fine, right? Just learn as you go. I think that's the important thing. Fonso, Minsu or Akhna? Yeah, so I would ask, so. I think we're both like, why would you want to do that? Yeah, exactly. Why are you going to be a product manager? I asked you that question, right? I mean, you don't have to hate yourself like we hate ourselves, right? So you can, you can... That's a better idea. You can have a happy life and just deliver every week without having to do 20 things at once at all times. So, I think, I mean, this is product management. I don't know what's going to happen in 10 or 20 years, but today there is no school for product management. There's a lot of people that try to sell your school for product manager, but I don't actually believe that that's kind of what it takes. I am kind of the quintessential, I don't know, maybe I'm not the right person to comment because my career has been like the most typical one for product management is computer science masters and then an MBA, so it's pretty straightforward. But I didn't think about it that way, right? The way I learned how to be a product manager was really because I had the opportunity when I went back to school for my MBA to actually work with a lot of startups and really try to do stuff myself. And that's really, and be really involved with the startup ecosystem in London going to a lot of meetups, meeting a lot of founders, work with them for free during my studies as an intern, like you were suggesting. And so basically, these are really the way you learn on the streets, right? Because it's not something which today at least there is a really proper school for. But again, I would really question why is it that it's something that, because it's super fun, I wouldn't change it for any other job, but it's also very stressful and you don't switch off. It's not like it's 7 p.m. and going home, right? It's something where you're always on, where oftentimes you work in meetings and weekends. It's, if that's your calling, if that's what you enjoy, by all means go for it and have a blast. But really be sure for what you wish for, right? Because you might get it. Yeah, I mean, I thought that right. So I think questioning your motivations are really important. Let me speak to a therapist if you need to. But no, I think sometimes it's glamorous to gather people what we do, right? Because we're doing presentations, and we have metrics, but there is a whole wall of pain that comes with it. So really understanding the role first, understanding what the expects of it and deciding whether it's for you, right? Personality wise, it skills wise as well. And you know, if you're really interested in it then, I think the best way to learn it's really on the job itself. I think there are really actually academic degrees for product management now. They spin those up very fast. But if you are a radio software engineer today, you're already in the right place, right? And you already set up for success in that you have interactions with PMs around you. So go talk to them. Go try to get no more of that work and make it known within your company and see if there's a chance for you to transition from there. I know we've had people in grab engineers who transitioned to product managers and we've supported them. So just really going out there and talking to your fellow PMs, trying to help them. And I think each point by getting mentors is great as well. And then putting your hand out. And then really the only way to learn is just on the job itself. And a lot of what other people do when they try to get into a junior PM role, right? Which is, you know, even if it's a boot camp, you know, at least it shows that, hey, you got to see us about it. But reading up the same books, you know, doing the same interviews in order to get into the role. Yeah, and if I can add something practical, I think echoing what Minzi just said, right? There was something that I read a few weeks back which kind of came to mind when I was listening to Minzi. And this is basically a general advice, not just related to product manager, but related to any time we want to do like a different work, right? And if you have the chance to access those people that are already doing that work, it would be like, you know, tell me, go to them and ask, tell me what's the 20% of your job that you really hate and take it upon yourself to help them. That would clearly really like a path to success because everyone I'm sure has a part of their job that they really don't like. And to be able to have said it, basically you win two things, right? You win the, basically the reconnaissance of that work of the help you did to that person and they will try to help you back, of course, as much as they can, but also at the same time, you will win that you already know what's the worst part of the job. So you know exactly if that's for you and if you can do the worst part, then everything else is an upside, right? So that maybe is a very practical approach to kind of get down that path. If you work in an organization with their product manager, trust me, one thing that I can tell you for sure is that product manager will have some extra work. So this is something that they can offset to you. And then if you improve that you're gonna deliver on time for what you promise, then that would, I would say it clearly clears a path because the moment like Minci was saying, the moment there is an opportunity, a role for a product manager, for a junior product manager and the company, if a more senior person says, you know, I think we should give this opportunity to this guy and he's been helping me a lot lately and I think he can do it, that counts like a hundred points, right? So definitely, that would be a great way to do that. And actually, since we were on the topic of helping current PMs, I know due to 20% that they don't like, right? So someone anonymous actually asked, what do you dislike most about being a PM? Where does that now? I think that one thing that becomes, one thing that I'm definitely not good at that I can definitely, I wish I could learn and that's why one reason why I don't really like so much as to do it is kind of a lot of time, right? Let's be honest, there is, as we said correctly earlier, right? There is a lot of stakeholders, especially in a non-product-driven organization, right? Where there are business stakeholder, where there are other stakeholders, right? And a lot of time, a problem manager has to kind of prove like that the sun rises on the east, right? And that's something that really, really like kills me inside, right? For example, when I argue that, hey, you know, we should make this page faster because it's gonna increase the victory. And when you say like, prove it to me, I was like, oh, okay, fine. But basically, that's something that has been proven in e-commerce for 20 years, right? And so maybe this is something that I'm not particularly happy with when I have to really, when my insights, my basically experience talking to customer, my understanding of competition is not enough for me to create a roadmap and I need to somehow please a third party with some sort of invented statistics to show that that's exactly the first thing that we should do. That's something that I, that's one part of the job that I don't really find exciting. I feel like it should be, you know, I really enjoy the part when I have to understand the customer needs. I have to work with user research. I have to make sure that the research is not like putting my answer in the mouth of the customer. And those are really things that I think it takes a lot of like attention to detail. But when it comes to like, you know, tell me exactly what this thing is gonna have an impact in the next six months. I haven't found yet someone that could really come up with a proper way of formula and then hit the target consistently, right? So that's something that I really don't enjoy about product management. Yeah, I think I called, oh, sorry, Juan. No, no, no, go ahead. Yeah, I think I called at, don't get me wrong guys, I love my job. That's why I'm doing it. I mean, despite everything, it proves that I'm not the case who loves pain. But, you know, oftentimes there's no right answer in this world, right? You can run your experiments and at different times you will get different results. So you go with one based on data, based on your experience, but then you have to defend it with your soul, right? So depending on the company's tolerance for failure, that could or could not work out well. Also, it's contrary, right? You know, when you are a product manager, your key job is fully stakeholder management, right? How do you manage different opinions? How do you influence? How do you convince? And that can get really tiring and sort of sometimes distracting you from creating impact, right? When all you wanna do is to focus on users and ship good stuff, but hey, and you know this as you go up to a certain level, you know, in management, sometimes it's just about managing egos in the room and the loudest voice, right? So if you are in a situation where there's too many cooks in the room, I think that can get a little bit tiring as a PM. All right. How about it? Not a PM. I don't have that on my title at all. But I mean, to me, dislike or like, it's like having a spouse or a girlfriend or a boyfriend, right? There will not be 100% whereby you would like or dislike the person. It is a choice that you have made. I think it is a choice that you will commit to. If at some point of time it doesn't make sense anymore, there's of course the ability to exit or divorce. So that's my take on it. I find a poison you're willing to eat, right? I think that's what they say. I'm sorry? It's like, what are you, what's the pain that you're willing to eat every day to put up with, to prepare? I think that's the same for that. Yeah, so the other analogy is of course boiling the frog. So most of the PMs are just stuck in the pot being boiled. What was I doing saying? I know which shit sandwich are you willing to eat? Oh, yeah, yeah, I think. Okay, so we'll be moving on to the final two questions for tonight. And so it's that we talked about what you know, what is probably like not the most favourite part of the job. But we also want to take a look at what makes a good PM and what are some failures, and what makes a bad PM. What are failure modes? What do you mean by that? So it's like, I think maybe to rephrase the question, it's what, like, how can a, in what way will make a PM a failure and what makes a PM a good PM? It's two different questions, but so I would say I would start by taking it a little bit like from a wider angle, right? From a different perspective, right? Basically, it is said that there are more entrepreneurs in the United States compared to Germany, because if you bankrupt in Germany, then you're in big trouble. If you bankrupt in Silicon Valley, then you're a fantastic success and you're ready to start over again, right? So I would say this is probably true also for product managers, right? It takes a lot of experience, a good amount of luck and a smart eye to distinguish a product manager who failed and learned from a product manager who failed and will fail again, right? And I would say if you have that amount of ability to distinguish between the two, then you're a great CEO or a great CPO or whatever is the role. And then you definitely have to select for those product manager that fail and learn, right? I never quite understood how would you basically, one way that I look at it is like, oh, imagine for example, and this happened in every company, right? It happened in every single company I work with where you have some major mess up and maybe for example you didn't require payment for a while or something like that and those things happen incredibly in incredible amount of time, right? It's quite shocking how often those things happen, right? And then I feel like, okay, you let this guy go and for sure this guy will never make this mistake again, so you paid the money to make him learn the lesson and you let him go so that he will apply that lesson somewhere else. So that's kind of crazy for me. So that I would say definitely every failure if you have the right mindset is definitely a way for you to learn. And I think it really comes down to the company culture but also the work culture. In one of my first jobs back in the day, I actually was kind of the administrator of a bunch of servers that were used to send SMS between mobile phone back when SMS was still in vogue, right? And this kind of funny story happened that I was there as an intern and my boss was on a business trip and so somebody, a developer came to me and said, hey, I need more space on the servers and then it's a long story but I'll try to make it very short. Long story short, I wiped down the entire test lab, right? Of Nokia, which is not exactly a small company, right? And so for like a few days, the entire development team for SMS was stopped, right? They couldn't work. And I remember when my boss came back, I was obviously, I was terrified, right? And I explained what happened and he said, well, there was no way for you to know because the software was not developed enough to give me a warning. So just don't make the same mistake. That's it. And that was the whole the problem I got from that. And I can promise you that never happened again and I made other mistakes, but definitely not that mistake, right? And so to me, this is kind of an important thing, right? You have to have the culture that allows for mistakes and allows you to own those mistakes and more importantly, share those mistakes, right? One other thing that I really don't understand is how certain company keep those mistakes. They don't wanna share them within the company because they're afraid that they will become public. That I understand, but at the same time, you will run the risk that another PM will actually do the same mistake. So what we're doing, for example, what I'm trying to introduce in the company that I work with is we're basically prime manager, share their mistakes, right? And I think this is a super powerful thing when you do it inside the company because I think you really learn. And in Silicon Valley, I remember I went when I lived there, I remember I went to a failed something, there was a failed conference, right? Where people were- Oh, back up nights. Sorry? Back up nights. Yeah, no, I think it was kind of called failed something. And it was a conference about all possible failure and I thought there was genius, right? Because it takes a lot of guts to talk about your failure but you can learn so much more, right? I'm not gonna learn much if you say how smart you are, how good you are and how much you got everything right. Because first of all, I know that that's not the real story and second, because there is nothing to learn, right? The second part, what qualities make a good PM? I would say, I mean, definitely you have to be very analytical. You have to be good with numbers, you have to be outspoken, you have to be willing to fight for what you think is right. You have to be a step, definitely you have to be stubborn but you also have to be smart enough to learn when to change your mind, right? So it's kind of that particular kind of thin line where you have to protect your ideas but also in Silicon Valley, they call it like, there is an expression for that, now it's allude me but basically what they're trying to capture is that you have to be very strong with your opinion, very opinionated. As soon as you see evidence of the opposite, you also have to change your mind very rapidly, right? So you have to be very evident-based, that's the driven, read about the logic of what it is that you're thinking, bring the logic to the table but then if somebody brings in new data that contradicts what you said, verify the data and that data is correct, that you have to be ready to change your mind. A lot of people say they have this expression of check your ego at the door, I don't know how easy it is but kind of the idea, it's kind of that, right? The idea is that at the end of the day and I think I'm getting better at it for sure like probably in the past, I was probably more attached to my idea and trying to prove myself right, now I'm much less interested about that, I'm much more interested about, okay, what's the right thing for the product and how can we bring everybody and all their experiences together to make whatever is best. And as a last note, right? I think this connects to a lot of other things that we said in the past, right? You, if you wanna be a product manager, if you wanna become useful for the product manager on top of your development skills, then this is definitely something like be factual, bring data and help the product move in the right direction and then you will definitely become more valuable rather than your great value from the development perspective, right? But if you wanna move past that value, this is definitely the path to go. Okay. Anybody has anything else to add? No, I'll quickly, I think I'll come to it. So definitely failure to learn from failures is a failure in itself. But objectively, I mean, for a company, right? As a PM, you feel when you don't need your metrics, right? Are we defined by our metrics and the impact that we deliver? That's a door onto the second question. No, I've seen PMs who meet their metrics at the expense of others. And I've also seen PMs who meet their metrics with others, I think what I mean. So I think we all have subjective opinions of good PMs, right? The ones that I really enjoy working with are those that have a very strong product vision and they know how to get there. Who can belly teams around them and build trust and confidence in their stakeholders who's willing to go to mouth but also having their teams back. So I think those are all very strong leadership qualities that enable you to become a good product manager. Like, I mean, there are some people I will rather fail with some people than succeed with others, right? So you have to be that kind of role model for your teams. I think to me personally, diplomacy is something that is extremely important because product manager is still very much in the middle. So you have to manage up, you have to manage down as well as sideways. So the ability to be very diplomatic but also not so politically correct that nobody likes you, right? So I think at one end of the spectrum you might have Trump that nobody likes. And then the other end of the spectrum just sounds like, looks like a brown noser that sucks up to everybody that also nobody likes. So I think what's quite important, at least what I feel is that there has to be a certain amount of authenticity that you bring to the role. People can trust that trust is very important. And at the same time, if like Alfonso says that you build up enough credit, the credibility that that is extremely important capital that you can go and push forward your product at the point what you're trying to do. The diplomacy, like say for instance, to talk to engineering team, to talk to design team, they also need to know and trust the fact that you have their best intentions at heart when talking to stakeholders. If they're not being, if they don't have representation there, you would be the one at the PM to represent them in that particular situation. So I think it is at least in the past experience I've had that has been extremely important to make sure that credit is shared to be diplomatic, to be authentic and to be respectful for everybody, not only the bosses, the folks below doing the work and also the peers. Anything to add? Like maybe like what do you, like from your experience working with like product managers who, what qualities do the best ones have in your opinion? Yeah, I think as like someone who constantly interfaces with product managers and who like it's requirements to be delivered by the developers on the team. I agree with a lot of things that Nin mentioned. Definitely someone who has gained the trust of the team who's able to articulate the vision, who's able to make the team understand why we're building something and what are the trade-offs. And even like when challenged, they are able to justify and articulate why the priorities are the way they are. So the people who we are able to work on work well with and those are the product managers that I've said very well. Also people who can be really tough on the engineering team, but also who have the back of the engineering team when there is trouble. So those are the product managers that people really trust and enjoy working with. Thanks so much for sharing. So we'll just go to the last question. Maybe just like which Inho has asked. So as a final takeaway, is there one thing that you wish all software engineers know about like your product manager or about like product managers as a final takeaway for this? PMs are also human, right? Everybody is there to collect salary at some point. Okay. Minse? Yeah, I don't, it's a tough one. I don't, I mean, again, I can say this, but I'm coming out with good interest, right? I don't know if anyone has to, it's working with someone from the same place, but you know, we all, our goals are to see, right? We want to deliver good products, we want to change user behaviors, and we want to do things that we're proud of. So yeah, I don't think there's one thing I would have to know, but like, you know, it's a tough job and we're all trying to do our best. But yeah, I mean, I think what I would say is also, you know, we all want you to be more involved in the product development process. I think, and that's what I really believe in product development. And every time I hear Bex, opinions, new suggestions, I think that's the most joy a PM can have also when your team is engaged and when you're actively building for the same thing, right? So yeah, if anything, that. Actually, I was thinking exactly along the same line, right? And I was going back to what I said about communication, right? So it's very, very important for, I mean, as Minse said, right? In reality, you know, a product manager should not, I think most of the time, maybe it means that understanding about the product management role is that the product manager is seen as the source of all inspiration, right? That should actually not be the case. And it should be in fact actually just a facilitator, right? Where, you know, it helps kind of put things in perspective, bring some experience, collect the data, ask the right questions, but you shouldn't be the one stop shop for everything that is to change the product, right? And in fact, actually the ability of, you know, collecting the right feedback from data, from user research, from other members of the team, that's really like one thing that the product manager really appreciate. So I think my suggestion is kind of try to find the right way to share more feedback about the product in the right way, in the best possible way. Probably, you know, like spring planning is not exactly the greatest place to be vehemently opposed, but there are other situations in which actually it's very, very good to kind of disagree because idea is to get to the best possible solution. And communication again, meaning that, you know, you have to like the same way as product managers try to kind of understand more and be more productive speaking more of a technological, you know, language and lingo. I think software engineer should really try to be more proficient in speaking in the same language of a product manager so that they both can meet in the middle. So that would be my takeaway. Right, and Alcina? So I'm not really a product manager, so I'm just going to think from the perspective of a software engineer. I think I agree on what Alfonso just said. I think it's really important for, you know, like the product and the tech to coexist because as like if the product teams, if product managers understand what technologies can bring to the table, as soon as they understand what the product is and what they're building, it's like a superpower that's been unleashed and together it's actually really effective. But when there is not a high degree of trust or when information is not shared with engineers, that's when we see a lot of conflicts and a back and forth about what's being built and a lot of like issues and conflicts. So for me as a software engineer, I would like my product managers to be really open and transparent with me and share the product vision and, you know, treat me as a peer so that my ideas are valued and together we build the product together. Right. Okay, thank you so much for sharing. Minsu, itch, Akna and also Alfonso. And so it's really enjoyed the sharing by everyone of you. And I hope everyone else who has tuned in also enjoyed it. So as we've come to the end of the panel, we'd like to thank everyone for taking the time to kick off this week with this panel. And thank you so much. I hope everyone has learned something. I hope the panels also have learned something from each other as well. And I enjoyed it. I hope everyone enjoyed it. Thank you so much for tuning in. Just so you know, this is recorded and it should be uploaded quite soon. So if you want, you can share the link of the video with your peers who have probably missed this. And thank you so much for coming. Hope you enjoy the evening. Good night. Hey everyone, just before you sign off, I have just posted a link to a feedback form in the chat. If you could help us with some feedback. We'll also post it on the meetup and Facebook events so that you have access to it outside of this Zoom meeting. But we'd really appreciate it if you could give us some feedback. Thank you. And thank you. Thank you for having me. Thank you everyone. Bye. Bye. Bye. Bye.