 So I'm Meredith. Hello, I am a product manager. For those of you guys who haven't met me, I've been doing this for a while. Interestingly, someone else just asked me that question and it took me a while to try to recall how many years a product manager. Maybe on off, I would say 15 years. I guess that kind of gives away my age as well, but who cares. Okay, so what I'm going to do today is just to give you guys a bit more information of what we do as product managers. I'm sure a lot of you guys work with them if you're an engineer and you'll probably think that this thing about a product manager like, wow, very busy. This person running up and down, giving me orders. I don't know what this person is doing. So I'm here to clarify a little bit of that and for those people who are thinking about going to a product manager, I hope you consider. It is a, well, as you can tell, I've been doing this for a while. So it must be quite satisfactory, I guess. Although Michael was kind of giving me some insights of what to cover. He said that some people here might be considering a switch to product management and all I could think of was you need to have a high threshold of pain, I think, to some extent. But anyways. Okay, so in theory, product management is pretty much these few activities. Although we do a lot more outside the circle and the job doesn't just stop at the very end. So of course, we start at the very beginning. We do a lot of user research. We are very active in the field talking to customers or doing customer research and then understanding what is it that the customer wants and what is it that we're trying to solve and bring the solution to the customer. In this sense, I'm talking about digital product management. I don't really have any experience in hardware. So I'm just going to cover. And then a big part of my every day, which I'll talk about later, I do product backlog grooming. I enjoy days where I just sit in front of my machine and just look at all the features I want to build and write acceptance criteria. At least so I find a lot of satisfaction writing all your user scenarios for my engineers. And then of course, putting into sprint, running the sprint and agile ceremonies on a daily basis. And then a big part of it is going to market. So going to market is not just launching code, but it's also coordinating with a whole bunch of other people like marketing, legal, tax, finance, compliance, PR and getting the product out to the hands of the customer. But obviously, there are a few ways of doing that and we'll talk about that as well. Lastly, part one of many, which is the data analysis. So after you've launched something, you look at the data, you figure out why is it not working? Why is it working so well? And you go back again and look at your backlog and your groom and you just repeat the whole cycle again. So as a product manager, we don't just stop here and it's a continuous process. I sometimes think that maybe it helps that I'm a mom and I treat the products like my babies and I continuously grow them. So that's one thing to think about as well. So my daily duties, some of this, so stand up, sprint planning. I think most of the time I spend stakeholder management, which is depending on your organization, big or small, you always have stakeholders. And whether it's senior or junior, even engineering is also stakeholder, right? So I spend a lot of time talking to my stakeholders, making sure we over communicate and making sure my team understands what they're doing, repeating the objectives. I think like shy, shy lash. Maybe it's all about, you know, reiterating what's the objective of the sprint and making sure that the engineers understand it as well so that you can then prioritize your items as well. And then making sure that you achieve the objectives that you need. I do think it's really important for product managers to keep reiterating that. And it sometimes can get very lost when you are doing your daily engineering task and then executing them, not knowing why you're doing so. So it is, I do encourage you guys as engineers to also push back to your product managers and say, I don't know why I'm doing this, explain why and demand that answer. Because you do need to know why you're doing some stuff, right? And your task. Product analysis that is a daily exercise as well, sometimes maybe not so disciplined, but I try to get into a routine. The first thing I open up is Tableau, look at numbers, digest them, breathe in my numbers and understand why it's going down and find some hypothesis. Because the next thing I know is someone's going to ask for a report and then we've got to submit the report. Backlog grooming and prioritization, which is really an art. There is, maybe there's some signs around prioritization and we'll talk about that. But priorities, spending a lot of time thinking through is the first thing to get out because everything is important in this day and age and everything needs to happen first. But what is the first, first, first thing that needs to happen before the next first that needs to happen? So prioritization is a very big part of a product manager's duties and actually doing this every two weeks and then going into grooming with the engineers as well. So I talk really fast and I'm just like that. So stop me. If you guys need to stop me and have questions. Okay. So this is, this is an open sharing session. All right. So I like to think that product management is a sign and then there is the art part of it. So I guess you're not, you could be very familiar with the scientific method. I think product management as a practice has evolved across over time. And I was also just sharing this experience earlier with someone just now. You know, I, I miss the days where I am writing my user stories on in very small font in a very small find it pen on a posted note and sticking on the wall. And I really miss that experience because right now you have Jira, you have Trello, you have all these different which is more digital and virtual because you have a lot more virtual teams and clearly so cause, you know, if I put it on a posted not everyone can read it, right? But there's just something about crunching that posted and throwing away and calling it done that really drives a lot of satisfaction for me. But anyway, so product management is practice has evolved across time. I think scientific method is really here to stay for a while. It's all about experimenting and learning, launching small little features, doing very incremental features so that you learn from every release and then you go big. So whether is it a bigger rollout? Whether is it incremental changes to a certain feature? I think product managers are taking practice a lot more common now. So it's all about being a scientist, literally going into a lab and being through on your lab code and be a scientist, find some observations of why you think the customers want a certain feature and one have a certain problem understanding what the customer problem is all about. And that goes into your observation. And in the next part, what we do is we ask ourselves a lot of questions to then what is the right solution to put in front of the customer? What is the right experience? And some of that really comes from your user research. We spend a lot of time in front of customers interviewing them, putting prototypes in front of them and actually even observing what they tap, how their fingers move from screen to screen to really understand where do you want to put that button? So all down to that minute detail. We form our hypothesis and every hypothesis would then come with what is the outcome that we want to drive? So hypothesis would be, you know, if we do, if we build this feature, then we increase the company or bring certain satisfaction to the customer. So then we create that hypothesis. It has to be clear, concise, and it goes into acceptance criteria. And then we put it into execution. We work with you guys, the engineers put into sprint and then we execute. Obviously, I think the hard part is when the data doesn't show what we needed to show and then it's finding out why doesn't it show in the way that we think it would be and then come back and iterate again. OK. And then the art of being a PM, which is I would think 80 percent of the job, it's really all about the communication and drive with the team, with the stakeholder, with different people in the company and with the with the users as well. One big part is all around the product strategy. Decide why you want to go down one path and sticking with that decision. Sometimes it can be the wrong decision and then learning from the mistake and then kind of correcting it. Like I say, prioritizing features for implementation is a huge thing and understanding why one thing has to go above the other. But of course, I think the other area that product managers sometimes we forget is around tag debt and tag debt, bugs. This topic is super hot and, you know, because product releases is all around. Let's put up something shiny and new to the customer. But at the same time, causing a lot of tag debt. So good product managers should really be aware that tag debt does require some prioritization and actually dedicate some capacity for that. So I do encourage if there are product managers in the room to do that as well. Managing stakeholder expectations. So sometimes when you put out a feature, it doesn't go, you know, things don't always go up. Sometimes things go down. So managing the expectations is important, of course. And then bringing the product to market and deciding working with product marketing, working with PR on the communication. And what is the positioning? How do you bring forward the value proposition of the product to the customer and explaining that in layman's terms so that they understand it as well? So that's the problem. And lastly, I think in us, not really something that can be very data centric would be, you know, being empathetic to the user, really putting yourselves in their shoes, walk their experience, understand their difficulties on an everyday basis. So and then putting that into how do you translate that into finding a solution for them? So I have a list that I think can be good from my experience from the people that I work with. I think can be good, but I'm sure the list can be more. And if you have more, please share that with me. But I think for a good product manager, this is what you need to be. Number one, you need to be obsessed, obsessed with the user, obsessed with what they're doing, obsessed with what they're experiencing, the problems that they have. And then obsessed with finding them a solution. Sometimes I get so obsessed, I actually dream of my products. And that's when I know I'm in it to win it. And I just did last night for for something that I'm building. So that's a good sign. But being really obsessed with the user, don't stop. Just be obsessed with it. The next thing is be very decisive with priorities. It can be quite common where priorities change. The change could come from the top, it could come from sideways. But I think a good product manager, if you decided something with a team, kind of stick with it as much as you can, if you, because it doesn't produce churn. So I know my engineers would really not be happy or not like it because they plan all this work. And then now they have to kind of look at the funnel and kind of change things around. Change is not bad, but it has to be reasonable. It has to have an objective to why you're changing things. But be very decisive. I know I've come across and I myself have been in these situations where I just cannot decide what features to put out first. And I just cannot decide at that point. I always tell my team, just give me one night, let me sleep on it. Maybe it will come in a dream and then I'll decide. But yeah, I think being decisive is important. And being able to have that patience to then get opinions from everyone. Everyone will have an opinion about a feature. Everyone will have an opinion about a product. Being open and listening to that opinion is one thing. Taking it in, you don't have to respond. You don't have to agree, you don't have to disagree, but it's just about intake. And then kind of sorting that through, right? And deciding what is actually important to take in, what is just noise, when to say no and when to say yes. So I think having that capacity is very important as well. And being product managers, you have to be very open all the time to take in feedback because trust me, users are very... I would say that users sometimes a little bit unkind. But if you have, if you've done something wrong, they'll be the first to tell you. If you've done something right, they will never say anything. So that's just how it is. And above all that, you know, empathy and all that art behind it, it's always leading with data. So I think these days you would see more and more common where observations should be driven from data. It should come from the statistics that you've collected from a certain feature that you put out, from a prototype that you've put out, you know, from the user research field. Put all of that into data, put all of that into observation. And then if someone actually has an opinion, you can actually say, this is the data and this is what it shows. Of course, sometimes when you launch something to a smaller crowd versus a bigger crowd, the data would go the opposite way. I think then product managers could manage that via your rollouts, you know, throttling, don't go zero to a hundred. We've done it sometimes, brought some machines, brought some servers down. So, you know, maybe a good thing is always paste your rollout and then watch your data on a daily basis. But yeah, leading with data, that is very important. And I think it's just this never giving up in terms of making the best experience. Of course, not being perfect, right? Because it takes a lot of coding to be perfect and there's really no such thing as being perfect. Bugs will always exist. No one can promise me a hundred percent SLE anyway. So I think, but having that, you know, push, always push the team to make sure that the experience is the best that you can offer and having that as your intent. And lastly, this is my favorite. You are, the product manager is kind of the glue. I think if the product, good product managers should be the glue to hold the team together. You bring clarity to the team. You bring a meaning to why the team exists. So, and I think for me, you know, I don't know if Michael, you've realized that, but sometimes you will bring treats in to make sure that we pep up the team as well. So yeah, being that morale booster to everyone, right? Because everyone's working really hard. So yeah, I think product managers, this would be a special thing to add to your everyday for your team. I think it would be good to kind of make sure that you build a team in that way, right? So I'll end here by talking about, you know, as product management career for you. I think if you have the capacity, the patience, the never giving up period of wanting to make things good and putting things out there good for users, yeah, it's definitely something you wanna consider. But there's also a lot of communication, a lot of collaboration in this day and age because development is not just your team and yourself. It's actually horizontal with a lot of teams. You are dependent on so many different people. So being able to collaborate with people and having that attitude of forever learning as well. I think that's very important, that's right. So that's all I have to share today. If you've got any questions right now, please feel free to ask them. So you have 15 years of experience in this area. So in your opinion, in your experience, what are the user gaps in? Gaps in. And in the user gaps of lockers that defense a product from a company. Or from a desired time frame of a company. Right. I think there's so many I'm trying to decide what's the good one to share. So I think having clarity of if a product is, and I hope I'm gonna say your question, but having the clarity that if a product or if there's a certain direction that you're going with is the one that the company wants to take. Because sometimes the product manager can work in their own silo and not realize that, oh wait, the company is moving in a different direction. This is no longer prioritized. And then suddenly something gets blocked. Or very frequently right now in my everyday with grab because it's such a big ecosystem, we are so dependent on everyone else's code. So I work for, my area of work is called consumer experience and I basically manage the homepage. One small page, but oh, there's so many things to do. So we are so dependent on every single team making sure that their priorities are all online. And spending time doing that alignment can be a really long time. So I think alignment and making sure that it's the direction that the top ones as well is quite important. Just to make sure that you don't get blocked or you don't suddenly have to stop work and then change direction and then lose all that, good code that you guys have written. So follow up to the question is that so that you establish that is, that is the communication is important and it's key in determining that. Is there any kind of teamwork that you follow that will make this communication easier? Well, that's a really good question. So in most of my experiences is all about why are we doing this and does it get us to the goal that we need to get to as a company? Obviously there are company goals and then there are the problems that we wanna solve. And of course, all those are interlinked. So we always have that as the biggest, I guess the biggest card to use, right? Like whatever you're doing is not gonna meet this. Is it gonna get us there sooner? Is it gonna get us there right now? So that is usually the card that we would play as a trump to everything else. Yeah, thanks. All right, thank you very much.