 Hi, my name is Yvonne Perrel-Andoni, and today we're going to be talking about product management. Specifically, we're going to be taking a straightforward look at what is a very convoluted profession. We're going to start by talking about the long-strange road into the product management career path. After that, we're going to touch on defining success at a personal and product level. Then finally, we're going to talk about some tactics and ideas to develop a stronger relationship with insights-driven storytelling. Before jumping in though, a brief introduction. As I mentioned, my name is Yvonne Perrel-Andoni. Currently, I'm head of ProductDat 4, which is a social media marketing company based in New York. Prior to this, I was director of ProductDat Forbes where I was working on these subscriptions and membership team. Before jumping into actually becoming a product manager, I think it makes sense to take a step back and define what a product manager actually is. For this, I would like to start with a little history lesson. Back in 1931, Neil McElroy from Procter & Gamble wrote this 800-word memo asking for brand men. Neil's idea was simple. If you had individuals whose sole purpose was to be a representative of the voice of the customer within the company, then you would never develop the wrong product. Because the voice of the customer would be the one who was actually driving the product development lifecycle and process, which is great because it prevents you from developing products in a silo that you think might work, but you haven't really had time or the ability or the wherewithal to fully justify and rationalize with the actual users. On a side note, Neil ended up becoming Secretary of Defense co-founding NASA, and he became an advisor at Stanford where he inspired a couple of gentlemen by the name of Hewlett and Packard into computing excellence. That is to say, all product managers are clearly awesome. Moving on to 1943, Hewlett-Packard Enterprises took this idea of brand men and ran with it. You see, the whole idea of Hewlett-Packard was that if they use the voice of the customer to guide their product development process, they couldn't go wrong. They combined that with a few really interesting product development dynamics and processes that they borrowed from Toyota. But overall, they really do attribute this idea of the voice of the customer to their 20 percent sustained 50-year growth from 1943 to 1993. You can actually also read about this in the book called The Hewlett-Packard Way, which is a really interesting deep dive in history if you're interested in such nerdy things. Moving on to 1997, by this time, product management had become less about marketing, which it really did start off as a very marketing-focused profession and more ingrained into the idea of actual technology, so into the nitty-gritty components of actually building and developing products. In 1997, gentlemen by the name of Ben Horowitz of Andreessen Horowitz fame, wrote this memo called Good Product Manager, Bad Product Manager. This is probably one of the most famous quotes in product management, which is the product manager is the CEO of their product. We'll touch on that in a second. But after this in 2001, which was a year of both space autosies and Agile, surprisingly enough, 17 software engineers got together at the Snowbird Ski Resort in Utah, and developed what's called the Agile Manifesto, which was the very first Magna Carta document that described the overall Agile software development process and upended the idea of waterfall development. Pretty much immediately, because of course, what else are 17 software engineers going to talk about on a ski vacation, right? So I did mention that we were going to go back to that quote, a product manager is a CEO of their product. I think it's a really important quote because it's something that a lot of people point to as their reason for becoming a product manager. I think this has become a little bit less unvogue as time has gone on, but when I was coming up in product management, which was in like the early 2010s, this was the whole idea, a product manager is a CEO of their product, and it sounded so cool and so exciting, right? It's like a shortcut to becoming a CEO or something. And unfortunately, it's not necessarily true, or rather it's not something that you should take at face value. See, there's a lot of differences between being a product manager and being a CEO. The major difference is that as a product manager, you don't really have the authority to do much. Instead, as a product manager, you lead with influence, meaning that your job is to interface with different teams and different stakeholders and try to influence the right decisions being made in the company by using a combination of quantitative storytelling, by using a combination of the voice of the customer, and by using your ability to just tell a story in general to showcase your idea for where you think the product should be evolving based, again, of all those external factors, the data based off of what customers need, based off of what the market dictates, to take it off of what the company actually needs to accomplish here. And so this leads us into what a product manager actually is, right? Because if the product manager is not the CEO of their product, then what are they really? Well, product managers are all sorts of things. They're customer service professionals, they're teachers, salespeople, technologists, marketers, UI UX enthusiasts, they're strategists. Product managers wear all sorts of hats and they embody all sorts of roles. And the entire purpose of the ethos of being a product manager is to be all things to a customer, so that other people don't have to be those things to a customer, if that makes sense. And so that means both being very adamant about reaching out to customers and doing market research and identifying what actually needs to be built, but also being very adamant about using data to justify those hypotheses and those assumptions that you're coming up with that are guided hypotheses, but their hypotheses nonetheless, put in together plans and strategies to test those hypotheses. And then effectively bringing other teams along for the ride or leading with influence and trying to get leaders of other teams to, I don't wanna say see things your way, but kind of see things your way and take a stab at doing what you are recommending from a product roadmap and product development perspective. So at a very high level, a product manager is an influencer and that they lead with influence and not authority. A product manager is a guide. They are a sherpa on the journey to the right answer and they really are that voice of the customer and they help effectively drive people in the right direction of building the right product at the right time. And more than anything, product managers are consummate storytellers. The common thread between all of these different hats that I mentioned, all these different things that a product manager is, is that a product manager needs to be able to tell a really effective story in order to get buy-in to do something. If you can't tell an effective story and you can't get buy-in, then you can't succeed in product management full stop. So this leads us to defining like how you can actually become a product manager. And I think what I like to do is think about the six simple mantras of product management that I've kind of come up with throughout my career. These could change for different people, certain people might have different mantras than I do. These are just the things that I've learned and have worked for me. Number one is be humble. As a product manager, it's really easy to fall into the trap of thinking that you know everything because you are the voice of the customer, you're looking at the data, you're talking to all the different teams, right? You're the source of truth for everything. But I think it's really important to recognize that as a product manager, you're never really gonna realize how much you don't know about something. And this goes to this idea of empathy as well, right? It's very easy for you to go and try to dictate how other teams should do their jobs or how other teams should conduct their processes or what other teams should do in support of a product. But it's very difficult to empathize with what else those teams are trying to accomplish and really think about, hey, if the marketing team has these five other goals, like helping me achieve this product goal might not be a top of their priority. So being humble helps you really reframe the conversation with that team and say, hey, this is how we can achieve our goals together, but tell me a little bit more about what you're struggling with and what you're trying to accomplish and let's see if we can come up with a solution. The second piece is being collaborative. And again, this goes back to that whole like empathy piece, right? You're a Sherpa. Your job is not to tell people what to do or how to do it. Your job is to guide people in the direction of making a successful product. And again, as a Sherpa, you have to recognize that sometimes your product goals might not be the highest priority for a different team because again, you're not a CEO, you don't have very much authority. As a collaborative product manager, your responsibility really is to come up with a win-win situation where you can work together to achieve the outcomes that you both need from a team basis and not feel that you're sinking work into any one thing that isn't gonna actually help you. The third thing is always be curious. It's really easy as a product manager to forget about exploring things outside of the immediate needs of a product. It's really easy to be very short-term when you're thinking. It's very easy to think about just the tasks that you have in front of you. It's always important to be curious and always important to keep questioning yourself. And this also leaves this idea of like humbleness and keeping your ego in check, right? Curiosity doesn't just mean that you're always exploring different product examples in the market, always talking to different customers, always digging into the data to identify what your customers are and are not doing. Being curious also means taking a hard look at the hypotheses and assumptions that you're making and really trying to convince yourself or pitch yourself on them, right? With this bias towards proving yourself wrong. I think the more curious you are, the more you try to disprove yourself, the more you are challenged to create a really strong story and create really strong evidence around why your ideas, why assumptions and why your hypotheses are not only correct, but are definitely worth exploring for. Number four is be strategic. You know, like I said, it's very easy as a product manager to focus on short-term tasks and effectively miss the forest for the trees. As a product manager, it's really important to balance the things you have to accomplish now versus the things that you want the product to accomplish in two years, three years, five years, et cetera. Product management is not a short-term career. It's very difficult to have like a short-term gain mentality for product management. It's really important to have this long-term strategic vision of where the product is going to evolve to. And again, the humbleness to know that that vision could change based off of things that you discover along the way. Number five is bias towards action. And it's kind of funny because this sounds like a little bit of the opposite of what I just said, but you know, a lot of things that younger product managers will also do is neglect the things that have to get done in the short-term in order to drive the long-term strategy. And this means little things like turning out tickets. This means little things like conducting interviews and synthesizing these interviews. This means little things like developing really great documentation. These are all tasks that have to happen and these short-term tasks do need to be balanced with that long-term vision. And then, you know, wrapping it all up, number six, really important be a storyteller. Every experience you've ever had has given you some insight into what you think should be done. Make sure that you can distill those experiences, distill those ideas into a really effective story to tell all of your stakeholders, hey, here's what needs to happen, here's why it needs to happen and here's how we're going to make it happen. So let's talk about becoming a PM. Now that we've kind of defined what a PM is and like what the product management life actually looks like, I think it's important to also recognize that there really is no singular straightforward path to becoming a product manager, right? Again, a product manager is an amalgam of so many different careers and so many different hats and so many different specializations that it's difficult to say, hey, like I've been a product manager my whole life because most of the product managers I know, and I would say most of the most successful product managers actually were not product managers when they started their careers, they were something totally different. So even though there's no singular straightforward path into becoming a product manager, there are some things that you can do to set up your move into product management. So first and foremost, if you're in a larger company with a product organization, it's a really great opportunity for you to think about applying internally. Like I mentioned, every product manager has to wear many, many hats, which means that whatever you're doing at this current moment, be you a designer, a customer service agent, a developer, et cetera, you have a very great insight into some piece of what makes a product manager a product manager. Use that to tell a story of why you would be a really great product manager and start developing relationships across the rest of the product team inside of your organization, really looking for those open roles. This is a really great opportunity for you to not only make connections within the product team in your organization, but also ask questions, like really try to dig into what you could do to be a successful product manager and make sure that your application to those open roles reflects what the actual definition of success is for product management in your particular company because the definition of success for product manager changes from organization to organization and more on that later. The second thing you could do is look for APM or entry level roles. APM associate product manager is honestly something that's relatively new-ish. I would say that the first APM roles were probably started by Marissa Mayer when she was at Google in like the early 2000s. A funny story, when I was coming up as a product manager, it was almost impossible for me to move into product management because there was this catch 22 of like, to be a product manager, you need to have product management experience, but to have product management experience you need to have product manager. You need to be a product manager. So it's like, how do you actually become a freaking product manager, right? The APM role, I think it was a great bridge into getting into product management, but it was something that was exceedingly rare back in the early 2010s when I was coming up. This was something that was very Silicon Valley focused. It was something that like the big techs were doing, but it wasn't something that had led its way into the mainstream from a company perspective. I would say that that's changed quite a bit. I think you'll see a lot of APM and entry-level product roles open nowadays and all sorts of companies are hiring APMs. It's important to note that a lot of companies hiring APMs or entry-level product managers will still have some sort of a years of experience requirement. It's just one of those things where, the third testament here is don't be afraid to put yourself out there. Yes, a lot of job postings are going to require experience. And yes, I'm just going to say, it's going to be daunting because you're just like, well, I'm not a product manager. I have no product management experience. But typically speaking, unless you're working with recruiters that are very to the letter in terms of experience required, what you'll find is that people make allowances for different experiences that ladder up into product management. So don't be afraid to apply for that PM role even if you don't feel that you have the years of product management experience necessary. Instead, use your storytelling ability to explain not only why you'd be a great fit to work collaboratively to guide a feature to success but also use that storytelling ability to really dive into how the things that you've done actually do contribute to product management. Again, there's no straightforward path here but one kind of platitude that I like to say which is funny because I really don't like platitude but to achieve success, you really need to define success. And so this goes into defining success at the product and personal level, right? It's very easy to talk through all of these different tactics that you can have to maybe like make your way into the product management profession but it's really important to have that end goal of like what you actually want to achieve and what is successful to you in order for you to start being more effective about how you're telling those stories. So defining success on a personal and product level is honestly as critical to launching a product or a feature as it is to setting you up for career success. And then side note, I love royalty-free imagery because it really adds this sense of gravitas to every presentation. And so, you know, this is legit advice because of this hyper inspirational royalty-free imagery. So let's talk about defining success. What does that actually mean? In its simplest form, defining success really just means defining and justifying a problem to solve, right? So you want to start with defining your why, meaning why are you trying to solve this problem? What is this problem? What is the importance of this problem? Why is it important for you to tackle this problem and why is it beneficial for the company to address this problem? Secondly, define your vision. Once you've justified the why behind your problem, you need to be able to articulate a vision on how you view not necessarily solving the problem but approaching a solution to the problem. Now, this isn't you saying, hey, like we need to develop this product with these super specific features. Rather, it's you taking a step back and saying, hey, in an ideal world, knowing that we need to solve this problem, what are some of the core outcomes of a successful product that would be solving this problem? And with those core outcomes, you really want to keep them kind of at the high level, instead of, again, talking about the specific features that you think are going to be a successful solution to any kind of industry problem, you want to start with defining the components of success. And so components of success can be articulated as simply as like for this product to be a successful solution to this industry problem, we need to be able to capture 10% of the total addressable market in order to have enough scale to continue to grow this product or in order for this product to successfully solve this problem, we need to enable the average user to save 25% of the amount of time that it would take them to do this normal task on a consistent basis. And so you start to see that components of success are honestly more metrics driven and a lot less feature driven. So once you've defined those components of success, you need to define your measurements, right? One of the things that a manager has told me that has stuck with me for years is that if you can't measure it, it doesn't exist. And so once you've defined the components of your success, this solution needs to make it easier to solve this problem. This solution needs to have this number of scale from a total addressable market acquisition perspective, defining how you're actually gonna measure those components of success or KPIs is gonna be absolutely critical for you to actually define success and solve this problem. So I said a word there, KPIs. What does that actually mean? At its basic form, KPI means Key Performance Indicator. Side note, there's a lot of acronyms in the product management world, which is absolutely hilarious. Once you get to use the acronyms a few times, you'll start using them in day-to-day conversation, like when you're out at a bar or drinks with friends and you take a listen to yourself and you're just like, God, what have I become? Anyways, it's imperative that as you set KPIs or Key Performance Indicators, you're able to effectively measure them. So there's a few kind of core components that make KPIs KPIs. KPIs need to be simple. You don't wanna have like a hyper-complex, like 17-way measurement if you can be avoided because it makes it very difficult for you to actually define success off of something that's so complex that you can barely understand it. They need to be relevant, meaning KPIs need to have some sort of relevance to what you're actually trying to solve. If you're saying, hey, like, I need to solve this problem for personal finance. I need to make it 25% easier for the average individual to balance their checkbook on a monthly basis. You shouldn't be sending a KPI of like, maybe it also needs to reduce a person's commute time by 15% because that's not really relevant to what you're trying to solve at that given time. They need to be aligned, which in terms of relevance, alignment with each other is super important as well. This is more just to say that like KPI shouldn't really be orphaned. Most KPIs have some sort of alignment against themselves, meaning that there's either some sort of like a ladder type relationship or like one KPI would be get the other, so you need to achieve success in one or achieve success in the other, or they all drive towards the same or similar outcomes. KPIs need to be actionable, meaning you need to be able to not only measure KPIs, but you need to be able to take action on what those KPIs are. And that really translates into the ability to do different things from a testing perspective to really drive towards whatever you've defined success for for that KPI. And then finally, KPIs again need to be measurable. Most importantly of all, you need to be able to measure the success and the impact of the things that you try and the tests that you run in order to make a product successful. So KPIs are great, but how do you actually define them? It's very weird and esoteric to say that like, KPI definition is this like huge measure of success without really talking about like, how KPIs are actually derived and like what is the actual like importance of those KPIs? And so this is where we start diving into the relationship between a product manager and insights driven storytelling. I like to say that insights are our product manager's best friends. And here's what I mean by that. So, we talked about kind of our KPIs in the last couple of slides, but if you really dive down into what makes a KPI a KPI, there's this level of insight that goes into developing a KPI. And without it, your KPI is kind of flat, right? So let's take a look at some of these quote unquote insights, right? Like several users preferred the green font treatment over the red font treatment. And I think that this means that it's because green means go and our customers love to go. Some users didn't log in last week. And I think it has to do with last week being a bank holiday in the UK. I'm not sure though. Or a few paying subscribers canceled their subscription last week, likely because they needed the app more expensive. All of these insights are theoretically meant to be used to derive what an actual KPI is and to help measure and achieve success against specific KPIs. But it's very difficult to set KPIs because KPIs need to be specific, like a 20% increase in overall logins or something if you don't have specific insights to base those KPIs on. So really let's take a look at what quantitative insights look like and how they're gonna be a lot more helpful. So what if we say instead of like a few or some or like I think, you know, 50, there was a 50% decrease in logins last week, likely due to the bank holiday in UK, which affected 40% of our user base, right? That makes sense. It says, hey, like there's a very strong correlation between this decrease in logins and our overall user base because the majority of our user base was exposed to this specific thing that was outside of our control that could have impacted their ability or desire to log into our application. Or 90% capability of green font treatment over red font treatment in our AB test, right? Sure, you can speculate. It's because like green means go and red means stop or whatever, but really the core insight that we wanna drive to here is that, you know, we AB tested a group of 10,000 users and 9,000 of them decided that they liked green over red, which is a hugely important and powerful insight to use into the creation of subsequent tests or subsequent visual treatments that help drive towards some sort of a product API. Or, you know, there's a 40% turn rate month over month and keeping with our price increase timeline, which is underpacing our expected turn by 10%, right? So this tells a slightly different story than, hey, a bunch of users dropped their subscriptions last month. This is saying that while our turn rate is high at 40%, we're actually underpacing our expected 50% of turn rate and this is well in keeping with expectations based off of our pricing shift. And so as you really think about what makes the insight successful, again, it just can't be overstated how important insights are to telling an effective story. So we've talked about insights, we talked about KPIs. It is still a little bit esoteric, right? Because how do you translate data into insights? Well, I think about data as almost like a funnel, right? There's this kind of like really wide end of the funnel and then there's like this very narrow and we're like little bits drip out of it. And so on the wide end of the funnel, what you see is this giant pool of data, right? Most companies have so much data. They have more data than they know what to do with and that's fine because data is the lifeblood of information. One step below data, instead of that giant pool, like one slightly processed step of data is this idea of information. So information is a processed view of data that can start to be combined into insights, right? This is taking that largely unstructured data, structuring it and making it both readable, writable and actionable. And then we have insights. Insights are really quantitative gold and the prospect of deriving insights becomes a lot easier when you think about deriving insights as a factor of information. Again, information is this kind of distilled sense of data that is readable and understandable. And then from an insights perspective, what you do is you go into that information and start developing core metrics and you start developing core outcomes and you start putting the two and two together to make four and sometimes five, but that's okay because we all make mistakes to develop these core insights that you could then use to develop your KPIs that you could then use to define success for your product that you could then use to define your overall roadmap and your testing strategy. See how it all works together. So how do you actually navigate data to derive insights? Well, you start with the hypothesis, right? So insights are not gonna just jump out at you. You're not gonna be just staring at some dashboard and be like, aha, Eureka, I've discovered it. No, typically you're gonna have to really think about a directed way to start exploring information in order to achieve actionable insights. Starting with a hypothesis is a great way to do that. This is one of those things where you don't necessarily have to be right and it's totally okay to be wrong. And as with any hypothesis, you should really try to disprove yourself because other people are gonna try to disprove you. So it's important if you're your own first line of defense there. You know, start with your hypothesis, use some of your assumptions based off of your day-to-day, based off of your interactions with other teams, with customers, et cetera, to start guiding your exploration of information. Your hypothesis, again, doesn't need to be correct, but it needs to be compelling and that you shouldn't just be like wildly making guesses. Like really use kind of this sense of a structured hypothesis, right? Cause a hypothesis is really just like an informed assumption. So really emphasize the whole informed piece so that you're not just taking a while to stabs in the dark and hoping you're right. Number two is you look for information. Once you've developed a hypothesis, start thinking about the information that you could use to prove or disprove your hypothesis. So a great example is like, hey, I have a hypothesis about our overall monthly churn rate. So information I wanna look at is like overall app usage, overall churn rate, overall login frequency, increase or drop in like WA use or MA use however you wanna define success there. But all of these elements are just information. They're not insights in themselves, they're pieces of an insight. So number three is mix and match. Again, insights are gonna be made of a lot of different types of information typically. So you wanna start picking and choosing the information that most effectively tells a story against the insight that you're trying to achieve based off your hypothesis. Make sure you look at the information from all angles. It's really important to be able to identify several pieces of information that can ladder up to a single unified insight. Simple water. And then finally, ignore your ego. As with all things product management, you're probably gonna be wrong and that's okay. It's totally fine to be wrong. We just need to number one, admit that you're wrong and number two, work to correct your mistake. And from this, we start to realize that the most compelling stories are quantitative, honest and scalable. So back to this idea of defining success, that's this idea of insights driven storytelling. Quantitative, honest and scalable, are really great North stars for you to think about. So what do I mean by that? It means like, you wanna make sure that you're focusing on impactful problems, right? If you have a giant thing staring you in the face, if you have this opportunity to make a very minor, very boring adjustment to have an outsized impact on your application, maybe it's moving a button to drive like a 50% increase in conversion rate or something, always focus on that first. There might be more interesting problems to look at. There might be more fun things to start working through from a feature perspective. And those fun things might impact a much smaller group of audience. All right, so really think about the overall impact, the overall scalability of the decisions that you're making and focus on what's gonna be the most impactful first. That's gonna be really important, especially as you go through series of rapid iterations and testing. What you don't wanna do is move the needle a tiny, tiny bit on every massive test you make. You wanna make sure that you're using as minimum effort as possible to drive as maximal of results as possible. And that's a great ethos, just kinda live by in life, honestly. So let's wrap up. Product management, again, it takes many forms and there's a lot of X factors for success. One thing you'll see as your career progresses is that being a PM at different companies is gonna mean completely different things. You're never gonna have one unified definition of what a PM is or what a successful PM is. But there's some core elements of like moxie, productivity and storytelling that are gonna be hugely impactful and hugely helpful for you to evolve your career as a product manager. So chase your dream. If you really wanna be a product manager, you can do it, like just go out there, put yourself out there and keep seeking those opportunities. Keep applying and keep using each application as an opportunity to hone your ability to tell your story. Be proactive about defining success. Again, both at a career and a product level, it's really important for you to have a strong definition of success because if you don't know what success actually is, it's gonna be very difficult to put together a strategy or a plan to achieve a successful outcome, right? Cause you're just kind of planning for what? And then finally, above all be the best storyteller. Use all the tools and experiences at your disposal to tell the most compelling stories you can about whatever you're trying to tell a story about, whether it's why you would be the greatest product manager for an organization or why your assumptions and hypotheses for a product test cycle are gonna yield the best product possible for the market. So that's it for me. Hopefully you learned a little bit. Feel free to reach out. My email is on the deck at the very beginning. I'm very happy to answer any questions. And if you catch me on LinkedIn, feel free to connect and say hi. I'm always happy to message people. Other than that, thank you very much and have a great day. Bye-bye.