 Hello everyone. My name is Ronke Magicadumi. I'm a Senior Product Manager at PayPal. I want to thank ProductSchool for providing me this lovely opportunity. I want to thank you for taking the time to attend this webinar. Today I get to talk to you all about my favorite subject, characteristics of great product managers. So, as noted, my name is Ronke Magicadumi and I'm a Senior Product Manager at PayPal. PayPal, as most of you know, PayPal is an American company that supports online payment system in majority of the countries that allow online payment transfer. This is in lieu of the traditional checks and money order. For most of my career, I work in the financial industry. I've helped to build B2B and B2C platforms. Today I wanted to share with you all my PM superpower. I thrive in finding insights beyond the side of others. What do I mean by that? Whenever I'm faced with difficulties, whenever I get a no, I always look for other opportunities. I look for ways to get my product or my future developed and launched to market. And sometimes I have to come up with some very creative things, but I use my PM superpower every day. So I implore you all to please use the PM superpower because that's how you build products that change the world. I also wanted to share with you all my favorite books. One of my favorite things to do is to look for books on sale on Kindle and iBooks at night. And so today we're talking about characteristics of great product managers. I wanted to share with you all my favorite books about leadership. These are books that have helped shape my leadership style as well. There are five main takeaways today that we're going to talk about. These are all characteristics that these great product leaders have that I've noticed anyway. They are customer-focused and they rely a lot on business insight. They over-communicate, and yes, I did put over-communicate and you'll see why, they over-communicate strategy and vision. They partner and influence, they are strategic and tactical, they are data-driven and intuition. And these are all the characteristics, the traits that I believe make them so great at their job. I want to start by saying that great product managers build people and products. So what do I mean by, when my teammates and I get together and we talk about great product managers that we've worked with, we talk about skill sets that they have, there are two things that always stand out right away about them. They build people and they build products. What do I mean by products? They nurture their teams. So they're scrum teams that cross functional teams, they nurture them, they build a community around them, they invest in them. They make sure that their teams are recognized before they are. And so what happens is when you invest in people and you nurture your teams, you have motivated individuals who are ready, willing and able to help you bring your product vision to life because they know you care about them. Great product managers build products. These leaders think from the outside in. They're not complacent, they don't settle for the status quo. They don't build for the segment that they currently have. They constantly think about other segments that could possibly use their platform. So therefore they build from a platform approach. So even though their organization may not be quite there yet, by the time their organization acquires another company or there's a merger, their platform sometimes they don't need to rebuild them because they've thought ahead. They're strategic. They think from the outside in. That's the other thing that makes this product leader so great on what they do. Great product managers that I've worked with one of the skill sets that they have is the customer focused and they end every end of the client business insight. So what do I mean by that they're customer obsessed and they use metrics to define actionable steps. So customer obsessed for instance, they embody customer first approach for their experiences for the products and services that they built. The customer needs and wants are always at the center of everything that they do. It's at the center of their discussions with their teams. It's at the, it's at the center of their discussions with customer facing teams and non customer facing teams. They're always trying to make sure that they are building what is right for the customer. And then of course we'll talk about metrics that become definable action steps for customers that the customer sets as I mentioned, so I'm customer obsessed as well. But the way I traverses a little bit different pre COVID. For another organization, I would invite customers and in our local city that we worked where we worked, I would invite them to the office. I would take them around so that they can see our building so that they can see our offices and how we all are we all work together. I would then bring them into a conference room and I'll bring one to and then conference room would be my PMM partner will be my tech lead would be my design lead along with the engineers. I would then bring our platform up on the screen, and then we would have lunch and keep the conversation light and breezy and have just kind of talk through and ask them why did it pick us. Of all the, they were looking at us, and then we're looking at all the other competitors, why did it pick us was so unique about us. And then I would ask them how many people in their office use our platform, and why did they use it what jobs are they trying to do. I would also ask them what tools today use and why did they use those tools. And then I would ask them, what features do they use what features in the platform to the user not using. And then I would also ask them if we could add five features, what would those five features be, and how would it change the way they work. I love having these this customer this day in the life customer visits because it changes the customer, the customer becomes transformed aligned and inspired. They feel hard, they feel hard, they walk away going oh my god the company really cares about what I think. And for the engineering team and my cross-functional team, well it changes them as well, because now they have empathy, because they understand the stresses that the customer faces. So, even if with even though you're working from home, I employ you if you can do a day in the life. Even if you do it via Zoom, it is so important because it brings your cross-functional teams right into the room with the customer. It gets you where the pain points are, it gets them what they're trying to do. Metrics become become become defined and relaxing steps. The way I try to address it is I always pay attention to a matrix. I believe that metrics help to tell the full story of my product. So there are two in particular that I always look for. One is the NPS score. If my NPS score, if it comes, if the score is high, when, if the score is really high, when it, for, they wouldn't recommend this to my colleague, that to me is an issue. Because it means that I don't see the value in the product and not enough to even user let alone recommend it to their colleague. So then I go and I try to find out why. I talk to my customer-facing teams, I talk to my non-customer-facing teams to try to figure out what's going on. And now we can fix whatever those problems are because if a customer sees your product as having value, they would recommend it to other people. The other one that I pay a lot of attention to is CSAT. CSAT survey. I use CSAT survey in two ways. One, onboarding. Once the customer is done onboarding, I use CSAT. So that I can kind of, I use the CSAT survey because it gives you raw and honest feedback right away, whether or not their onboarding experience was great or not. And the other one is when we launch a new product, when we launch a new feature right away, I like to use CSAT survey. Again, same thing, you're going to get their feedback right away, whether good or bad, at least you can kind of then make some adjustments. So these are how these great product leaders, like I said, be a customer-focused and use business insight. This is how I use it. So yes, I did use the word over-communicate strategy and vision. I did use that word because as product leaders, we are, we are evangelists. And these great product managers that I speak of, they could tell you the customer value. They could tell you the goals, the business value and the customer value. They could tell you in their sleep. So they are a walking, they are just a walking, talking, you know. So this great leaders are, so this great product managers, the over-communication strategy and vision. And they have to because they're evangelists for their products. So I kind of want to walk you all through how I do it. So I call it a communication tour and it's done in five acts. So let's say I already have my research done. I know what future I want to build and we have it all sorted out. Right. We know what the customer need is. We have all the research done. The first thing I do, I call it an act one is I involve, I create, I set up a working session with my first three in a box, which at this point would be myself, the product manager, my design lead and then my content lead. And we would go through what is the customer? What is the goal? What is the customer value? What is the business value? And how do we met and what will our KPIs be? If everything goes well from this, from this discussion, then we can move on to act two. And so from act one on my design lead, our design, we would then go off and build the iteration. And when we get back together with him in the content lead and kind of go through it before we go into act two. If we still need more research, we'll know after this conversation. But let's assume everything did go well. And we now have an iteration. Then I move it on with the communication tour. And now we're in act two. In act two, this time it's myself again, the design lead and my tech lead. And what we're trying to do here is that we go over with our tech lead, the problem that we're solving. Why it matters? What would be the benefit to the customer and to the business? And how does it tie to the raw strategic goals and objectives of our organization? Same deal, we'll get the feedback of our tech lead. If we need to iterate on the experience, we'll iterate on experience. But what the outcome of this conversation will be our tech lead will let us know if there are technical debts that we should be aware of. So we're going to need a proof of concept to make sure that we can actually build this functionality. And if he needs to do any additional research to see if we have any other dependency teams that we might have to bring them, I have to work with. So that's the cool thing is we start early. So I caught that again, this is why I call it the communication door. So swimming everything goes well there. Then we move on to act three in act three is when I bring together customer facing and customer facing teams. So at this point, I bring together customer service, relationship management, technical support. I bring together any teams, any of the teams that talk to customers, their leads, my counterparts, and then customer facing teams. I'm looking at data scientists. I'm looking at the lead with billing and pricing and so forth. And we bring them into. And we do a formal presentation, my three in a box, which is myself, design leader, my tech lead. And we talk through with them, the goals, the customer benefit, the business benefit. And then we talk about how we measure success. The objective of this meeting is to make sure that we got it right, but our experience solves the customer problem. And the customer facing teams, this is where they come in because if we didn't get it right, they will tell us. We can go back and iterate on the experience, but we want to make sure we're solving the right customer problem. And then for is when we bring over is when we have another formal meeting with our cross functional teams. So this for me would be our risk compliance, our architects, our state other additional stakeholders like product marketing and we'll do again another formal presentation and present to them what we're building and why we're building. So this is where the meeting with the cross functional teams are, they're going to have to help us probably build parts of our product or feature. But we want to know from our kind of parts of 19. If there are any hiccups that they see, is there another dependency team that they have and they need to talk to do we need a proof of concept. Are there any possible, any problems that they could possibly foresee that will prevent us from building this product or feature. We bring them in, we bring them up orderly so that they can kind of start to help us iterate on the experience and also to make sure we can we can build it. We listen to their feedback, and we iterate again on the experience if needed. And then act five of the of this tour, as I talk about it this communication tour is now that we have the buy in of with the buy in of the cross functional teams. And then now we go to leadership and we present a leadership where we're trying what we're trying to solve for the customer problem. The customer value the business value, the KPIs and how it ties sort of raw strategic goals of our organization. And this meeting we include our research counterparts so that we can also then begin to talk about what is the learning plan so that we can do a usability study. As I mentioned, these great product managers, they are evangelist. They know they, they will tell you the story of the product and why it matters to the market, what is the market distinction, how it benefits the customers. So that is how I over communicate strategy and vision. So I just wanted to share with you all partner influence. These great product managers, they know how to partner influence they know that because cross functional teams build people build part of their own part of the products. So they know that they must, they must lead, and also they must partner in influence. And here's how I do it. So, in the beginning of the year, when I know that we have a product strategy defined, and I have a product roadmap ready. I have a working section with my counterparts on the design, not just design, but also all the other teams, risk compliance union architects and bring them all together, and I walk through with them. Well, why this is our roadmap, what is the product strategy. The reason I do this right in the beginning of the year, so that they can include my, they can include our product into their roadmap, so that they're not surprised when we ask for help later on. So this is the feedback on experiences as soon as we have a first iteration, we're going to go talk to them, and we're going to show it to them and get their feedback because we want to know right away. If there's any technical debt and the hiccups anything we need to be aware of. Is there other teams that we are not talking to that we should be talking to again to set ourselves up for success networking, the way I network is a little different. Whenever there's a new member to any of the cross functional teams, I schedule coffee with them pre COVID. Since we've been working from home, I scheduled virtual lunches with them. So I make sure I get to know my partner teams because by getting to know them I know the best way to communicate with them is an email is a slack. I know the best times of the day that they're ready for meeting. Are they taking their kids to school in the morning at eight o'clock is 30 better is 90 and better. I also understand in the middle of the day if you need to go pick up the children from the school not to schedule the meeting let's say at three o'clock or four o'clock. So that's sort of one of the ways I've never the other thing I do is, and I used to do this pre COVID is I would schedule once a month I would schedule a lunch with my scrum team, and my tech lead, my design partner, and my content partner, and I would invite my counterpart on the risk side of compliance side I will invite them that that product lead their engineering team, though, and as well as their content lead if they want to come. And design partner if they want to come to lunch. The goal is to introduce our engineers to each other, because when, especially when we're building a product together or feature those engineers need to be able to work with each other, because they might have to build a proof of concept, because that we're building pieces of our future and we mean, and before we could even release it will need that feature, and we need to be able to test with them, it makes it easier for you already know each other. And now my scrum team of networked with another scrum but then with my with another cross functional teams come team so it makes it easier to do the job, and when we release if we have a bug, it makes it easier to fix. The other thing is being malleable and open to feedback as product managers are so close to our experience we're so close to our product. And sometimes when the feedback we get and not be the best, but I've also, I employ you all to be open to it, because they're only given that feedback, because they care and they're invested in our success. So even if that feedback is not the most desirable thing in the world I recommend being open to it. Communicating updates. Oh, this is so important. I cannot tell you all how important this is. Especially when you have a project that is being built by other teams and my team. Whenever there's a change, I communicate an email a community is slack communicated in a meeting. If we pre covered I would also do it in person as well. I'm going to explain why the change, why we're having the change with every single project there is bound to be change. The question is quickly to be communicated especially when other teams are helping to build that product or feature is the quicker we can get those. We think the quicker we can communicate those updates that are better, especially when it impacts dates and timelines, and the other thing about communication. Because now you're that PM that they can trust that if something is going on, they can rely on you to talk to them about it right away. So this is how I probably. Influence another skill set that these great managers have strategic versus tackle. So these great product managers, they are both. And I've worked really hard to be both myself in my PM career. So the first thing I always do is I always have got the strategies that the strategies priority, and I don't pick between one of the other I balance it because I think you need both. And here's what I mean. And so, when you're building and when you're executing an experience right when the different teams, cross functional risk compliance, when they're all building this experience to kind of have detailed questions, they're going to call and say, Oh, what should this happen what should this do. Well, in this experience. How do we know how to answer that the only way I'm going to know how to answer that question for them is to have a strategy. And that's why it's important right in the first in, I mentioned how we have to over communicate our product vision right and experiences and everything. This is why it's important, because if we have a buy in of all the cross functional team, if we have to buy in of leadership, they were all in the same pages to what the strategy is. So then, if we know that, then it makes it easier to answer the tactical questions. So that is how I'm for it. I use both, I'm strategic and tactical, I don't pick one or the other, because without the strategy, how do you answer the tactical questions. So they to me the kind of feeling they you need both. So that is how I, that is how I traverse that data driven versus intuition, this great product managers that I talk that I speak of. They are data driven, they use data and using intuition, and both of them makes them success in their fields. So I'm going to talk to you all about how I do it. I use both data and intuition, that is what makes me it is strategic and that's what makes me successful. It's well defined, right. It's, it's black and white. Right, so we know that. And intuition sometimes you have to use your intuition especially we have really complicated problems and so on it's an answer right away, you use your intuition to make those decisions. I always use data and rely a lot in data. And when I'm into an organization. The first thing I do is I go talk to customer facing teams and not customer facing teams so that I can have a historical context for the product. That way, if I'm called upon to make a really to make a decision for really complicated matter, I have a little bit of room to work with. And in those times, when I don't really know a lot about it. Yes, I rely on my own data. And so I go out of my way to find those historical context because it helps me especially when I have no choice and have to make really quick decisions. So I use both, I use data, and I use my intuition, this grip, and your intuition you get to use your intuition really helps you especially when you have more experience in that environment in that product. Then it's even for you to use your intuition you don't have to do the research that I have to do if you're new to it. So that's how I use data, and that is how I also use my intuition. Hope that helps. So the main takeaways for our talk today, this great product managers that I've had the privilege to work with. These are the skill sets that they have, they're customer focused, and they look at business insight, they have a community strategy vision because they are evangelists for their products department and influence, they are strategic and they have data driven and they also use their intuition. But as I mentioned, they build people and they build products. When you have motivated people who know you care about them, they are willing and they are willing and able to help you build to help you bring your product vision to life. And then I remind you of this is my PM superpower. I remind you to please use yours. For me, I thrive in finding opportunities beyond the side of others. I want to thank you all for taking the time to attend this webinar today. I want to thank Howard School for this lovely opportunity to talk to you all today about characteristics of great product managers. This is how you can reach me. I thank you for taking the time. Have a lovely day.