Product Development with Purpose: Building a Winning Mindset and Core Principles for Success with Eric Leach, Co-founder and Chief Product Officer of Strata Identity

Welcome to Product Leaders Podcast, a podcast by FireArc. We are the defenders of usability, champions, product consistency and the emissaries of enjoyable human technology interactions. Don't play the game. Listen to the podcast where we share conversations in product leadership to help empower you to produce great digital products for your customers. Hello my dear listeners, today we are having Eric Leitch, an entrepreneur and product leader with a profound focus on creating new market categories and building teams to tackle the challenges faced by the customers in those markets. He has over 20 years of experience in leading product strategy, go to market and innovation for identity management, application security and data protection products. And today we are going to talk about mindset and core principles to guide your product development. So stay tuned. Thank you very much for joining our podcast. Are you mind to take some time and introduce yourself and tell our listeners a little bit more about your journey as a product manager and in general tell us a little bit about yourself? Yeah, I would love to. First of all, thanks for having me. Really excited to be here, excited for what you're doing and was really kind of happy with the message overlap and trying to really kind of communicate what I do in product and share that information more broadly. I've been in product management for 25 years now. It feels really strange to say how long sometimes. And I would call myself an accidental product manager in the sense that and like a lot of product managers, I didn't set out with the objective at the beginning of oh, I'm going to be a software technology product manager. I was at a very small startup and learned how to use a tool and that startup got acquired by another company that sold that tool. And when I arrived after the acquisition they said hey, we hear you know about this tool. And I said yeah. And they said congratulations, you're the product manager. And I was like, what does that mean? It's awesome. I think like you also forgot to mention that you're an entrepreneur and I know that you also co found a great and successful startup like Strata, right? Yeah. Yeah. So over the journey I've. I've spent some time in both big companies and small startups. So I've had this kind of really diverse experience of running and managing products in these different environments and under these different circumstances and getting to be there and establishing a new product really with a blank sheet of paper from a greenfield, I think is really what, when you approach founding and entrepreneurship as a product person, that's what it's really about. How can I create something new from scratch that's going to have a positive impact on the world. And how product management has been changed since you started career as a product. Oh, wow. Yeah, it's changed pretty dramatically over the years. I would say. Some of the biggest changes are kind of. They seem superficial, but moving into new development methodologies. Right. So back in the day we primarily did waterfall style stuff. I remember early on in my career I spent so much time writing PRDs, product requirements documents, and they were these big, long, heavy duty documents that laid out everything in advance as if we knew, like, as if we had some amazing insight into what was going to happen. And that's gradually transformed into people doing more agile methodologies where we take it in smaller chunks. And I think we. The biggest difference is that you assume that you don't have the answers at the outset and so you really spend much more time out with customers before you even start building or trying to sell anything, really trying to understand what they need and what their problems are and what they're trying to solve and the things that keep them up at night most. And so I think that's been a really big transformation. Maybe that's just me. It seems like it's something that spans across the industry where you really done a good job over the years of trying to break things down, make them smaller and deliver value earlier in the cycle than we used to. Yeah. I assume that as you have more than 20 years of experience in product management, probably you face the exact moment when companies started to transform themselves from waterfall into a more lean and agile way of working. And I assume you're a billionaire and can you tell me maybe you have some story about how back then companies transform from waterfall to agile companies? How did it look like? Or maybe you faced some challenges with that? Yeah, I think one of the really big things was moving from packaged software into SaaS software as a service. Right. So a completely different way of delivering the software and going from, hey, we're going to build a product, we're going to get it pressed onto DVDs and we're going to ship it out to customers in boxes. Right. They're going to take that stuff and do something with it to getting to a delivery model where customers can see what's there and experience the value right away. And so I think the biggest transformation that I made was in moving from that, you know, big heavyweight process where you had to have everything well defined and everything had to be done and it all had to be tested and documented. I mean, all those things are still true, but you just do it in much, much smaller chunks. And you have a chance to adapt and change. When you get feedback, when you send out that dvd, you don't know what, what the customer is going to experience until after they get it. And so when you deliver through the cloud and you deliver through a SaaS model, you can test your hypotheses, you can test your ideas, you can test out features in a much more adaptive and agile way. That was eye opening for me. You know, it was one of those circumstances where I was, I got to ask and I got to get answers and then we could change before we had to ship everything. And that was a really big, exciting change that's happened because I never imagined that we would find out until customers started reporting issues. Right. Or they came to our customer advisory board a year into after product launch and they would tell us like, yeah, I don't like this thing or that thing doesn't work or I love this, do more of that. You know, there's always that part of it as well. But being able to find that out so much faster was such a game changer I think for all of us. Yeah, I agree. Even right now all their different structures in startups, mostly they do have squads and they don't have any like project manager, all team has the same OKR KPI's and then they're like targeting the one goal. But still I noticed that some of especially like big companies, they still have some kind of project management and I'm curious to know your opinion on that. What about project managers in product companies? Do you think they still can bring value or with all these agile frameworks, Scrum et cetera, classic project management kind of sinking into oblivion. Yeah, I have to be careful here because I have some good friends who are project managers. No, I'm not saying that project management as a position is not needed. I mean project management can be different, but especially by project management, product company. Yeah. So I think what happens in a lot of big companies is they partially make the transformation, right? They go partially from waterfall into agile. I've heard it described as Agile Fall, right. Where it's like you're mostly doing agile, but you're also kind of still doing waterfall and you're trying to hit these milestones and all of those things. So I think we're working with, between product and project management. I think the real important thing is there's a couple of different goals that are there. Right. Project managers are trying to make sure that the thing stays on track and you're hitting towards some Milestones and project management. What we're trying to do is break those milestones down into the smallest things possible. It's not what we're going to deliver this quarter, it's what we're going to deliver today. Right. And so I think getting project managers aligned with that at first is kind of hard, but I think over time, especially as you build that relationship and maybe this will lead into some of the mindset and core principles stuff. I think over time you get project managers accustomed to, yeah, hey, we're going to be able to meet all of these things that you need to do. A really good example is you're building things and there's a project manager who's keeping track of the regulatory compliance work that needs to get done. So you need to integrate with that person's project so that you can help them with that. Regulatory compliance is bigger than any one thing that you can deliver in any one day. Like there's whole big chunks of things that have to be done. And so I think it comes down to this regular flow of communication, like, hey, we delivered something today and we're going to deliver something tomorrow and we're iteratively building this thing up to give you this feature or this function or these things that you need in order to make your project milestone. And that visibility and communication, I think is what makes the collaboration between product and project much more friendly and efficient and gets everybody to the milestones that they're trying to get to. Yeah, I agree. Also, you mentioned mindset and I know that you have written already in your newsletter about shared mindset and its impact on a product manager success. Then do you want to spend some time telling us a little bit about that, like how to build it? Yeah. So I think one of the things that I've learned over my career, and I tell a little story in that newsletter edition about this where very early, that first full product management job, the development team was in Dublin, Ireland. I flew over there, walked into this conference room a little bit jet lagged and immediately started talking about what this is, what we're going to do and this thing is we're going to do and it's going to be great. And what immediately became apparent was no one understood and no one was aligned on why we were doing it to begin with. And so I think that building a mindset starts with building that understanding of why are we doing this, why is it important? Why will anybody care about this? Why would anybody use it? And those are the seeds of mindset. And then the second Part of it, I think, is really you're going to have tons of forks in the road and tons of points of transition and lots of decisions to make. And I think the other thing that mindset helps you with is, is giving you a set of principles and a foundation for making those decisions in a way that is consistent and makes sense and that people can follow. And what I've also found is that there are certain principles that you can establish that really help people, like, they don't have to come back and ask every time. And secure by default, being one of those core principles, is one of those things that you build mindset around. Like, we as an industry, we as collectively product management, we have to do a better job at building products that are secure. The threats are real and it's existential, right? So it's out there, it's every day. And we have the disadvantage that we're always trying to defend against everything all the time. And so when you set out a core principle like let's build secure by default, you start by talking about it all the time and making sure that people are aligned on that, right? Getting together with the team and saying, hey, do we all agree that this is a core principle that we can follow and getting some agreement up front about that, and then constantly revisiting it, going back to it, and saying, hey, secure by default's important. Let's make sure that we're doing that and constantly revisiting and reinforcing that. And I think that's the way that you establish an imprint mindset on an organization. So then people themselves start thinking about, hey, we need to build secure by default. We need to make sure that we're considering security as we build this new feature or this new capability or as we refactor this code or whatever it is. And I think the gradual understanding and then hearing it back from the rest of the team like, hey, we need to make sure that's secure. That's where the mindset pieces come in. The other good part about the mindset piece of this is you can build those principles, you write them together and you sit down with the team and you say, hey, this is what this principle is going to say. And one of the things that I do, I leave that four principles doc. You write it down as a doc or however it makes sense. Whatever tool you're going to use, I leave it open on a, in a tab on my browser every day, right? And then you, you know, that gives you the opportunity to go like, hey, I'm reading these Core principles right now. And you know, you're in a ceremony, maybe you're doing iteration planning or you're doing, you know, some kind of planning and you're thinking about the backlog and you're thinking about tactical things. You can take a step back and you can say, hey, here's core principles, right? These are the things that are there. And just constant reminders to yourself and to the rest of the team that there's these really important guiding things that we should all be thinking about as we're planning this stuff out, as we're thinking about things, as we're looking at how we're going to build something, that those core principles being there, and I encourage everybody else to do the same thing, like leave it open, right. Have it there in front of you all the time so that you can refer back to it and remind yourself of those things. If that becomes a one and done type of event, like you write it down and everybody agrees on it, nobody ever looks at it again. It's not going to become a mindset. You can't force people to have a mindset. You have to influence them into a mindset. Yeah, exactly. But it sounds easy, but in reality it's really hard. Especially if you are having like CPA position, probably you have different units, different teams and how to make sure that all the people that working with you or people that kind of reporting to you would still have the same principles. How you advocating these principles, how you're making sure that the team is moving in the right direction. Yeah, so some of it is, I think it starts even as you're building the team itself. So you know, you have those core principles and as you're going out and finding people that you want to be on the team, it's really about kind of filtering for those principles. I always look for kind of three things in product managers. Do you have the product management skill set? Right. And I think that's one thing. Do you have the domain expertise in the area that we're going to be working and do you have those core values and core principles in your mind as you're coming in? It's okay if everybody doesn't share your core principles, if they think other things are important, but maybe that's not somebody who's going to end up on the team. Right. It's okay. So we don't all have to agree. Right. And maybe that person is just not a right fit for the team. And so I think it starts as you're building the team. You talk to People and you say, hey, these core principles, these core values are really important to us. What do you think? And ask them and get that honest feedback. And one of the things that's been great about it is that's led to a bunch of adjustments of those core principles. It turns into conversations that go something like, well, hey, have you thought about this? And very often I said, no, actually I haven't. That's a great point. And that'll give you a clue or an indication that might be a person who's a really good fit for the team who can help reinforce that for you. So I think it starts there and then I think it just continues with regular revisiting of the core principles of the core values. Just talk about them, right? They have to be top of mind and across multiple teams, across even just one small team, just continually revisiting them and talking about them and refining them and understanding, you know, maybe this one is we got through the part of the project and this one isn't as important anymore. So let's change or rearrange the priority of them or let's add something because we forgot it. Let's evolve it over time. I think when people participate in the creation and evolution of something like core principles and core values, they feel much more invested in it and they'll embody that and they'll carry it around the organization. The most important thing is that it can't just be me, right? If I'm at the top of the product organization and I'm leading that, it can't just be me saying that stuff all the time. It can't be a top down thing. It really has to be very much more organic. It has to be bottoms up. It has to be something that people inside the organization and inside the teams that they really embody, that they really imbue it across the rest of the teams in the organization and help people to understand why it's important. And can you share with us an example of these principles and how it affects day to day work of a, I don't know, delivery team? I'm just curious personally just to understand how granular you should be with these principles? Yeah, I think it depends a little bit on the team. I hate giving the it depends answer, but I think it depends a little bit on the team and the kind of product that you're trying to build. I think there's a couple that apply pretty broadly and generically though. The first one I mentioned, which is that secure by default, right? It's everything that you put into your backlog or everything that you think about building or core architecture of the product that you want that everybody's thinking about. What do I need to do to secure this? What do I need to do to make sure that this is the most secure product that I can possibly deliver? I think another example of that similar is API first. And this is something that I took away from my time at Salesforce, where there was a very clear core principle that everything had to have an API. That was the core of the platform were those APIs and the ability to interact with the platform through those APIs. And one of the things that a core principle like that does is it cascades through a lot of different areas. And so it makes people think about, oh, well, if all of my APIs are going to be public, then I need to think about how I'm going to secure that API and how I'm going to secure that API endpoint. So it relates back to the secure. By default, if everything is behind an API, then me and my team and all the other teams that I'm interacting with need to think about those contracts between us and how to build abstractions and how to decouple across features or components or whole product. And it influences an architectural mindset about how to build in a way that you don't get monolithic and you don't get tight coupling and you don't get into a position where there's these, like, weird and heavily, you know, coupled interdependencies between teams where everything comes to a halt because you're waiting for this other team to deliver something to you. So I think it keeps parallel progress going. And I think it's another example of a pretty broadly applicable core principle that you can ask people to think about day in and day out, and that will influence a lot of the decisions that people make. Right. And you know what I'm curious about? Have you ever violated your principles? I mean, I see that you were the founder, you also was a cpo. I'm just interesting. Have you ever blinded with your awesome, innovative idea? So you made decision not based on data, but based on your gut feeling, let's say gut feeling, driven decision. Absolutely. And I would say the earlier in my career I look back to, the more likely I was to do that. Right. So early on, I relied pretty heavily on instinct and intuition and much less on data, partly because I didn't know how to go out and collect that data. I wasn't necessarily that good at it yet. I haven't developed that skill set So I think when you rely a lot on instinct and intuition, it's harder to apply the principles because your decision making is much more situational. You look at it in the decision in isolation. And really, the mistakes that I made doing that were part of the reason why as I've evolved in the product management space and in my career, I've really focused much more on those core principles, on those core values, because I think that's what gets your decision making to be more strategic and less tactical. And I got that feedback from leaders and from people that I worked for. I was like, hey, you need to think more strategically. You need to up level. You need to be down in these, like, deep details. And it was like, oh, okay, yeah, how do I do that? And that was really about like, okay, how do I up level? That is by. Or one of the ways to do that is by developing these core principles and helping give me a framework and my teams a framework for making those decisions know, day to day that need to be more strategic and less tactical. So, yeah, I absolutely made those mistakes all the time early on. But it shouldn't be like always mistakes. Sometimes you can be right. Yeah, sometimes you're right. You get lucky and you guess and you get right. Right. Instinct and intuition is also, you know, sort of a metaphor for guessing right. You're like, I guessed and I got it right. Yay. But yeah, for sure, up leveling that is a way to try and mitigate or kind of avoid some of those mistakes. And the reason why you can do that is because around those core principles, you can start building metrics. Right? You can get to things that are more measurable and you can use those, the metrics and the things that you measure to understand how successful you're being. And I think that goes a long way. So as I've matured in my career, as I've progressed, I've spent a lot more time on metrics and borrowing from people. There's a lot of really good frameworks for collecting that. OKRS is one of them you mentioned early on, right. Is what is the okrs? The objective part of the okrs is really the why, right? Why are we doing this? What's that interesting, inspirational thing that we're going to do over the next 90 days? And then what are the metrics that we're going to have to make sure that we know that we're accomplishing it or not? So that kind of thing and then has been very helpful okrs. I saw a woman named Christina Wadke present at a Mind the Product conference in San Francisco a few years back. And that really introduced me into a more refined methodology around using okrs that I had dabbled, I would say before that I was dabbling in it. I wasn't doing it as well as maybe I could have. And when I watched her talk and then read her book and took a look at that at her blog, it really gave me some better tools to use for and inspired me to be better at doing okrs than I had in the past. And I think that was part of the evolution of, toward away from it, just purely instinct and intuition and into data and metrics that I could use and what kind of insights you can share, how you improve your okrs plannings. Yeah, the first few go rounds on okrs, they were inspirational and metricless. They just, the metrics, the measures, the krs, they just weren't tangible. And going through and looking at them at the end of the quarter and saying, did we achieve this? And I was like, achieve what? Right? It just wasn't obvious because the metrics weren't super clear. And so getting really disciplined about things is hard, right? And getting to a point where you have a really well defined set of metrics is hard. It's hard to do. And it's challenging because it's gonna force you to be very disciplined about what you have to do day in and day out. I think that's one of the main things that I learned about okr. It's not everything you're gonna do, it's just the things you have to do, right? It's the things you have to focus on. You're going to end up doing a lot of other stuff because we all stay very busy. But those OKRs are the things that you have to do, so. And then repeatable, right? So I think there are things as product people that you always have to do. And so making those into okrs is a great way to do that. One of the examples that I always have as an OKR now is voice of the customers, right? Doing voice of the customer interviews. And I usually set a goal that just says let's do one a week. You know, that's 50ish, 40 to 50 interviews a year. And you know, you can put a really tangible quarterly OKR around that. And you can say let's do 12, let's do 12 in the next three months, let's do 20 to 30 in the first half of this year. And it's something that you can very tangibly measure that has A big impact on what you do because that forces you to put in place the methodologies and the tools and the things that you need to do to do those interviews, collect that feedback, measure what you get from that and take action with it. It becomes very impactful to product managers, it becomes very impactful to development organizations. One of the things that's really impactful about it is it's got tangible metrics, right? You can measure a consistent set of things across multiple interviews. But the other tangible impact that it has is developers love hearing about that stuff. They love hearing, hey, I built this thing, this customer saw and used it. And here is the feedback that they got. And it happens in a very quick cycle. And developers love it. Of course, they're technical and they need to be data driven as well. And they want to see, yeah, they want to know that the code that they write is being used. And then product marketing and the field teams love it because it's the things, those become the nuggets that you use for differentiation and position. Right? When you want to go out and talk to customers and the market about stuff, they've already told you what they think and they've already told you what's important and you just go and take those nuggets and you turn it over to your product marketing team or you in a small company, you know, put that into your positioning and go and help your sellers and your hunters go and find the people that have those problems and sell more product. So I think that's an example of an OKR that you can keep consistently, right? You don't. It's not just a one quarter. We do that and then we're done. It's something that we always do. And then I think it also helps to build other related OKRs around that, like, hey, we're early on. So what we need to do with that first voice of the customer OKR is build two other OKRs around getting the backlog in shape and understanding the priorities and getting a cadence for that. And then maybe in the quarter after that, it's really about, hey, we need to start developing the content that we're going to use for the field teams to position or how we're going to train people about the products. And so you can come up with really tangible things, really tangible OKRs that relate and cascade off of that. So it kind of becomes your key. You know, you can use those as like a cornerstone or a keystone OKR that will drive other things. So I guess, you know, if I had to sum up you know, what I've learned about okrs is that. Right, right. That you can start with one thing, something that's big and strategic and impactful, and then you can use that to build much more effective related okrs off of that. Yeah. I talk also a lot with different founders and managers and almost everyone says they started build. They feel that it's better to start building OKRs based on articles and different sources in the Internet. And then after that go deeper into books and theory how actually to build okrs. And then you would get more value on that because you would have a real cases that you can apply once you find some insight in the book. And does it resonate to you as well? I mean, it's better to learn and build or build and then learning. Yes, both are good, right. I think it's good to experiment and it's good to start with something and see how it works for you and then to go and learn as much as you can. It's a perfectly good approach. I like to do a little bit of both. Right. I like to do research. I love to read, I love to spend time understanding other people's knowledge. Right. And see where and how I can incorporate that. I have a phrase that I repeat to people all the time. My teams have heard me say this over and over. None of us is as smart as all of us. And so gathering a collective understanding and a collective knowledge is really important. And then contributing back to that, obviously, you know, take your experiences from those other people's writings and their experiments and contribute it back and say, hey, I read your book or I read your blog or I read your post or whatever it was. I saw your webinar, I tried those things. Here's what I learned and here's how I adapted what you did and here's how it worked for us and our teams. And these are the changes that we made that were impactful. And so I think it's a little of both, right. I think experimentation and learning or learning and experimentation. Like it's all feedback loop. I think of it and I'm actually writing an article about this right now, which is you have that loop which is at the top it says do stuff, and then under that it says learn stuff. And it's just a constant, you know, virtuous circle between those things. I think that's just the way that it goes. Eventually you stop differentiating between which one came first, learning or doing. Because they feed on each other. Yeah, I agree with you. And also I think like, we need to Slowly wrap up our podcast meeting because I just don't want to take more of your time than I booked. And I just wanted to, you know, to give you some time to also promote your new business that you are starting. And I know that. Congratulations. I know that you just announced in your LinkedIn that you are starting a new business. What why consulting? Do you want to spend some time telling our audience? Uh, what is what why consulting? Yeah. Yeah. Thanks. So I started the substack. What why? And really to talk about the experiences that I've had in product management and to kind of share that knowledge and those learnings and try and broaden, you know, broadly disseminate what I know and what why. Consulting is really sort of the next step in that, which is to extend the impact that I can have on people that are trying to build products. So it's really kind of a transition from going and building product to teaching people how to build product. It's hard, right? And not every organization has done it deliberately. Almost everybody has product managers, and some of them are accidental. They've been kind of thrust into the role and said, okay, now go be a product manager. But they don't necessarily have all the tools and the skills that they need to do that. And then some people, they don't have that function. And they've got, you know, people collaborating on, you know, how to build a product, but they haven't really deliberately put in a product management practice. And so what Y consulting is really about helping people to solve those problems. How do you either get better at something that you're already doing in product management or establish the practice itself and to leave behind a set of tools that people can use to get really good at it and build great products and products that matter. Awesome. Thanks for sharing. And I think it would be valuable just because even for myself, it would be interesting because in general, I do different things in the company. I always feel that I'm lacking skills or something, and I don't know, like, where I can start to get this information. I mean, to go through bootcamp, it could be quite hard, but it's better. I thought that it's better to go with some mentorship, but then I'm. I don't know how to pick this mentor. And with what Y consulting is, I feel that's something that could a lot of people profit, like myself, because as you mentioned, there are a lot of people there in the industry became, yeah, product manager just because it's just somehow organically just happening. And after that, you like Feel insecure that you have not enough skills. I'm curious, what is the strategy behind. Are you going to be like one man army company or your vision is more like two dozen organizations that will teach future project managers? Yeah, it's definitely broader than just me. One of the things that I'm very grateful for is over the years having met and worked with and built relationships with so many really fantastic product people. And so I think one is that all of those different product people that I know, they bring a slightly different perspective. And so I think the scale, the ambition is to bring those people together and try and help in a variety of different ways. And so in a way, it's almost like collaborative effort across a bunch of people that can help to bear what they know about product management, not just me, because I don't know everything. I get things wrong all the time still, you know, I'm still learning and. But it's like a B testing. You need to do such things. Fail in 80% and then get this 20% of learning. Exactly. So bringing other people together to work and help in a really broad and impactful way. Awesome. And don't answer if you would feel that it's kind of personal question, but is Worldwide Consulting is the reason why you decide to step down from CPO position at Strata? Yeah, in a way. Right. It's really been about what can I do to scale my impact. That's been top of my mind and really moving from, you know, I've been building products for more than 20 years. And so I think for me, it was an interesting opportunity to think about not just building product, but to expand that reach and that influence beyond building a product for a company, which is what I've always done, and a new challenge for myself, quite frankly, which is to put myself out there, write, you know, publish, do things that can be scary. Right. Talk on podcasts. Right. Doing that stuff and kind of challenge myself in new ways and put myself into new and somewhat uncomfortable positions where I can continue to grow and as I grow, help to share that with other people. Awesome. It's a great mission also to put on the website then on the reason why you started Whatwide Consulting. Could be a great selling point, to be honest. Yeah. Is it your in general, your first podcast? No, but, yeah, but, you know, I've done a lot of speaking and I've done a lot of, you know, webinars and a lot of things like that, but not for myself. I've always done it for products and companies and those kinds of things. And so, you know, publishing the substack and writing those things and really kind of just it's me, it's the authentic me and that can be a little scary. So sometimes to put that out there for people because you never know how they're going to react. You never know what they're going to think. So yeah, it's kind of exciting. It's an exciting time. Awesome. I think it's a best time to slow down and start something new, especially in these times, market conditions. Yeah, yeah. Crazy couple of weeks. Yeah. As we are running like designing Source three business like we are agency and I was like looking at the news and constantly scrolling through the different news regarding SVB's because I thought like, no one will save them. I can't even imagine what will happen, you know. Yeah, it's one of those impactful moments and maybe it'll have a strong influence on how we approach the software technology business and what we do to build products and customers, companies and how we go about financially sustaining those things. Maybe it changes going forward and maybe it changes for the better in some ways. Yeah, I hope. But yeah, in general it always has some kind of cycle. You just don't know like for how long this type of condition would do. Okay, cool. I think we can wrap up. Thank you very much for all the insights and I think like it was to mention to our listeners that I hope that this episode would warm up the interest in the mindset and core principles of product management. And don't forget to subscribe to Eric Substack and I will leave all the links under the episode. All right, thank you. Thank you so much. It's been a pleasure. Thank you. Product Leaders podcast is brought to you by FireArc. I was your host Tovik. To find out out more about Fire art and how we aim to build a brand that will contribute to the world with useful products to empower people and make their lives easier. Visit Fire Search for product leaders in Apple Podcasts, Spotify and Google podcasts or anywhere else podcasts are found. Make sure to click subscribe so you never miss any future episodes. On behalf of the team here at fireart, thanks for listening.