 You guys had a wonderful main course. Thanks for staying around for the dessert. Obviously, this presentation is a bit different, even if we look past the fact that I'm a guy. No, he didn't notice that. I'm also not a developer. Okay, so what am I talking about? Well, when the organizers asked me to come up with a topic for this talk, I really wasn't sure what to talk about, seriously. In fact, we only settled on a topic like the beginning of this week. But I thought it may be useful to, I understand that most of you are developers, so we thought it may be useful to maybe give you guys a sense of how about the other side of the fence, what does a product manager do? Like, maybe I can start with this. How many of you are actually product managers? Anyone? I want to be good. You're at the right talk. And the fact that there's no product managers is good, because whatever I say, no one can contradict me, so that's great. Okay, so let's talk about defining what it means to be a modern product manager. Like everyone else, let's start a little bit about myself. So actually, I'm not a dev now, but I actually did start out as a developer. So I started out as a Java web developer. That was like 15 years ago. So if terms like J2EE, EJBs, entity beans, hibernate, spring framework, if that means anything to you, congratulations, we're about the same age. Since then, I spent about 10 years trying different things in technology. I've always loved technology, so I wanted to do stuff in tech, but I tried different things. So I did coding, I did sales, for a period of time I was doing biz dev. Then I went to Microsoft, I did some developer relations there, met a bunch of great people, then I tried marketing, and even last year at Microsoft I was leading a business there. But then, through all those 10 years, I realized that really my passion was in building products. But crap, I haven't done coding in like 10 years already, but I still want to build products. What do I do? Easy, become a PM. So currently I'm the director of product at Viki. This photograph is of me about 15 kilograms ago. I used to be a B-boy, believe it or not, but looking at my stomach, obviously I can't do this anymore. So what is a product manager? Basically, what a lot of people tell you is that the product manager is the CEO of the product. That's nonsense, you are not the CEO of the product. Unless you also have the ability to hire and fire people, you're not considered a CEO of anything. So a product manager is basically a business function that is really focused on maximizing the business value from a product. If you want to look at it visually, when you're talking about building a product, there's actually three main functions. There's UX, which stands for user experience, there's technology, the tech aspect of it, as well as business, whether your product fits the business needs or not. Basically, as a product manager, you have to be well versed in all three disciplines and hopefully experienced in at least one of them. So this is where you are. The other way to think about it is that as a product manager, your goal is to find a product that is feasible, that is valuable, as well as usable. If you have a product that is feasible and valuable but not usable, no user experience, no one's going to use it. Likewise, if you have a product that is usable but valuable, but it's not feasible, you can't build it with current technology, it's also useless. You get the idea, right? So holy trinity of product development. The modern product manager is not so much a dictator as more of a consensus builder or a glorified note taker, okay, if you want. So let's say you have customers that want a particular feature in your product or your CEO says, Jonathan, I need this bill, I need your homepage be redesigned again. So what do you usually do, right? No, you don't go and talk to your stakeholders or the customers, you take notes and you go back to the developers and say, hey, this is what we need to build. That's actually very inefficient. The modern PM actually tries to shorten the distance between your engineering team as well as your stakeholders and our users. So what I would do is say, okay, all right, let's all get together on a call or, okay, Sherman, why don't you talk to this customer and then we can see what they want. So one of the important things that a product manager does is to shorten the distance between engineering stakeholders and users, okay, not to become a gatekeeper, that may be the old way of doing things, but no, the modern product manager doesn't do that, all right. Another important thing is the product manager identifies and prioritizes the right problems for the team to solve. Honestly speaking, if you're working in a company with any kind of complexity, you will have a product that you'll feel is never perfect. And in fact, there is no product that's ever perfect. You may have a list of hundreds and thousands of things to do. You can't work on it all at once. So really, really important is to be able to focus the team and say that, hey, okay, we do this first, we knock that down, then the next thing, then the next thing, then the next thing. And the third point is also very important. A product manager doesn't go to the engineering team with the solution already in mind, okay? It's not your job to figure out the solution because to be blunt and honest, you don't know what the solution is, right? It's the team's responsibility to come up with the solution. Now, as the product manager, you are part of the team. So yes, you have a role to play in coming up with the solution together, but don't go up front with a solution. And yes, once the team gets together, figures out what the problem is, make sure it's the right priority, and then comes up with the right solution, then this is where the product manager documents the decision. Like it's very interesting, right? Like you may have a meeting, like a two-hour meeting with your devs, design team, try to figure out stuff, right? Okay, great. At the end of two hours, you got what you need. Everyone knows this is a path forward, this is the right design, this is the right solution, and then the PM has to go back and write the documentation, the specs, and do everything. That process of writing the follow-up emails and the documents probably takes up like five times longer than the meeting itself. But like I said, that's what you are. A PM is a glorified note taker. Okay, so for those of you who'd like to be note takers, who have a career aspiration of being a note taker, a PM is for you. Okay? And of course, most importantly is basically a PM hurts everyone to move in the right direction. Okay? Now, a product manager, what is it not? Okay, well, a product manager does not write code. I mean, you have talented engineers for that. Now there's some exceptions. Like for example, I'm special at Vicky because I commit to master directly. Yeah, I have faith from Sherman and the web team and my web engineer manager to do that. But I try not to mess things up too much. But no, but generally speaking, a product manager does not write code because engineers do that, okay? You also don't create mock-ups. And again, product managers, we like to think we're creative. Sometimes we'll do a wireframe or two. But for the most part, we don't do that. We don't do that. Neither do we have the skills to create a high fidelity mock-up. So yeah, you have designers for that. We don't sign deals that goes without saying. You have talented business people to do that. You don't plan PR. I mean, you get the idea, right? Basically, there are other specialized functions in your organizations that have specific roles to do. So you just have to worry about hurting sheep. Okay. Important skills for modern product managers to have, okay? Let's do it in a countdown style. We'll count down the top three skills, in my opinion, that a product manager should have. Saying no. Saying no is the third most important skill to have, okay? And this is, again, very important because you really have to know what to focus on. Your backlog, your wish list, you know, you may be bombarded by requests all over the place from your users, from your CEO, especially from the CEO, from your stakeholders, from your business people, you know, and the last thing you want to do is to go to your dev team and say, hey Sherman, I really need this by today. Can you do it? Hey Sherman, can you put this aside and focus on this one instead? Can you help me build this feature? You know, yeah, if you want one way to really piss off your developers, one surefire word, that's how you do it. You basically go to them every day with a different request, okay? So saying no is very important because you need to know what is important to focus on and you have to shield the team from additional noise, all right? Always be ready to answer the question. Okay, fine. Let's say everyone died, okay? Everyone got hit by a bus. You only have one dev left and you can only deploy that one dev on one thing. What would that be? Okay, so learn how to say no. And I mean, yeah, it's easy to say but imagine your performance reviews are being done by your boss and then your CEO says, but John, then I feel very strongly about this website design. Then you have to use some verbal kung fu to deflect that. Number two, most important skill to learn is credibility, okay? And this sort of goes without saying but if you have a vision of a product and you want to push your vision through to your engineering team, you have to be credible, right? Sherman, am I credible? Pretty good, yeah? Okay, all right, cool. Okay, lunch. Yeah, so if you don't have credibility, all right, then there's no way you can sell a vision because you may say that, oh, I'm the PM, I have all these great ideas. This is what we have to build. No one will care, right? You will not be able to push your vision through to sell your vision to the team. Credibility is earned, not given. I mean, oh, Big Shot PM came from Microsoft, 15 years of experience in the industry, doesn't mean a damn thing, right? You have to earn credibility by showing that your positions, your vision is backed up by data, right? You have actual user reports that say that, okay, this is actually user behavior, we want to go this way. And basically you have to prove yourself that you can be capable of making good decisions, right? And you make enough of those decisions over time, you know, save people's assets enough times, then that's how you earn credibility, okay? So I hope I'm credible, all right? Sorry Alan, okay. All right, what's the most important skill for our PM to have? Any guesses? Come on, just shout out something. Communication? Sort of, but not really. Okay, never mind. Empathy, okay? So in my opinion, empathy is the most important skill for our PM to have, okay? So let's talk about the obvious part first, all right? You have to have empathy for your customers' pain points. You have to understand how they're using the product, why they're using it, and what pain are they suffering. Now granted, at Vicky, we don't always have full empathy of our customers' pain points, especially our community of users, because no matter what we do, they'll still stick around for some reason. But that's not the right mentality to have, right? So you have to have empathy for what's their pain and then how you can deal with them. But beyond that, you have to think, again, any organization or company with enough complexity is not only about product and engineering. You have the design team, you have the customer experience team, right? The people who actually suffer when customers complain and issue support tickets. Then you have our BizDev team, you know, you have your marketing team, you have PR, you have CEO's office, you have all these different stakeholders in the company. Now, if you operate in good faith, you'll believe that everyone's marching towards a common goal of doing right by the customer. But every group of these people, each of these stakeholders have different perspectives, have different considerations, and have different priorities. As a PM, you also have to have empathy for those people, right? So when you design a feature, when you roll out a feature, when you come up with a launch plan, you have to consider, okay, what's the impact for marketing? What's the impact for customer support? What's the impact? How would that help or hurt our content team from getting additional content? So it's very important to have empathy for your stakeholders as well. And of course, it goes without saying, but you have to have empathy for engineers and how they work, and that's really the most important thing. Like, for example, at Viki, we have an unofficial rule, like PMs shall not approach the desks of developers until after 5.30 p.m. And that's because we have an open concept, so it's sort of distracting if people just go up to you all the time and talk to you. Especially, you know, as devs, sometimes you're in the zone, right? So usually if I need to talk to a dev, like say for example, I need to talk to Sharon about something, I'll go behind her chair. I'll see whether she's listening to music or not. Is she focused on coding or she's doing her New York Times crossword puzzle? All right. And then if it feels about right, then say, hey. No, but usually we try not to do that. And then because we use Slack for intercom communication, so we usually Slack message. And then if, for example, you Slack someone, and then they reply immediately, okay, it means that their context has already switched right. Then it's okay to go and approach them to talk, right? Because frankly speaking, I came from organizations where it's more efficient to go talk to somebody than to send an email or to Slack. But whatever, to each his own. But regardless, the point is you have to respect and have empathy for how your developers want to work. Okay? Now, a million dollar question. All of you are devs here, or at least most of you. At least one person here is thinking about being a PM. So how do you know if product management is right for you? Well, you may be a closet PM. If, number one, as a dev, you love pouring over data that helps quantify the impact of what you build. Now, it's okay, right? Not all devs need to be overly concerned about numbers because honestly speaking, that's what the PM is for, right? To get the numbers, to get the feedback, and making sure that the product team is on track. But if, as a dev, you feel the urge to, yeah, I want to find out, like, how my feature is doing, what's the impact? You know, then maybe you have some signs of being a PM, right? Do you feel energized working with other people in your company outside of engineering? Do you like to talk to your marketing folks or to your recruiter, for example? You know? Everyone likes to talk to a recruiter. Hi, we need more colleagues. Right? Do you like talking to your CEO? Do you have a one-on-one schedule with your CEO? I mean, not to, like, curry favor, but because you generally are concerned about the company and the direction and you want to know more, right? That's all cool, right? Yeah, then you may be a PM material. Do you get a thrill from leading workshops like brainstorming sessions and ideation and documenting down the conclusions? Do you feel ecstatic when you put pen to paper and write things down? Do you love documenting stuff? Do you live in Evernote? If you like documenting things down and write complex documents, then yeah, maybe PM is for you. Lastly, you know, are you opinionated? Do you have an idea of what your company should build next and can't wait to tell everyone about it? You have this great idea and I just want to tell everyone. I want to tell my PM, I want to tell my designers, I want to tell my CEO, you know, this is what I want to build. You know, yeah, I'll get my job done, but this is really what I want to build. So, if all this applies to you, you know, yeah, you may probably, you know, consider product management as a career path. Does this apply to you? Sort of, no? Okay, alright, too shy to answer, okay. Okay, so, that's really it for me. Thank you, so, yeah, I hope some of you will consider product management as a career path once you get bored of turning out code. Never. Thank you. Yeah, I know you're going to be a career dev. Any questions for John? He's the most empathetic person in the team. Is it? Really? Okay, lunch tomorrow. Yeah. Okay. Are you more product manager? Unfortunately, no. Unless you want to take my job. No, we don't have any product manager openings right now. But we have plenty of dev openings. Yeah. Okay, any other questions for any one of us? Or the, all good? If you can talk to us. Yeah, don't pice it. Yeah, don't pice it, yeah. It is awesome. Thank you so much John to share with me.