 Sometimes people think that as a product manager you actually need to know all of the answers. Well, I personally don't think that. You need to know the people that can help you get those answers. And you need to partner with those. So the first group of people that I wanted to talk about is your internal stakeholders. Now depending on the organization, there may be more or less stakeholders. But they can really help you understand that kind of business viability and understand the risks and understand how to position your product in the best way possible. So if you look at the internal stakeholders, the first thing that I would say is actually focus on customers but understand if the product provides value for the business. And I mentioned this basically. So try to understand is this product actually strategically goal oriented to what the company is trying to achieve. In terms of the financial considerations, does it fit? Speak with your finance team. Try to understand that. If you have a product marketing team, try to understand how we go about commercializing and putting this product, what is our go-to-market strategy and how does that fit again with the company goals and the company strategy. And then from a sales team, which a lot of people feel that actually sometimes they're a bit more annoying than helpful, they actually can help you identify those kind of early adopters or your beta pilot for the products that you are either creating or enhancing, evolving. And those are going to be the ones that give you feedback whether or not you are in the right track. So partner and look in within your organization to see whether your key stakeholders that can help you to different aspects that allows you to ensure that yes, this is the right product, this fits with the strategy, this fits with the goal. Ensure that the internal stakeholders have the right information. It's something that I sometimes have this and make this mistake. You make a lot of assumptions that people understand what we're doing and they have the information and when they talk with someone else, they're going to be saying the right thing. Yeah, most of the timing is not like that actually. And there is a point and you probably going to hear this a lot from different people is that over communicate to a point that you get really annoying and say, I heard that, don't need to mention it again. Because it's much better that you make sure that your message is passed clear to everyone within the organization and they pass it clearly as well to your clients, your customers, your external stakeholders, whoever that may be because at least you know that everyone is aligned basically. So one thing that I worked in a company and we were B2B type of thing and as I mentioned sales sometimes can decide that whatever you're doing at the moment is ready to talk to your potential customers and say, well, no, it's not. We don't even know if this is the right thing yet. So one of the things that we implemented is was actually to split the functionality between alpha and beta. So the alpha was the things that we're still testing that we wanted internally the organization to be aware that we were testing through some sort of discovery to gather some feedback as well if they had any. But we didn't want our sales team to actually talk to potential customers or existing customers about it because we didn't know if we get to that point of actually implementing it. And what we called as the beta, which was these are the items that you can start talking to clients. However, it is not a point that is scalable. So we're actually going to ask your help to identify some customers that maybe have a key interest in this functionality and it would be great if you can partner with them and they understand the risks involved using a beta. But before we actually going and launching it across all of our users, we just want to have that feedback. And then obviously you have your standard releases, the ones that for every customer they see it. So make sure that the communication is passed across as clearly as possible and make sure if you're working with internally external clients what is possible to communicate to external clients as well. Communicate using the right language. I was at the conference last year and I had the pleasure of taking part in a workshop with Melissa Perry and the key thing about the workshop was actually about communicating the right language, specifically at sea level. Now, in a product environment, in a tech environment, we used to certain terminology that we do on a day-to-day basis talking about metrics, which makes sense to all of us. And actually they're very good that we talk it as regularly as possible and keep our eyes on those metrics. But then sometimes we forget that when you step out of that group, the level of communication and the way that you talk to represent what are used on a day-to-day basis doesn't translate exactly the same. And you need to make sure that in order to get the buying from your leadership team, from your senior management, you talk in a language that they fully understand and support you. And yeah, that's the right thing. Let's go for it. Let's give it a try. So to give you an example, when we talk about user acquisition, for instance, which is a metric that many of us take into account, when you're talking to sea levels, it probably makes sense to talk more about revenue, which is something that they're more familiar with. Without going in specifically, and I can mention a few other examples, just take this into account. Communicate the right language, either you're talking with a developer, sea level, external client, someone in sale. It is quite important to adjust it, basically. Use what you learn from users instead of just forcing opinions. It all is all great, but I certainly have faced this many times. You go to a meeting with your internal stakeholders and say, oh, that's great, but can we do this instead and say, okay, interesting perspective, why do you think that would be better? Have you seen it somewhere else? Do you have any data supported? Has any client, any user spoken with you and mentioned it would be great? No, I just like it. I think it's better. And then a lot of the times, unfortunately, that comes from someone that has a much higher ranking to you. So you can go and say, well, okay, that's your view, but I prefer it this way. And I can guarantee you that's not going to take anywhere because you end up implementing what that person has asked you. Or you can turn the conversation and say, okay, but we actually use a test of this. We launch an experiment and we have some data to support that our users prefer this version. If you don't have that, then launch the challenge and say, interesting perspective, thanks for the feedback. What about if we go about gathering some user feedback to see which one they prefer? Or we launch an A.B. test on the live site to see which one works better. So change the conversation between, I like, I prefer, I think, to more, this is the data, this is the feedback, and this is the reason why I think it's important for us to implement this functionality or not. And this is quite crucial and I guarantee that it's something you're going to face as a product manager a lot of times. But if there's one key takeaway that I would like you to take from the internal cycle, this group is communicate frequently and clearly as possible. And it takes practice and it changes sometimes from organization to organization and it changes from people to people. Some prefer communication from my email, some prefer it for you to have some sort of wiki, some prefer you to slack immediately as soon as something is done. Just make sure you understand the best way and use all of the channels. Again, over-communicating is much better than no communication at all. The second group of people that I would like to talk about that are quite important for you to achieve a successful product is the team. Without a team, nothing gets done. But the team is more than just someone that sits there to do the work. They actually can help you understand, is this even possible? And if not, do we have alternatives for this solution that address the same problem that we're trying to address? So the first thing, and I can't remember where I read this. If it was in the same book from R.T. Kagan or somewhere else, I love this expression and I mentioned several times to my team is like, I don't want mercenaries. I want missionaries. A mercenary is someone that you basically hire to do a task, not a very good one, and they just do it, don't ask questions, get the cash at the end and that is it. And if they do a good job, you keep on asking them to do more and more. A missionary is someone that is on board, that understands the reason why they are doing things and understands what is the ultimate goal. And if they're having a coffee with a colleague and their colleague asks, oh, what are you working on? They can actually explain what they're working on and the reason why they're working on. So they spread the word. And that person may say, oh, that's an interesting aspect. We're actually doing something similar. So let's see if we can take lessons from each other. So the team should not just be the people that you go to and throw user stories at their end and ask them to do things. It's part of your success as a product manager. And they should have the clear visibility of what is it that you're trying to do. They can help you understand the visibility, as I said. Better than anyone, they will be the ones that help you understand the risks around it, either from a technology point of view, from a time point of view, from a skill set point of view. I mean, I have faced times over and over and even at voucher codes where we actually look and say, actually, this is the kind of solution that we wanted to implement. And I had my tech lead saying, well, we don't have the right skill set to do this, but we can use this technology which achieves 80% of what we would like to do and then looking and saying, that's fine. And I can also give you an example where we identify an opportunity to improve performance in one of our internal products, but the technology that we currently possess as a voucher code doesn't allow us that. And the cost involved to getting that technology would be quite expensive, which is not business critical, taking into account the improvement we're going to get. But is your team with their skill set that know how, and because they understand the solution or the problem that you're trying to resolve, that we'll be able to give you that input, basically. And then, collectively, you can make a decision. Is it worth pursuing or is it not worth pursuing? Oriented towards outcomes instead of outputs. So this ties very closely with the first one that I mentioned and is about working in your team to ensure that they help you understand the best way to solve that problem. A few weeks back, can't remember exactly when, Tom Barber from TripAdvisor actually did a talk here and he was specifically focused on the topic about focus on the problems. Those are the things that will help you achieve the most successful problems. It's not about the solution. It is not about how pretty it is. It is about the problem. Are you actually trying to solve a problem or are you creating a problem to begin with to then create a product? And if you understand the problem and you explain that problem clearly to your team, they can help you understand what is the best solution. They can probably help you understand if there's two or three possible solutions and you guys can collaborate and then find which one is best to do it right now. And if it is even worth implementing the full solution, we'll just go for 20% and see how it progresses and then carry on. So work with your team. They are very resourceful on that. Martin Geiger definitely mentions about engaging them as early as possible and as much as possible. Driven by continuous improvement. This is something that I actually take on every team that I work with. We do the standard retters at the end of each sprint, which we focus on actually what happened within the sprint. It's absolutely fine. What I found out is that actually it doesn't help us to understand how are we doing as a team? Is there anything that we could change? And I found that in the standard kind of scrum agile, we didn't have a forum or a space to do that. Yes, they could easily do, but unless sometimes you create the opportunity, no one is going to speak out. So what I do actually with my team is every couple of months, we have a team meeting. And it typically goes about a kind of retro, which I actually love right, retros by the way. I find it absolutely amazing to try to understand kind of things that you can improve. But it also gives the opportunity for us to open up the question and I ask them, do you guys have any suggestions on things that we should try, changes that we should make? And it could be in our processes and our tools and the way that we are organized. Should we move desks because it makes more sense? Anything. And we have done that. I'll give you an example. When I joined, my team was working on a pure scrum methodology. And I didn't find that it was very efficient. Reasons aside. So I actually spoke with them and say, shall we try a scrum band approach? Kind of mixed scrum with mixed hand band. The reason being because as an organization, they still are doing scrum across all the teams. So we didn't want to lose that kind of two week sprint and the retrospectors and sprint planning that every single team does. But we wanted to have a bit more flexibility. And we discussed and we actually agreed, let's give it a try. And we stayed with that for the time being. We also changed some of our processes. There was another topic where we discussed in terms of actually our Jira board, which a few people felt that didn't provide the right visibility. So as a team, we kind of discussed how we would like that Jira board to look like. And it made tremendous improvement for the entire team. So not only look in terms of how your team can help you with your product, but keep on challenging and keep on opening their minds that they should collaborate and contribute for the constant improvement of the team as much as the product on an ongoing basis. You want them to excel. You want them to feel empowered and you want them to feel in a position that they can speak out about anything. Key takeaway. Involve the team as early and as much as possible. I didn't specifically talk about this point, but as I said, they can help you understand the feasibility. Some people feel that you know it's a waste of time. What I've seen from practice is that if you involve them early, then they understand better the problem. It means that in terms of the solution they implement, it is a lot more leaner, is a lot more efficient, because they know the reason why they're doing that. The third group that I wanted to talk to you about is actually users. These are the people that you're actually building the product for. These are the people that have a problem that you're trying to solve. And I don't like to term users. As I said, I'm here to talk about people. And the first thing that I do is make sure that everyone in the team, whoever it is that is creating stories, doesn't create as a user, I want this. I want an actual person. I want to understand who that person is, what their problem is. The users, A, they can help you understand the value risk. Well, they actually use it. And the utility risk. Do they understand how to use it? As I mentioned, users are not numbers. It is very common for a lot of people to focus on those metrics that I was talking about earlier. Click through, bounce, et cetera. You have a bunch of dashboards. You have some that collects all of the inputs from social media. Are they liking our products? Are they not liking our products? Is it green? Is it red? Is it whatever it is? And you just end up focusing on data and numbers and spend quite a lot of time digging into why that went up by 2% versus 3%. But actually, your products are for people. So absolutely look into that data. But ultimately, talk to the people that are actually using or are meant to be using your product. They, better than anyone, can help you understand if there's still issues or if they like it or not. So, I will give you an example. Recently, we were looking at optimizing functionality with one of the one of the pages for mobile. I won't go into details because we're still doing quite a bit of testing around that. But we launched an A.B. test. Everyone in the team felt, oh, this is really good. I think it's going to be positive. It was bad. It was really bad. All of the metrics were negative and really bad. And we couldn't understand it. I mean, it did look great. So we use user testing.com, which I'm not sure if any of you have used. So it allows us to put up some prototypes very quickly and gather some feedback in terms of what people think about those. So I kind of put up on user testing.com, the prototypes, and I asked a few questions around it to try to understand why that was so bad. And the feedback that I got was so shockingly surprising. Not because it was nothing that we had not thought about it, but because we had been working on this for quite a few weeks, we know the product so well that we actually missed some of the obvious aspects. So for us, it was a particular functionality that it meant at the end, clicking and converting. We just did that so mechanically that we missed out that along the process we made it confusing for users that are not so familiar with the product like we are. So when we put it on user testing.com, they pointed out, oh, I don't understand. What is this information? What is this meant to do? Where do I click? We actually made it more confusing, thinking that we were making more simple. What's simple to us, they use a product today, but for the users, it was actually a lot more complex. And the reason why we could find that was because, well, in this case, we didn't spoke directly with them, but we had that verbal communication from them. They will help you understand if the product is valuable. Does the product actually make their life easier? Ultimately, that's what you're trying to do. It could be a simple task that they no longer have to do on a day-to-day basis. And it could be something more complex. But if it is for them that you're building a product, if it's for them that you're creating a functionality, then make sure that you speak with them to understand does this actually help or not? However, what they say, oh, sorry, I was going to think it was the next topic, but what they say, they like it or want, not only is it a representative reality. And I'm not sure if any of you have taken part in focus groups. I've actually done both, so been part of a focus group and assisted to focus group. And it always struck me fascinating because sometimes there's a person that is quite outspoken in a focus group and they start talking, oh, no, I like that because of this, this and that. And then there's someone who says, well, you know, I'll follow and say, yeah, it makes total sense. And then suddenly you have the majority that thinks that way and then the ones that are a bit more shy end up just jumping in a green with it because they tend to be a bit more reserved and they want to belong. We all want to belong in the group that we are part of. So it's kind of a natural reaction. But in effect, some of them don't actually like it and think differently. And it's very hard to understand if that's the minority of the users or actually the majority of the users. So when you're talking to users, remember that sometimes what they tell you may not be the reality when they're the comfort of the homes, doing some shopping, trying to find the discount. It may not be the exact same process. So unless you can actually watch them and be there with them, make sure that you speak with a wider group of users that they're different spectrums and they interact differently to get that sense of, does this check? Is it really true what they're saying or not? And don't forget, ultimately, they also don't know what is possible or not. We work in technology, or I assume we all do. We kind of have a rough understanding what is possible and not to do nowadays, but most of the users don't. So if I was going to say to someone, you know, oh, I can see that once this job finishes, you press this button to start this job. You know, that would be great. What would make it easier? They can say, oh, can I just get a pop-up when this job finished so that I really know that it has finished so that I press the next job? That may be the solution for them, but you can actually say, well, what if I automate the process and don't ask you to press that button to begin with and one starts as soon as the other one finished? A lot of them is like, oh, you can do that? Oh, that's amazing. So don't forget that a lot of the times they don't even know. One of the things that, you know, more recently we've seen, I don't know if you know, and I actually had to Google this, but Amazon basically, their motto is build a place where people come to find and discover anything they want to buy online. Now, if you were going to ask that, okay, when you're trying to find something to buy online, how did you go about? So, okay, I'll open the website. There's usually this kind of white space that I can put something, what I'm searching for. I press the search button, I get a list of results, and then I try to find the one that I like most. Okay? What about Alexa? What about that voice search? If they probably would never thought that it was even possible, but it's becoming more and more popular nowadays. They just talk. So coming and saying, well, what if you don't have to type it? What if you don't have to press that button? You just can talk normally and say, find me this. That's amazing. So, again, don't forget that sometimes what they tell you that it would like to have, it's because they don't know what else it's possible, and it's up to you to try to figure out where your team, et cetera, et cetera. The key takeaway of this is that look behind the data and talk to users. Better than anyone, they'll be able to make sense of those numbers going up or down. So I talk about internal stakeholders. I talked about your team. I talked about your users. And some of you may say, well, that's it, basically, right? Well, not really. Yourself, basically. So we spoke about the four risks and how you can help to partner with people, to address or understand those risks a little bit better. But there's one key element in all of this. It's yourself, a product manager. Are you inspired to achieve great accomplishments? You are the glue in the middle of all of this. I was at a conference last year and Martin Erickson opening speech was actually about the imposter syndrome. And this was a room full of product managers, and he basically asked, how many of you feel like an imposter? And I always felt like that, but you're not really allowed to say it out loud. You feel that that's not great. And it was surprising to see that everyone just raised their hands. I was like, okay, it's not just me then. That's good to know. So I actually have a definition of imposter, taken from Google. It's an individual that doubts their accomplishments and has a fear of being exposed as fraud, despite evidence of their competence. It happens to us all the time, or at least it happens to me all the time. And it's actually all right, because we are surrounded by people that are specific and very skilled in an aspect. Either they're great UI developer, or a great UX, or a great backend developer, or a great QA, so they have a very specific skill set and they're amazing at what to do. But sometimes we feel, well, actually, what is my skill set? I don't really know. I say this as a joke, but some of my friends ask me what I do and say I'm just a human outlook. I basically just forwards emails back and forwards. And that kind of ties me to feeling a bit of an imposter. You know, if I'm not there, they don't really need me. Well, let me tell you something, they do. Because if you were not there, all of this conversation between all of the people that take part of building a product probably wouldn't happen. Or if it did, it wouldn't happen the most efficient way. So you do have a skill. It just may not be so easy quantifiable. Beagle-focused, value-guided, and data-informed. As I said, remember your company's strategy, your company's goals, is the product that you're looking fits into that. The values as yourself, as a product manager, or as your company. And we've seen some news recently about some companies exploiting data, for instance. I personally, as a product manager, I don't think I'll feel all right to create a product that does that. But I'm not going to go into that debate. But just make sure that whatever you're doing fits with your personal values, your company values. And be data-informed. Use the data, obviously, in your advantage. I'm not saying don't use any data. You know, if the user has given consent for you to use it, then do it. It's absolutely fine. Explore different techniques. Challenge yourself. There's so many different techniques. I mean, you can be involved in user research. You can do maybe testing and experimentation. There's jobs to be done, which I've actually been dying to try out in my current company. But there's lots of different techniques that come up every time. So it is actually important for us as product managers to keep up-to-date what's going on in the product world. But as well, give it a try. Because what works in this company? What works in this product? What works in this team? But no, work in the next. And vice versa. So constantly do that. Ask a lot of questions and learn to say no. As I mentioned, we kind of interact with different people. So we interact with different people. And the point is, because you ask the questions, you're really that annoying kid that says, why? Why? Why? Why all the time? And at the same point, just tell no. I had someone coming today to me and ask me for a second. I'm sorry. I am annoying. But that, considering everything that we need to do for the next quarter, is just really not fitting in. You're not selling it to me. It doesn't drive any revenue. It doesn't help the users in any way. I know it helps you. And I would really love to help you. But at the moment, that is one concern and one problem in a series of other major problems that I'm trying to address. So sometimes you have to say no. And trust me, sometimes you have to say no and say, that's not going to work. That is not a good idea. Only in your mind that is going to work. Obviously, when you have those conversations, don't just do it as gut-filling. If you don't have the data to back you up, try to get that data first. But learn to say no. And build personal resilience. I mean, having people constantly all the time asking for things to do. And then you tell them, yeah, that's fine. I'll put it in the backlog. I was like, oh, I know what that means. It means you're never going to do it, isn't it? Well, yeah, kind of thing. But sometimes it also is the point of you create an experimentation, you spend a bit of time doing it, and then the results just are not great. So it does take a toll. You do get a lot of hits and bumps along the way for a multitude of reasons. And you have to learn how to build that personal resilience and to persevere and keep on trying and trying and trying and trying. And I can guarantee you that if you're right, it's the right questions. If you're around yourself with the right people, you focus on the right problem to solve, you will succeed. And set up some personal goals. Either the goals that from a career perspective, you're looking to achieve, it could be the type of sector that you're working for, or it could be something a little bit more, I want to run a marathon, whatever it is. Because your products have a goal and you're trying to address your problem, sometimes it's actually good to distance from a user's problem and spend a bit of time focusing on your own personal goals. What is it you're trying to do for yourself? As I said, either in your career or as your personal, to kind of have a little bit of break, to just stop focusing on that product and focusing on yourself. It does allow sometimes to come up with these crazy ideas when you're just giving that bit of time to relax. Share what you learned. I'm doing that today. It is my first time. I actually was having a conversation with someone at the work the other day. Well, that person is no longer working in the company, to be honest, but for different reasons. And we were talking about, you know, coming to meetups like this, and I said, oh, actually, no, I would never like to present. I said, well, interesting, why do you feel shy, afraid of talking to bigger audiences? I said, no, because then I would be talking about the things that I learned and I wouldn't have an advantage about people that don't have the experience that I have. And I find that quite sad, really, because I learned so much from other people that have a lot more experience or less experience, but have a different perspective. And I'm more than happy to contribute to help you guys in any shape or form that I can or anyone that I interact with. And I find sad that someone just prefers to bottle up all of that knowledge and not sharing with anyone. So you don't have to do it in this way. It could be someone at your work that is trying to step up into a product role. But try to share a bit of what you learn from your experiences. It's great to see people grow as well. And they will help you grow along the way. The key takeaway that I would say is dedicate some time to yourself to think, to learn, to evolve. It is important that you have a good balance between what you do professionally and what you do personally. And you allow your brain to disconnect a bit to rethink, to reevaluate. And sometimes you have different perspectives to do problems because, again, taking the example of the experimentation, sometimes you're so embedded into it that you forget the simple things. And by allowing some time to yourself, you then become more aware of those simple things. One last thing that I wanted to share. Actually, it's an expression that I learned from an expedient and it was repeated a lot of times. And I keep on saying that throughout every company that I work after that is that I always said, you know, hold on tightly, let go lightly. And I find it that absolutely amazing, which is, like, fight your battles if you really have a strong conviction. Make sure that you come across why and you back that up. But then if for some reason that's not a direction to the team, the company itself decides to go, or if it hasn't worked, just let it go. Move on to the next stage. There's no point of you thinking back in terms of, oh, what could have happened if this has gone, it's not gone. It's like, it's a waste of time. I'm telling you, it's a waste of time. Move on to the next, basically. There's a lot of challenges ahead of you. There's no point of thinking about the past challenges. And to finish it up, I love this quote from Brian Kramer. It is not, it didn't say it within this context, but I love it so much that I decided to put it here. There's no more B2B or B2C is human to human. It is quite important to create those level of relationships, as I mentioned, across the entire organization at different aspects, your stakeholders, your team, your users, the people that you interact, those are the ones that will help you achieve successful products. As I said at the beginning, I personally don't feel that the product manager needs to know all of the answers, but it should know the people to talk to to get those answers and have the correct information in order to build those products. And that's why for me, people, and remembering that it's all about the people, it's something that I want to talk to today instead of all the products that I've worked on. Thank you so much.