Giving Product Direction With a Product Strategy - Nacho Bassimo, Director of Product @Xing

Hello everybody. Today Alex and myself talk to Nacho Bassino about the topic of product strategy. We talked about defining a product strategy as well as making sure to communicate it in the right way and guaranteeing that it gets established in the company. Alex, what was your highlight of today's conversation? I think the conversation itself was probably your highlight, right? As you're the one deeper into product strategy conversations than I am. I think obviously one thing that I loved hearing as well was also the example around how product strategy can influence a whole company's direction. And I think it's like also important to look at it and to look especially around like the collaboration and the stakeholder management, bottom up and top down. But yeah, if you're interested in learning more, you should listen in. Exactly. And as always, a short reminder, please take a look at our social media channels and share this episode if you like it. And with that, I would say, let's get started. Hi Christian. Hi Nacho. Hi there. Cool. Before we jump into our conversation as usual, quickly a few words on our guest today. So Nacho is calling in from far away. He's in Mexico and his background is he started his career as a developer initially in Java. Then from there, he moved on into becoming a product owner and then finally made its way into product management overall. Today, he's the chief product officer of Best Day Travel Group. But besides that, he's also very active in the product community. So he himself is also hosting a podcast for the Latin American market. So for all the Spanish speakers that might be listening to us, you can also check out his podcast directly. And besides that, he also co-founded the product bank for Cancun. He was also a professor on the product management executive program for the Universidad de Palermo. And he also wrote a book and the book is called Product Direction. And it's talking about how to build products at scale. And in that book, Nacho touches a lot on like strategy and how to then translate it through roadmaps, objectives, OKRs, key results, and so on. And this is also what we will talk about today. Nacho, maybe you can also share a little bit like why product strategy is such an important topic to you. Thanks for that introduction. First of all, really happy to be here. Thank you for having me. And yes, I can probably talk about why product strategy was important to me was because when I started as a product leader, I found a lot of, say, theoretical material or high level material that didn't want into the details that I need to actually implement it in my organization and connect it to teams execution. Through my writing, I found that problem resonated with many people. So I wanted to consolidate my experiences. Awesome. What was the most important message, if you would need to summarize it of your book? I think that the most important message is that product strategy is probably the most important thing a product leader can do besides coaching and developing their team. And that is not something reserved for the enlightened. It's something that can be done through practical approaches and tools. And that's what I'm trying to share. Mm hmm. Beautiful. And why do you think is product strategy such a vital and central part also of being a leader in the product space? I think our role is to align teams to actually achieve the product vision or the company vision, actually, as well. And the strategy is how we come up with a plan based on our diagnosis and the most important opportunities we have ahead of us and align all teams towards those goals and those outcomes that we desire. So I think that the strategy is that fundamental piece that lets you jump from your vision to what you are actually executing and achieve something. But I know many companies who are not working with a product strategy. Where is that coming from? I found that problem myself. And of course, I was biased of the company I knew. But then Marty Kagan, when he started writing Empower and a few articles, he mentioned the same that all the companies, most of the companies he worked with didn't have a product strategy. So I think it's a generalized problem. I actually touch on what I think that's a problem in the book. I think that there are two main reasons. The first one is a lack of method and accountability. No one is really saying who should do it and what actually a good strategy looks like. So no one knows what they are expected to do and if they should do it. And the second one is an inclination for tactical work. So we know product managers are always very stressed and very busy people. And we have all the time something urgent that is calling for our attention. So carving that time to think about the long term and how we can make an impact is difficult, but it's something we must do. Yeah. It's like this challenge of like really taking the time to zoom out and to look at it like from airplane mode, like a couple of thousands of feet. I should talk about the flight level, one of the problems I face a lot. And the flight level, I would say that it has actually two sides of the road. You have those companies that call a strategy like a list of 50 strategic initiatives for the year, which actually is not a strategy, it's just a plan, a project plan or whatever. And the other one says, okay, we want to duplicate sites this year and you don't have any way to actually do that. So finding the right flight level for the strategy, I think is a very hard challenge. Talking about accountability, who is, in your opinion, the driving person or role for a product strategy? The way I frame it is with what I call the top down, bottom up dance. And actually what I mean by that is that you have levels starting with the strategy at the top and then going down up to objectives at the bottom. And through that, you start with a strategy in which you have key accountability by the product leaders, but it must be influenced by product managers and teams. And then when you are down at objectives level, you want accountability for creating them and setting up with the teams, but with the product leaders influencing those to make sure they are aligning the strategy. So I think there are some gray lines, but if I had to summarize it, I would call it that way. But if there would be one person, who would it be? For the strategy, I would say that the product leader, and that depends on the size of the organization or the structure of the team. So for instance, in my case, as CPO of Estay, I'm in charge of what we set up as the product strategy, the year product strategy for all business units. So we try to summarize all our intentions or direction in one single page or single document. But then also the heads of products are responsible for creating strategies for their business units. I'm not sure if I answered the question, but basically we have levels. Yeah, because that's also a question that I get asked many times from either senior product people or product people in general, product managers asking who's responsible for the strategy. And my answer is usual, if no one does it, pick it up. But to be honest, what else do you want to do? But on the other hand, I clearly see the leaders as the drivers of such topics, which doesn't necessarily always mean that you are the one who finalizes it and adds the little dots at the very end, but you should be involved in it and also ensure that at the end of the day, the outcome will be a strategy that is aligned across the company. Yeah. So I think that if you are trying to empower teams, actually I don't want to misquote Martin Kagan, but basically the message is, it's not that you are leaving team members alone to decide by themselves, you are providing them the context to pick the right problems so they can pick the right solutions. So it's helping them in their later execution as you said, impacting the side outcomes. Yeah. I think as a leader, you're generally responsible to give the context, give the direction and be also a little bit the one who has the vision. And if we look at companies that are successful, usually there is one strong leader behind it that also leads with a vision, leads with the goal and then trickles down to the team by, as you say, give the right context and help people, empowering them to make the decisions within this vision and view. Absolutely. But I think the message in the book, because what I think that might lead to is that product leaders may be scared or maybe may feel that they need to be Steve Jobs to come up with the right strategy. And actually my goal is to let everyone know that being a great leader with providing a great product strategy is something that anyone can do. So yeah, I think it's important, but shouldn't be scared about it. Yeah, I fully agree. It should definitely not scare you away. It should be the opposite, right? It should motivate you to create something that brings clarity and helps people to see the bigger picture. And due to the fact that the bigger picture is so important, I'd love to discuss a little bit the process of getting started with it because it can be a huge document. It can be a huge topic for itself over marketing, over personas, over numbers and calculations and market analysis, plus the roadmap. So I don't want to go too deep in it. I would love to hear how do I get started if I have the task of creating a product strategy? Yeah, and I'm very, let's say, methodic in the book, but I should warn that probably if we could say the process is non-linear and has many variations and you need to adapt it to your context, but just to give some starting point and that you can adapt to your context or your audience can adapt. Basically, I say that the first step is coming up with insights. But in order to do that, as you said, you need to first do a diagnosis and understand where you are. And that has many different angles or perspective you need to consider. Most of the time, we just look into our own product results or product data or customer behavior on the product. But you need to go beyond that and you need to analyze the market. You need to analyze the current technology tendencies, also the bigger picture of the company, maybe the company results beyond the product and things like that. So that's an important point. And I have in the book, I mentioned nine dimensions to analyze, but you can extend it to as many as you need for your context. But with that, the first step will be to come up with insights. And insights might sound scary because it sounds like how I frame it is like finding or learning about this opportunity that can have a big impact on the user needs and the business results. And the great news is that is basically what we do all the time when we are doing discovery. We're trying to analyze and identify those opportunities. So it would be naive to think that when you're saying, okay, now I'm going to do a strategy, I will sit down and come up with all these insights. It's probably something that you sit down one day and you review all the insights you have in the last couple of months or last year or whatever, in order to write them down and start selecting the most important ones. Beyond that, I usually use some tools to organize or frame the thinking around insights. For instance, I do a lot, the tool by Teresa Torres, the Opportunity Solution Tree. And I think that can help you instead of seeing only the first insights you come up with, kind of expanding your view and trying to come up with more ideas or more opportunities or more problems to solve related to the same desired outcomes. So that's one. You can also analyze your value proposition, the key core attributes of your value proposition, and you see which ones you can eliminate, raise, create or increase. So there are different variations, different ways to see it. You can also use a business model canvas, many tools, but the goal is to come up with those learnings that let you know which are the biggest opportunities. Let's say we are living in the year 2010 and we are working in the area of e-commerce and we are realizing that more and more people start accessing our website from a mobile device. So I think it's pretty clear that people have the need to shop mobile and maybe even with an app, but don't want to solutionize too much. But let's say we have the insights, we have some data and we know that there is an opportunity, there is a problem and there is a couple of potential solutions that we could provide. So how do I nail this down? Am I just writing an email and say, Hey, our product strategy is go mobile? Is it a Google Docs? Is it a Google slide deck or a press release? So what is the product strategy? Actually, you're giving me a great context because that's, it was 2019. That's something we did at Best Day. So the problem we were having and analyzing all the information we had, basically was that conversion for the mobile device was a quarter than the conversion for the desktop application or desktop site. So yeah, basically the conclusion, I will talk about the process, but the conclusion was, yes, we need to go mobile. And I want to let you know how we created that document that expressed that. But going through the process, what we did was not just only saying, great, we need to go mobile. We actually need to come up with all the insights and all the opportunities we got, because for instance, in the e-commerce example that you were saying 2010, probably there are other opportunities, like for example, expanding to other markets. So you need to consider again, and also what are competitors doing? Are competitors maybe not going mobile, they are going to smart TVs or whatever, just coming up with random examples. But you need to analyze those contexts and understand where you are at and what are the opportunities. So when I talk about insights, first, you need to understand all the opportunities. Once you select the ones that will increase your strategic position and your advantages, then you need to communicate, then you need to come up with a way to write them down and communicate them. So I talked about insights, I talked briefly about selecting, and then now we're going to communicate it. And for that, there are two steps I usually mention. The first one is putting that into goals. When we are talking about the strategy, it's the same as probably quarterly OKRs, but we need to understand which is the desired outcome we want to get to. So for instance, in this case, hey, we have a problem with mobile, we need to go mobile or increase our efforts in the mobile side. What we come up with as the strategy was to duplicate conversion by the end of the year. So we have a very aggressive goal. And of course, duplicated conversion has many different paths. So I will talk about that. We want to step further and say, OK, we want to duplicate conversion by improving the experience on the mobile side. And to do that, we have a few core initiatives, increasing speed or reducing friction at checkout, things like that. That comes further down the path. But in essence, we come up with a goal that summarized what we wanted to achieve by investing or going mobile. And then the final step, I call it a synthesis, because you will have probably a strategy document with several or many pages that you can distribute with the key stakeholders or the closest team members of the product team. But you need to have something that you can show to anyone at any time and explain it in five minutes and repeat it and make it memorable. So I call that synthesis. And in that, we put probably two or three strategic divers with the goal we are trying to achieve and why those are important. So, for instance, in this case, in our case, in 2019, mobile was one of the strategic divers. So we want to duplicate conversion by the end of the year. And this is important because we are not being able to grow in the mobile market as the one that's growing. So that was the summary of how we communicated. I'm sure it answers the question. I have a question here, because in your example, you also specify a time frame, right? So if we think of a product strategy, should it be one year? Should it be like five years? Should it be short? Should it have a time frame at all? Is there a best practice? We usually, or that depends a lot on the company, the size and the stage. So that's something that I mentioned at the beginning of the book. For instance, a startup is trying to find product marketplace, committing to a very defined path for the next 24 months wouldn't make any sense. But a more established company, for instance, in our case, we try to do it annually, but we can even extend to 18 months if needed, depending on that. But I think one important caveat to that question is that as product teams, we need to consider the longer term impact of our actions. So for instance, what I use as a method to implement that is to think about the three horizons of growth of McKinsey. So we are doing things that will increase our core business, and that will probably be in a short period of time, six to 12 months. Then we are trying to expand our business to either new markets or new opportunities or a chance in users or whatever. And that will probably have another time frame. And the impact we are expecting for that is 18 to 24 months. And then we have the bets for the future. And we are trying to explore new things. And as product teams, we need to make sure we're investing in all of them because we have a higher responsibility than other teams for creating the future sources of revenues of the company. So we need to make sure we are investing on all of those. So to summarize the question, or to answer the question briefly, you have a strategy that you probably will execute for 12 months or 18 months. But in that strategy, you will have initiatives that are for shorter terms and initiatives that are for longer terms. These initiatives would be part of the roadmap, right? Good question. I tend to use pseudonyms a lot, but just to say it briefly for a moment. In the strategy, I usually say we should come with strategic drivers. So those are high levels, areas we want to focus on. So maybe a problem or an opportunity that should be on a higher level. And then when we move to roadmaps, I suggest not to do is to break that down into solutions. So we want to stay in the problem slash opportunity space, but we probably use more granular opportunities than the one that we use for the strategy. So for instance, going mobile is a very large opportunity. And then when we go to roadmap, they want to reduce friction in the checkout. So that's still a problem they want solved, it's not a solution, but it's something more granular that will be a problem item. And I think every designer and developer will love the product team or both product leadership and product managers for not putting their solutions directly on the roadmap. I have to say, it depends a little bit. So let's say you are a company that has already multiple teams working on some of those solutions already. So in the moment you're going to start visualizing it in form of a timeframe or let's say a roadmap, you would very likely put already the features that are in development or that are planned for development in case they have been planned already put down to the roadmap to make it more as clear as possible for the stakeholders. That's a very good question and interesting problem. The thing is that depends on what you're using the roadmap for. So I think that the roadmap is for visibility and clarity, but when you start putting solutions into the roadmap, the first thing that happens is that solutions still have a high level of uncertainty. So you might find yourself trapped in a commitment, you may or someone understood that's a commitment and what you need to move to another solution. There was a complaint, Hey, why are you not doing what you said you will be doing? Or why is it taking longer? Things like that. What I usually said is that same with the problems is better. And you can always, when you are communicating the roadmap, you can say, yes, for this problem, the best possible opportunity is this one. So we are thinking of making actually this solution, but on the document or the artifact, you stay with the problem. Yeah. And since we are discussing the complicated things right now, I'm also curious to discuss this topic of roadmap versus OKRs, because I know some people are very strict about not mixing those up and keeping them separate. Some people do both. What are your thoughts? I actually, I would say I'm very passionate about having both and linking both to make them work together. So basically, if we said in a very high level, you start with a strategy, this is your drivers, then you go to a roadmap, the roadmap gives you problems in a more granular shape or more smaller problems that you can put quarter by quarter. And then when you go to OKRs, this problem will know if we are solving this problem, if we hit this and this key result. So it's a very good way to be aligned from start to beginning and making sure that your OKRs are aligned with the strategy. And it's a very also easy practice or makes your OKR setting process easier because I have many companies and I've been there myself in which every time you start thinking about OKRs, it's a blank page and you start throwing ideas to there. So when you have this logical step from bigger strategy, narrower roadmap, and then OKRs, it's very easy to say, OK, our problem is going to solve next quarter, this and this. So let's put OKRs to those. And it helps you align and helps you make that process faster. And I fully agree with you. That is a very good breakdown, as long as you have the clarity and the clear roadmap. But the real world also shows me many times that these things are sometimes fucked up. So you have a high level roadmap, which sometimes is even not high level anymore. And then you come up with OKRs and then the OKRs are designed and defined in the way that for sure teams can decide what they want to build. So it's not exclusively top down. And then things are starting getting fucked up because then you have the source of truth of the roadmap, the source of truth of the OKR document, as well as your backlog. And then even the engineers don't know anymore what they should believe in and what should they look first in. So I think you really, as you explained, need to follow the logical steps and have the clear connection between those documents, because otherwise you're going to fuck it up. Absolutely. If you're going to have a roadmap, make it connected. If not, we're going to have a roadmap. Yeah, that's a fair point. Very nice. Another thing that I'm also wondering as we're talking about preparing the strategy and setting the goals and finding also the different opportunities would be like around ownership. But when it comes to like really the development, like who should be involved? Who are the key stakeholders and functions that you need to bring in to the exercise of defining the product strategy? Yeah, I think that's a very challenging topic. And again, if you think about these three levels of strategy, roadmaps and OKRs, it will vary over time. But let's start with strategy. The is the most challenging one and most interesting one. So I think that you need to find a balance in which you are not designing by committee or having an analysis paralysis because you're having 50 people in the room trying to come up with a strategy. But you also need to make sure you are having everyone's inputs. So I think there are two different stages. The first one is in the insight slash select area in which you need to make sure you are capturing information from many stakeholders. So many stakeholders, team members, because again, it's very important for me as a CPO. I know that I have senior product managers that are very, very good strategic thinkers and I want them involved. You need to be careful. Say you shouldn't select by rank level alone. So you should be a mix of people who can really add value and depends probably on the areas you want to invest more. So you have part of the team, you need to select some people from the product team. And what I mean by the product team, I'm not just referring to product managers, UX designers or heads of UX or technical leaders or managers of IT, whatever role it is. And those are very important people to have on board and to share their thoughts. And then on the other side, the stakeholder side, I think there are two options. The first one would be get someone involved. For instance, we're talking about this. Sorry. BestDay has many business units. So for GoMobile, it was our B2C unit. That's why we were very involved with the B2C business manager. And he was involved and he will later on manage the marketing budget and operation costs. So we need to involve him because if we wanted to be successful on our own strategy, we need them to also do certain things. So you cannot separate the product strategy from the rest of the company. And then so that we want for key stakeholders, you should directly involve them. And the other one would be stakeholders for which you need their input. But bringing them on the session will probably make the group too large. So for those, I usually say that someone on the definition group should make sure that they contact them and get their inputs before the definition process. So for instance, if you are having someone from going back to marketing example, if you need their input for the budget for marketing or problems they're having, you will have some product manager go and talk with them and ask them the most relevant questions to bring the information to the table. So making sure you have that mix is what I suggest, but the group shouldn't grow too large because it will be impossible to decide anything. As you said, you have someone that is accountable who needs to ultimately be deciding. After I have involved my stakeholders to create the product strategy, I would love to talk about this whole topic of alignment. Because as you said, you cannot build the product strategy in your own bubble and detach it from the company. So what does it take to successfully communicate and bring in the product strategy into the company? That's a good question. You need to make sure that you commit probably more time to communicating the strategy than you need to creating the strategy. That's something that not all product leaders are aware of, and it's very important. So again, and probably it's related to the previous question, if you are involving the right people in the insight and selection, that is great because you will have alignment from the start. And that's very important because you won't want surprises for deleting your whole work when you go to communicate, okay, this is what we decided, this is what we formulated. So in that sense, that's a first step to gain alignment. But then when you are going to communicate them, there are two things that are important. The first one is to have one-on-ones with the key stakeholders again, and those one-on-ones, product leaders must communicate the strategy, and they should anticipate what problem, I mean, managing products, managing intention, as Mark Abraham said. So you will probably have selected some things that will negatively impact some stakeholder, or they will have something that they wanted to have in the strategy, and you are not selecting that. So you need to make sure you have those one-on-one conversations where you can open up and be more transparent about what, not just transparent, transparent you're always, but make a confrontation with their needs and their problems, and be clear of the reasons you decided that. And bringing the tissues. Yeah, exactly. And making sure you don't get punched in the face. Socially distanced. Exactly. But again, you need to make sure that you are being upfront with that and avoid having these very bad surprises in a large meeting with many stakeholders. I couldn't agree more. Yeah. So that's a time-consuming job, but you need to do it. And then you can move on with the communication sessions that I think is interesting because you probably are going to do different levels. So maybe the top levels or C-level, whatever you call it, in which you present the strategy. But in that, you will get feedback from different areas that you can incorporate and make a better message or present it better when you go and do some area presentation or however you call it. What was actually the biggest mistake you have done while you were communicating your product strategy? I would say that probably the first one I mentioned is underestimating the amount of one-on-ones I had to do. So first one was time-consuming and second one was that I, or the team in general, haven't touched base with all of the stakeholders we probably wanted to touch base before presenting the strategy. So some concerns were raised at a stage that was probably too late for us. So it was an interesting problem because if you detect something at a later stage, it's still your problem and you will have more rework to do. So it's basically not something you can avoid and just say, oh, sorry, it's decided and so we will move on. So that's probably the worst mistake. And the second one is probably more related when the product teams discuss in more depth the impact of the strategy. Having previous conversation with the product teams to understand which will be some potential opportunities or solutions we will pursue for this strategy is something that we didn't do in our first round and we incorporated and it helped move the conversation forward. When you present that strategy to a team that is too high level or is abstract, some of them may have trouble understanding what you are trying to pursue. So having some examples, even though if later on you don't do those examples at all, it helps move the conversation forward. Yeah, I agree. Cool. What would you say are the problems that someone might run into working on the product strategy? Things to look out for or to avoid? I would say that there are two very critical steps. The first one is, as I said at the beginning, making a full diagnosis. I'm not sure if that's the right word, but making sure you're analyzing all potential angles and coming up with really a wide range of opportunities. So that's very important and something that we usually don't do. So we usually sit down and we are very solution biased. So we need to do this and let's make a strategy that supports we need to do this. So that's a very bad problem to be in. And you really need to change your mindset when you're doing strategy. And the second one is how we select. Because again, and this is something I discovered badly over practice, or bad practice, is that the way you prioritize a backlog with, for instance, with return on investment or formulas or Moscow or whatever you use is very different than how you prioritize a strategy. Because what we are trying to select when we are prioritizing strategy is the things that build a stronger strategic advantage and position as the best solution for our customers and create the best business results. So that's not always something you can resolve with a table or formula. So again, for instance, we mentioned when you need to expand to a new location, maybe that location is strategic for other reasons and not necessarily because it will be a great return on your investment for that expansion. So that's probably not the greatest example, but those are the things you want to consider when you're doing strategy. So that strengthening your strategic advantages is much more important. And you need to think about that over the potential formulas you have for the backlog. Is a strategic driver? Is this something that I can actually measure afterwards? Like, can I say, okay, this one was a good strategic driver, especially if you don't want to measure it around what's the return of investment of it, or what's the revenue that we get out of it? Yeah, I would say you should measure it. So it's actually not only that you can, you should, because you will put, as I said, after selecting, you will put goals around that. So for instance, let's say that you are trying to say, hey, this may not be the greatest return on investment, but what we will achieve would be being the best solution for this type of problem for our customers. And that's actually something you can measure. You can measure that around market share. You can measure that around customer satisfaction. So you should, you can measure it. You should measure it to make sure that you have made the right selections. But this automatically needs to be very tied into the overall business goals that have been defined. Just about to say at the end of the day, the strategic goals always need to match the business goals, right? Because if the business doesn't work and if you don't have to return on invest at the end of the day, you won't be existing anymore. But it also means that you have clear business goals and a good business strategy, right? At the same time, I think as product team, you can even bottom up when you do this discovery, inform the business more also on what are really the opportunities and how the business might also change their goals based on the input that they get from the product strategy or from the initial preparation work out of the product strategy. Let me give you an example that may clarify what I mean. In the book, That Will Never Work, that's written by one of the Netflix founders. They said that there was a point in time in which they were going to be acquired by Amazon or they were discussing acquisition by Amazon. And at that time, the acquisition never happened, but they realized that they will never be able to compete on selling DVDs. So at that time, they were selling DVDs and also working with a DVD by mail. They decided that Amazon in the long term will win the sell DVD market or the retail market, so to speak. So they decided to kill that branch to focus on the DVD rental. And at that time, the revenues of this selling DVDs was above 90% of the revenues. So that's what I mean by a strategic decision that will strengthen your core and how you want to position for customers. So it's not always kind of, let's make the button bigger to increase conversion. It's a deeper selection based on what you want to achieve in the long term. Makes a lot of sense. And I think just tying or continuing a little bit also on the question earlier of the timeframe of a strategy. Another thing that comes to my mind is like also what should the cadence be that I work on a product strategy based on the timeframe? Like when do I sit down again to do the assessment and to look at where do we stand and to come up with a new or to refine the old product strategy? So I think that is something that changes depending on the stage of the organization. Again, startup may change more frequently than established organization. But I usually say that there are different cadences that will trigger different actions in the strategy. So for instance, the quarterly OKR check-in, if you are failing miserably or succeeding expectations may trigger you to change the strategy. Then you also have, we also do a semester review in this case of the roadmap. So we do a deeper review of the roadmap. And again, if you are again, exceeding or not hitting your expectations at all, that will trigger a strategy reboot. And finally, the one I prefer is doing a strategy annually. Because again, it's time consuming and you want to have some stability because if you notice another strategy, I mean, if you don't have any stability around your strategy, it's just changing all the time. It's not what it's supposed to do, bring you this longer term plan and this longer term expectation of your desired paths. So that's how I handle different cadences to make sure that we are fast enough if we detect something that's not working, but also stable enough to really commit to some path and some desired outcomes. Great. So to wrap it up, I think you mentioned that there are a couple of things you should do and you shouldn't do and that some people are also not aware of. So our closing question today would be, what would you say are the two most important things every product lead should keep in their minds when they start working on a product strategy? The first one will be making sure that we are considering multiple sites of diagnosis and coming up with multiple opportunities, not just following the one that has been talked about the most in the last or the one that the CEO wants. So that would be the first one. And the second one is a two sided answer, but is making the selections based on this positioning and sending the solution advantage that we mentioned, involving making sure that we involve the right stakeholders. Because again, when we are talking about positioning, it's not something you only do in the product, the entire organization does the same thing. So it's very important that you are aligned in that sense. Makes absolutely sense. I think that's a great closing word and making sure to keep everyone up to date and everyone involved. And whoever wants to learn more about product strategy, we're going to link your book in the podcast description. So feel free to take a look and dive deeper. Amazing. Thanks for joining us, Nacho. Oh, thank you. I really appreciate it. It was a challenging conversation and I always like to talk about these deeper questions about strategy. So thank you very much. Thanks. Thank you too. Bye.