 Hello, everyone, my name is Flavia and I'm currently Director of Product at Spotify. Right now, I'm based in sunny Barcelona, but before landing here, I worked in Portugal, Ireland, Silicon Valley, and spent most of my career between product growth and product management. I worked in startups, scale-ups, and in larger orgs, which I think helps with this conversation, both as a full-time employee as well as an advisor. At Spotify, I'm part of the experience mission, which is responsible for the whole mobile and other platforms' experience and where most innovation happens. And today, I want to share some thoughts with you around the unknowns in product management. I think you'd be surprised with the number of people I come across, product people, that want or expect predictability. And this always scares the heck out of me because, in my opinion, product management is everything but predictable. The environments, the variables that we play with are rarely controllable, and there's always an almost infinite amount of known and unknown unknowns that we have to deal with. So being a product manager, or a good one for that matter, means accepting that uncertainty comes with a role and also learning how to navigate it. We only have 20 to 30 minutes today, so it's impossible to explore every dimension of this topic. So instead, I'll share the recommendations I find most useful that I think are less talked about and that can be applied in various different settings. So let me start by defining uncertainty and the tools we as product people can leverage to chart our way into building impactful products. I define dealing with uncertainty as being in a situation that requires a decision for which you have considerably less information than you need for the decision to be obvious to everybody involved. No results are guaranteed for sure with any product decision because users and markets have way too many moving PCs for anybody to be able to kind of express the logic of all the dynamics at play. And unfortunately, there's no one plan that fits all the challenges or that can guarantee good outcomes. But I do believe, though, that there are some strategies that can improve the odds of building great tech products. So let's start from the beginning. You don't have your product yet or you're fundamentally reimagining it. These situations and especially the prioritization process are like charting your path in a heavy fog, right? How many times have you found yourselves in a situation where you were asked to make a decision with limited to no information? I think the majority of us have been there. And there's a great deal of uncertainty that we have to deal with. So let me talk about some tips overlooked most of the time on how to navigate this. The first one is frequently talked about, but I'm putting a spin on it. One, move quickly to get a first rough iteration in front of users to start getting high quality data back. This is the old question, should we explore to build or build to explore? Well, first and foremost, you need to know what your problem is. What you're trying to solve and what goal you want to achieve. This is where research, qual and quant is essential. So start by using data to frame the problem, define your goals, create the hypothesis to test, but then pedal to the metal. Don't spend your time doing very complex analysis, planning all the details and working out a perfect plan just built to explore. And the reason why I say this is because it is key to move quickly and get that first iteration in front of your users so that you get a flow of high quality inputs that will then help you refine, redesign your strategy and or your roadmap. And now you ask, but aren't we all doing that? Isn't that the like the most important thing in product management? Yes, a lot of people talk about this. And I think we've come a long way implementing this advice when it comes to delivery. We no longer or a lot of companies no longer think and work six months on something and then put it in front of users. But that's primarily thought for the delivery process, the delivery track, not so much beforehand. And I still see in a lot of companies, teams spending an awful lot of time planning and re-planning and analyzing everything before actually committing to do something. Whereas I think that it's much easier to build something and then explore. What did you get from that experiment or whatever you put in front of users? What are users telling you and how can you refine work? How can you set the next goal? Obviously, by saying this, I'm not saying don't plan. Don't think ahead of time. We have to think ahead of time. But our thinking should go into creating the right hypothesis, should be into creating the goal, making it abundantly clear to everybody around us. Let me tell you a quick story. A few years ago, I was asked in an interview process to define a long-term roadmap in what I think was an awful lot of detail. And to be very transparent, I knew very early on that there was no cultural fit whatsoever, but I decided to use that process as an opportunity to see how set companies were on this way of thinking. And also if I could change them or change their minds, I couldn't. And so I challenged them and explained how doing back of the envelope calculations supported by either an existing data or way too many shaky assumptions would be useless. Think about it. If you come up with a plan that relies on 20 different assumptions and the 20th relies on the first, 5th, 10th, and then you start your process and the first one is not true, then what happens to the 20th? You kind of have to revisit your plan. So you might as well put all your effort into creating that first assumption or hypothesis or first couple of hypothesis, having very clear what the goal is and then take it step by step. At the end of the day, we're not supposed to be futurologists, right? We're product managers. So to sum up by moving quickly and creating a flow of high quality inputs will help you pave the path forward. It doesn't, however, make the path 100% clear. It just helps you kind of navigate and create the path step by step. So the best advice that I can give you is to accept from day one the uncertainty and the long odds. Is it easy? It's not humans have been using categorization and classification as ways of understanding something unfamiliar and also making decisions for centuries. So you can see that it's very easy to fall into the temptation of organizing, planning, classifying, to feel safe and in control. However, endless hours of that planning will unlikely change the odds. But what it will do is give you probably less time to iterate. So going back to the role of research and bear in mind that when I talk about research here, I'm referring to both qual and quant. It should never be used to soothe our fears, right? Or internal fears, but to advance the discovery to help us generate realistic hypotheses and a plan to test them. So make sure that you intentionally recognize and accept that most of the time the path isn't clear and the path to a successful product comes from standing on a pile of failed tests and iterations that hopefully will help you move forward. So if you are desperate because you have ran 10 different tests and neither of them yielded the results you were expecting, don't be discouraged because you can learn so much from those and it will help you if you look at them the right way to actually move forward. So you shouldn't fear failure, but instead embrace it, accept that the path isn't clear that you will only be able to see one feet ahead of the time. So be humble, nimble, learn as you go, iterate based on your learnings and take one step at the time. Lastly, I know that the unknown is very scary, but and that the majority of the time we don't feel like we can be cheerleaders, but it is part of our job to keep everybody motivated and with their way their eyes on the future. It's certainly daunting to look at the odds, especially if you work in a startup. You know what I'm talking about. And it's also daunting to look at the decisions that need to be made in the midst of so much uncertainty. But the truth is, and I hope that this helps you, most great tech products started from a similar position. They all have their own unique, incredible stories. But I think what unites them all was having one, a capable team, two, being very relentless in their pursuit and third, iterating just long enough to have to get an incredible product out the door. And as product people, junior or senior, we play an outsized role in keeping everybody motivated, aligned with the goals, knowing exactly what their role is to get to where we set ourselves to go so I can't stress enough how important it is to keep the team motivated through these difficult times of uncertainty. And I'll tell you a story. A while back, I was working with a team that was fundamentally broken. They were not broken, the whole setup was. And I'm not going to lie, I had my doubts. I could turn things around, but never for a second, I let others see it. After we went through that transformation, a lot of people, I had this conversation with a lot of people, but I specifically remember an engineer that came to me and said that oftentimes he was 100 percent sure, convinced that there was no solution to the problem that I was giving them. But he saw me so confident, he saw that I was looking 100 percent convinced that there was a solution that he'd never gave up. He was trying, going to try and find it out. Was I convinced? No, absolutely not. Most of the time, I didn't even know if it was possible, but I didn't let them know that because I wanted to instill confidence so that they would believe they could find a solution and to that difficult problem. So long story short, a happy and a motivated team can move mountains, but a paralyzed team could be the end of your product or your company. I've seen it. Trust me, you want to motivate your team. OK, so we talked about the importance of moving fast, accepting uncertainty and also motivating those around us. What else? Let's talk about data, which is something I think we usually turn to when we don't know what the future holds. I'm sure you've heard before that good product managers have to be data driven. Well, as somebody highly analytical who loves your data and uses it to make decisions on a daily basis, if I'm honest, I'm not going to tell you otherwise, it's incredibly important. Now, the art is one, knowing when and how to use it and two, to strike the right balance between the two extremes of 100 percent intuition driven decision making and the other polar opposite of fear induced paralysis, because for whatever reason, there's no solid data to go to work with. So I'll share now some pitfalls. I often see PMs falling into first one, proving assumptions. When we start recognizing familiar patterns and we can tell what seems like a reasonable story, it's easy to get complacent. And the reason why I say this is because sometimes something feels familiar. We write a narrative that sounds plausible. And before we know it, we are unintentionally planning our tests to make sure that it holds true. So while most product managers work to prove their hypothesis, I recommend that you focus your efforts on disproving them instead. After all, after all, if even what is a stable user behavior or a trend today might not hold true in a couple of quarters, COVID being an extreme example of that, shouldn't we challenge our deeply held beliefs, our assumptions, whenever possible to make sure that we're still chasing the right thing? I think so. So when we're prioritizing writing our hypothesis or planning our testing phases or anything related to the whole planning process, our goal should always be to prove that our assumptions are wrong. I know it might sound weird, but think about it for a second. If after trying to disprove your hypothesis, it still holds true. Shouldn't you have a better chance of being in the right path than if you had invested everything you had to prove the plan? I think you do. So in my daily practice, not only do I ask all the squads to plan experiments that can prove their assumptions wrong, but I also ask everybody to poke holes in my strategies or plans. These days, I don't spend as much time planning experiments or those sorts of things, but I do spend a lot of time thinking about the next big thing or putting together a strategy. And the one thing I do is ask everybody to poke holes in my thought process. And the more I believe in it, the more I want others to find potential problems because I know my bias and my will to make it work can make me blind. So I want them to go read the document and then based on what they know or even instinct tell me I don't think this is going to hold true or I don't think this is going to work out because I know this data point and I know that happened in that experiment or I know that in this specific step of the funnel, this is happening. And yes, is it tough in the early days to do this? It is. I remember feeling it's thing a little bit when I started doing this and asking people to criticize the work that I fundamentally believed in. But then I realized a few things. One, I might as well fail now than later on. The result is the same. Somebody saying that something doesn't end up now or me finding out made me go through the delivery process or even after we put it in front of users. The result is the same. I just I just learned earlier, which allows me to kind of plan differently. And second, our job is not to be right all the time. I know that it feels like we should be, but we're not supposed to be right all the time. So if somebody can poke holes, it doesn't say anything about your quality as a product manager. Actually, if the way you react to that says a lot about who you are and as a professional and how far you're going to come. So stay humble and question everything and learning and giving up on strongly held beliefs takes humility. I know that, but it will make you a much better product manager. And your journey will be a lot easier because you can anticipate problems. You can start the delivery knowing with the better chances of actually succeeding. OK, so now imagine your experiments disproved your hypothesis or that the experiment just didn't give you any meaningful information. And now you don't know what to do next. Please do not stretch the numbers to tell a beautiful story and don't jump to conclusions who here has looked at the data of a fail experiment and felt tempted to slice and dice the data a hundred different ways and come up with a convoluted narrative of what users were telling us through the data. I sure have the majority of us have, but data snooping while it can be a useful tool to iterate and define next steps. If it's it's flawed, right? If the data points are not coherent or even sometimes when they are, you might just be looking at noise. There's no there's no narrative. There's nobody's telling you anything. So the solution to deal with uncertainty is to do more discovery, to dig deeper, to chart a path to the learnings that will drive the strategic decision ahead, not find patterns where they don't exist or jump to conclusions just because it makes our lives easier. So it's key to have a good sense for when you need to repeat the experiment or when to continue to experiment to make decisions that ultimately stand the test of time. Finally, Phil Carthagoras saying that you don't have enough answer to answer. You don't have enough data to answer the question. While it might not make you popular, been there done that, I'll tell you a story in a second. I assure you that you will read the benefits down the line. So let me tell you this story. In my previous company, there was a time where when we started seeing our KPIs declining quite aggressively, PENIC was installed, my peers all got together. And in a matter of hours, they came up with a list of actions to fix the problem, to solve everything that was happening. And I got everybody nervous because every time they asked me, I would say, I don't have enough information about the problem to design a plan of action. So I had colleagues reaching out to me privately, showing concern about my ability to do my job and asking if I wanted help, if I wanted them to do it for me, because somehow I wasn't able to do it. And I thankfully declined and explained that I just needed a few hours to dig through the data to really understand what was going on. If you ask me, everybody looked really smart, except for me. I looked like this idiot who didn't know what she was doing. I kept hearing comments and people talking behind my back about whether or not I was going to keep I was I was going to be capable of doing that. And why wasn't I capable of doing that? If I was running the whole show in a specific area, so I should be able to know what levers to pull in order to achieve what we wanted to achieve. So it was it was it was hard. It was I didn't like it, but truth is it was the best decision that I made because there was a plan for each person in the leadership team. There were squads being asked left and right to do certain things. Whereas I had nothing. But the answer gave me a couple of days to really understand what's going on here. And that was tough. That was a tough period. But by the end of that exercise, not only those initial plans that my colleagues put together were not used, not because they don't know how to do their jobs, but because they didn't really understand the problem. And therefore those solutions were were not usable for that specific situation. But I had to sit with them and explain what was going on for them to then go their way and figure out, OK, I know what the problem is. This is my area of action. This is how I how I can contribute to fixing this particular situation. So my message to you is the loss of trust by stating something that is demonstrably false is really hard to learn back. So try answering the queries you don't feel comfortable answering with. I will look into it. I'll come back to you with with an answer or a plan on how I'm going to get that answer, or I don't think we have data for that yet. Here's why and how I'm going to go about fixing it. And when you feel pressured, because there will be a situation where you're pressured to express your opinion, be careful and state it as a hypothesis and how you would test it. So instead of saying, this is what's happening, say, hey, based on what I know, which is kind of limited right now because of A, B and C, this is my hypothesis. And this is how I'm going to go about proving or disproving it. So intuition has its value. You have to develop product intuition. You have to use your intuition throughout your career. But it's usually a lot less valuable than most people give it credit for. Bear with me, we're almost there. Last section, dancing to the tune. So product management is a dance between paradigm breaking changes and optimization or expansion of existing offerings. What we do and which side we invest more or less on depends on the end goal. What we're trying to achieve, what is it that we need to do for our business? So let's talk a little bit about strategy, optimization, how to identify the need for a paradigm shift and how to innovate without building a Frankenstein product in the process. So there are many tactics that I use to navigate the unknown. But if I had to choose the one thing that makes the process easier other than first accepting that there is uncertainty, there are long odds, it's tough, is that is having a North Star and a strategy. No matter how unclear the path is, if you have one North Star or a good strategy guiding you, you'll probably make better decisions or more good decisions than bad ones. And because, you know, you know at all times that regardless of the situation or how you want to what you want to achieve, what is it that you're striving for? And by knowing that, you can see how the several options that you have. So you have A, B and C, you know what the North Star is. You can better gauge what impact that the several hypotheses that you have will have on your North Star objective you have. So if there's one thing that I recommend that you do is having that guiding goal that you can always fall back on in case of doubt. Now, assuming you have that, you know what you're trying to achieve, you know what the business is for, you know what the business is trying to do. Generally speaking, then you're probably faced with probably one of these two scenarios, either you're in a zero mode, so conversion rate optimization, you're looking for an uplift or in innovation mode. So let's start with the first. You're chasing an uplift and you're not sure where to invest because it's unclear, it's unclear where you can actually optimize. The most likely place to find the next positive outcome is in an area where you just succeeded and certain needs usually lower. The potential is a lot higher where past iterations generated a significant uplift. So if you find if you found an underutilized area where there are multiple opportunities to explore and you have already some learnings that can help you make better decisions, double down. This will help you with prioritization, even if and it will make you partially blind to new opportunities because it steers your attention only to small marginal improvements. So don't be afraid to invest further in an area that you know is under optimized. Just make sure that you keep your eyes on the overall goal and that you don't go on, you don't go down the rabbit hole of going overboard in the attempt of squeezing that last point zero one percent in that little step of the funnel that you've been working on for four months. So if it's very unclear, your objective is to optimize. If you know that there's an under optimized area, that's probably going to be your best investment because you already have data. You already have some information to guide you. Just make sure that you don't be that you're not completely blind and just obsess about one single thing that you need to improve to the max. But at times it's not about optimization, right? Sometimes it's about innovation or it's a mix of both. So one thing to pay attention to are the signs that a paradigm shift or change in focus is needed. So I collected the most three, the three most common signs I've seen in my practice. One, your positive impacts become less and less frequent and or margin marginal increments reduce over time. Second one is the majority of experiments that you run actually return significant negative impacts. This normally means that you have arrived at a close to optimal stage in the current paradigm and three, it becomes very difficult to do discovery and come up with hypotheses that do not require a large rewrite of the user experience. This usually means that your current paradigm is kind of locking you in and you need to look elsewhere. And finally, if you're shifting your focus or planning a more fundamental change to your product, you also have to be careful not to build a Frankenstein in the agile world we live in. It's super easy to think that any hypothesis that needs more than two sprints to be put in an experiment should either be deprioritized or broken in chunks. However, this does not apply to larger changes in EWECS as a Frankenstein mix of the current state and the proposed state are not usable. I'm sure you've either been in a situation where you were you had to make this decision or you use the product that was in this process of completely reimagining how the entire functionality and you had a mix of the old and the new and nothing adds up together. So that's what you need to be careful of. And then obviously, small iterations are always preferable, but ultimately, the new proposed state needs to be super functional. So we need to be realistic that changes in paradigm carry uncertainty and risk, not only because you disrupt the value that you are delivering right now, but also because you need to invest more than you would for a couple of small tweaks to the UI, so you have the experimentation cost and the opportunity cost together and you and your teams need to go in cognizant of the challenges and determined to be dead. So just be aware of this and then you're set for success. So to summarize what we discussed today, first and foremost, accept the uncertainty can't stress this enough. You won't change it so you might as well embrace it. Also, build to explore and not the other way around because you'll learn more and faster, make sure everybody is motivated and might feel difficult at times, but it's crucial for success. And then data is very important, will always be very important so long as you know when and how to use it. Don't overestimate what you know and always challenge your strongly held beliefs and don't stretch the numbers to tell a story. Don't jump to conclusions. Don't try to find patterns that don't exist. Might feel easier, but long term, it won't do you any good. So feel comfortable saying that you don't know yet that you're going to have to explore because earning trust once lost is really hard work. Have a North Star that can guide you through the toughest decisions you'll have to make. And if you're in an optimization mode, double down your investment in areas that you know are under optimized and where you already have some knowledge. Watch out for signs that a paradigm shift is needed. So get the product in front of users as soon as possible, but avoid building a Frankenstein product. That's the last one. And I know that being a PM in the more modern days isn't easy, isn't an easy job, but it's incredibly helpful feeling when you know how to navigate these challenges. So have fun more than anything else. You know all of this if you're starting your career, if you're in the middle of your career or you're very, very senior. I think the best advice of all is just have fun. Building products is amazing. I think it comes down to how we approach the problem. I've been in situations where it was hard. The setup was not in my favor. And I found a way of seeing light at the end of the tunnel. So have a lot of fun. Make sure that you bring people along with you in this journey and just build crazy things because that's amazing. That's an amazing opportunity that all of us have as product managers. I hope this was useful and that you can implement some of these tips in your daily practices around. So if you have any questions, feel free to drop them in the in the chat or reach out by email, you have it in the in the presentation. So reach out if you have any questions. And thank you so much for listening. It was a pleasure being here and I hope to see you soon in the chat. Bye.