The Technical Product Manager's Playbook: Curiosity, Simplicity, and Customer Focus

Speaker A: Welcome to another episode of our podcast, Practical Product Management. Our, um, premise here is that theory is great, but product management happens in the practical space, in context in your company. And so it's really about what you do practically. Right, Marilyn? Yep. Okay, awesome. So today we are going to interview a Katarina. And so, um, we've talked a little bit in the past about how there are sort of so many jobs you can do when you're a product manager. And so, um, I asked Ekaterina if she would come talk to us about being a more technical product manager. So Katerina, I'll turn it over to you to introduce yourself and tell us a little bit about you and then we'll dive into some questions.

Speaker B: Yeah, absolutely. Hi, I'm, uh, Ekaterina. Uh, I'm super happy to be here. I love talking about product management. I also apply product management principles in my day to day life. So I'm a fan. And uh, I work with developer productivity and uh, client infrastructure at Spotify. Before that I worked with, uh, building a credit product, uh, from zero to one in accounting space. And before that I worked with, uh, partner integration and Craddytrix. So a few different things. And uh, in at least half of my roles as a product manager, my customers were other internal roles. And the, um, space that I love the most is when there is a very complex system and then we still have a great focus on the customer experience and we make sure that the customer never feels how complex everything is underneath. So that's my background in a nutshell. And then I also teach my kid to use the word prioritize. So that's also work in progress.

Speaker A: Marilyn can give you tips on, um, product managing. Your child, he's right. Hers is now raised, but, um, she's. I mean the kid's been on a pip.

Speaker C: He's had a scrum board.

Speaker A: Like he's got a whole situation. So if you ever need tips on raising your kid as a product manager, M.D. marilyn's your girl.

Speaker B: That's amazing. Marilyn. I'm, ah, I'm starting to note the questions to come to back to you with that

Speaker C: family stand up is a game changer. That's what I'll.

Speaker B: Oh my God. Okay, we're not that far.

Speaker A: You see the light go on in her eyes. Marilyn, family, stand up. What have you done today? What did you do? What are you doing tomorrow?

Speaker B: Exactly right?

Speaker C: How else are you gonna know what's going on in your teenager's life? They don't talk. They don't talk.

Speaker B: We're Gonna overhaul this whole theme of this podcast.

Speaker A: Right.

Speaker C: It's all over.

Speaker A: We're just changing the whole thing to 500 kids.

Speaker C: Absolutely.

Speaker A: Awesome. So Katerina, I would love for you to talk us through a little bit like how did you, how did you get into product management and how did you find yourself sort of in this space of really technical roles and finding that, that kind of love for that complexity space?

Speaker B: Yeah, um, I studied engineering in my first degree and then you know when I say that people usually say ah, but that's why you can do the technical product management. But my degree in engineering was around telecommunications on the railway transport. So it doesn't directly relate uh, um, to what I do day to day now. However it gave me I think the system thinking that really helps with uh, uh, platform product management, technical product management and overall whenever I work uh, with other people and products, um, and then my first job was in customer care and there I got lots of empathy to the customer. So it also to be honest gave me an opportunity to see what different people do in the company because I don't think I was as mature to actually figure out my whole career journey ahead of me. So I sort of figured out that if I start with customer care you will know who are the, what people do, how people grow and uh, after I have interacted with people who worked with product I thought it was super interesting. So that's how I got interested in product management and I felt like that role would give me both touch points with the systems and architecture and technical aspect. But also it's a lot about problem solving and that I liked as well and having customer in the center and that I liked as well. So I felt the recipe was there and um, the customer care that I worked was for telecommunications for cross border networks. But the first role that I got was for mobile apps which were on the rise at that time. So I got lots of empathy to the end customer to you know, people around me and how they use mobile apps. So that's how I ended up with uh, in product management. And then I had the mentor at the time when I worked with mobile apps and she actually recommended me to try and work with different type of products. And this is how I ended up going to Klarna, working with the ah, credit infrastructure and uh, backend systems. So that's how I got more into platform product management. While still I think it was extremely beneficial to have experience of working in a customer facing product because then um, the whole chain of how everything interacts with each other made Much more sense for me, even if I worked with the platforms.

Speaker C: Yeah, I love that point of view. Um, I think that what you just described really resonates with me and probably Leah. So I'm not a platform person. I don't know if you guys know this or not.

Speaker A: Leah is sure you're not.

Speaker C: But this notion of being able to sort of like understand how a platform works, um, and how that relates to the customer experience, um, I mean that's how my brain thinks. Right. You can describe as a, as a user, you can describe a problem. And my brain's already trying to figure out how everything across the layers will fit together in order to deliver that great customer experience. So I love your background, uh, and I'm super excited we get to have this conversation with you.

Speaker B: Likewise.

Speaker A: Yeah, I mean I think it's, I think, you know, one of the things for me that I, along the way have said to people is like, you need to be able to draw the big boxes of what the architecture of your products are. Right. And if you can't, then you don't know enough about your product.

Speaker C: Right.

Speaker A: And so I've had front end product managers be like, well, I don't know about the, the, the architecture and the infrastructure. And I'm like, guess you better go find out. Yeah. Right. And so, because I, similar to Maryland, I want people, when I'm, when I'm leading product managers, I want them to think that way. I want them to be able to put their product in context of the big picture of what it is we're delivering. Right. And if you're in the, if you're in the platform or in the back end or in the technical side, more than ever you need to be able to understand where you are in context of the entire thing so that you know what your piece does for that end customer.

Speaker B: Right.

Speaker A: Yeah. Um, for me that's always been really, really critical.

Speaker B: Yeah.

Speaker A: What do you think? Some of the, what do you think is unique? I mean, we talked a little bit about it just now, but what do you think is unique about the role you play versus maybe what people traditionally think of as product management? More sort of front end, uh, product management where, where Marilyn likes to hang out.

Speaker B: That's right. Um, I think main differentiator is the horizon, uh, how much time things take. And I often talk to, uh, product managers in my team about this sense of delayed gratification that uh, you need to be constantly, you need to be able to work in the, ah, in the environment of delayed gratification because as uh, someone working with a customer facing product, you can run a uh, quick a B test or maybe you can go and test with your customers and then get feedback and fine tune it. Due to the fact that it takes time to make majority of the changes that we are driving on the platform side due to the fact that it's complex, it takes time. So as a product manager you do discovery, it goes into implementation, you help with prioritization, but you already start working on next discovery or on some other things when finally what you have been working on gets delivered. You get feedback from the customers that are happy or not happy, but you're constantly sort of off sync from this feedback loop and then you constantly need to switch and go back down to the feedback that you got for the previous thing that you have been working. So I constantly think about this, when is the feedback loop coming in? When is this gratification of customer feedback or return on investment uh, comes in. And that's I think the biggest differentiator for working with the customer facing products. And I think another aspect of that is also that when I work with platform products it's a lot about empowering other teams and it's exactly almost uh, quoting what you said Leah, that you know what we do to empower them. I need to understand how they contribute to and solve customer problems, what are the problems of their customers. So I constantly have two groups of customers in mind as well as overall business, uh, aspect for the whole company, but then also business aspect, how to, how do we deliver impact on our side and how does our business contribute to the company. So it's also this two layers that I constantly need to keep in mind. And I think that's the second differentiator compared to uh, some teams that are working directly with the end customers and can directly get this, oh, we sold one more product and this is how it contributes to the business.

Speaker A: Yeah, yeah. I mean I know for me one of the big things that, I mean I've, I've gone and talked to Marilyn's teams at some of her interpass jobs to say like you get, you are product managers no matter what anybody says. Right. Because sometimes when you don't have that end customer touch point people are like uh, is it really product management if you don't have it? And I'm like, yeah, because I'm not only worried about my customer who might be you other product manager, I'm worried about your customer.

Speaker B: Yeah.

Speaker A: So I, it actually this has this really weird macro micro thing going on in your brain. Because you're always like, how do I build my thing so that it can be multi tenant? And how do I make sure that whatever I'm building that is multi tenant to these, my internal customers or my user base actually solves the problem of their customers? That's another layer out. And so I think it takes a special brain sometimes to be able to be like, how can I layer in this context? Right. Um, and so you know, I find it, I find it just infuriatingly, um, just disrespectful to be like, ah, you're not really a product manager.

Speaker C: Right.

Speaker A: So I mean, I think, I think Marilyn knows that when I talk about that sometimes people in the room are like, oh good, someone said I really am a product manager.

Speaker B: So oh my God. Yeah. And this is the challenge, I think generally challenge of product management, that when we were scaling a lot in technology, there were lots of product managers and then maybe there was less attention to the core of the craft. And uh, I think coming back to the platform ecosystem, many of them became more project managers or more doing lots of busy tasks. But if we look uh, uh, to the platforms, it's so expansive if we are wrong in platform ecosystem that or in technical ecosystem that because then we don't set up our customers for success which means they have a harder time delivering as efficiently value, uh, to the business and to the end customer. So I think the product craft is extremely important when we talk about platform context because depending what problems you are going to choose, how good you are at executing on them and delivering impact, you actually can really make such a difference in the business. And uh, also managing opinionated stakeholders. I find that my stakeholders are much more opinionated than when I worked for example with mobile apps because then I could show data and then it was easier to resolve that kind of argument. So I think in platform it's extremely important to have a really good product management craft. But it is hard. It's not uh, something that, from one day to another, um, that easy to get established and run in the organization.

Speaker A: Yeah.

Speaker C: And you said two things that I absolutely love. The first is the way you just described technical product management. Said nothing about being an engineer and it's all about the product craft. Um, uh, and then you're 100% right about the uh, expense and latency, the learning cycle. Um, and I do think it's very easy when you get to what I will call the innovative edge where the user sort of touches the software. It's very easy to innovate there it's very easy to test and be wrong. It's very easy to course correct. You need to be right in the platforms, you need to be right. And so I actually think, um, and I think full respect to Leah who's taught me to be a better platform person, uh, I think you must be right. Your tolerance for being wrong, especially in big ways in the platform is very expensive. And that's actually where you need a lot of your product management skill to make sure that you're learning as much as you can before you deploy engineering resources to go do something. So I m love those two perspectives. Thank you.

Speaker B: Mhm.

Speaker A: Yeah, I mean I, it's funny because as you're talking I'm thinking, you know that a lot of times when I talk about platform, product management, I talk about like you draw the box, what's in the box. You absolutely do not give up the ground on the box. Whatever you said is the platform. Everything orchestration, everything innovative on the outside edge. You're free to do however you want other customers. But this box is my box. The trip in that box then is like really being crystal about the themes like what problem I'm solving for, what problems can I solve for, where can I be flexible, where do I need to add an adaptability, but where do we never give up ground so that we're not wrong. Right. And I think you know, having you know, I think that edge, you know, and saying like there is this, this is what's in the platform, everything. I may build some of the other stuff too. Like that's fine. If you need me to build it, my teams can build it, but it's outside of the box.

Speaker C: Right.

Speaker A: Um, and it's really drawing those lines and being willing to say yeah, this, you don't own that so I'm gonna need you to back away. Right.

Speaker C: So yeah, you talked a little bit about um, stakeholder management and opinionated stakeholders like what Leah described as real. Right. How do you manage 100%.

Speaker B: Yeah, just when you were describing this box, I could think about um, few discussions with, with stakeholders where it's, it's challenging because supporting the business would mean changing the boundaries of the box.

Speaker A: Yeah.

Speaker B: But also supporting long term business might mean to uh, stand the ground and keep those boundaries of the box. And uh, this comes back to understanding the business as well I think. And then it's a long intro to the answer to your question Marilyn, about stakeholders. In that sense there are many teams and whenever working with platforms, platform could solve so many use cases, but really understanding what's valuable to the business and then for that one needs to actually understand the whole business. So I really encourage also the uh, product managers in my team really understand how, how the whole business case goes together, how what is the business model, what are the teams working on? But another part of opinionated stakeholders is of course the senior engineering members and uh, architects and people who are really passionate about technology. Because this box wouldn't work without that. Right. So being able to bring in the right aspects, ah, understand the impact and help articulate impact sometimes to their frustration because of course it's very fun to write complex code but also working with them and supporting them. Right. And uh, also for them to support me and my team in the work that helps to define how the box looks like and then being able to really empathize with the challenges of other teams of business teams. So those are stakeholders but then there are also adjacent teams who also sometimes other platform teams, sometimes they are supporting platform team and uh, trying to move from. Well this is my, my line. This is your line. How can we handle this all together? And I think that's why the, the um, metaphor with the box that you provided Leah, was. It's really powerful because it's both helps but also it might lead to a really wrong way. So that's why it's also very important to understand how those, how the whole ecosystem works, how the whole business works. So that one could decide in the right moments to stand the ground and say no and in other cases actually say yes, let's figure it out. But it all comes back to really building empathy towards the stakeholders, different competences of stakeholders. It all comes back to building trust with them and uh, trying to raise awareness of how the inner workings of that box works. What is the value that we can deliver. And I think in the foundation it goes back to communication because if we cannot explain that in the language that they understand, um, it's very easy in platform just to do very complex language and very complex explanation and hope they

Speaker A: don't understand and question you kind of. I'm going to make this sound really hard.

Speaker B: Exactly. But then that doesn't help either, right?

Speaker A: No.

Speaker B: So being able for them to get their mental model of how things work and uh, how we can solve problems together. Yeah, that's always something that delivers value. But it's not like it's, it's not easy. It's challenging. Of course.

Speaker C: Yeah, it actually. So you guys have talked on this, um, this notion of uh, over complex, over complexification.

Speaker A: Wow.

Speaker C: Um, and simplicity. I Do I do find that, um, you're right. People, like, we want to build really complex things. Um, but ultimately sometimes simple is hard. And I think as platform people, and I'm looking at both of you, um, how do you balance between, um, complexity and then actually building something? Because simple scales. Right. Complexity does not. Um, so how do you balance that? Because you are the definition. Right. You're, you are the people that are defining what's going to get built and why. Yeah.

Speaker A: You want to go first?

Speaker B: Yeah. Ah. I think when you were posing this question, I was like, I wish there was this formula that I could pull and say that's the formula.

Speaker C: Magic wand.

Speaker A: Right?

Speaker B: Exactly. And then everyone can, can do that role. I think it's a lot about. Unfortunately, uh, the answer is long and, and, uh, complex or at the same time simple. Right. You need to, you need to figure it out. And otherwise it doesn't make sense to build the platform if it doesn't scale with the, with the business or it needs to. It doesn't scale with the use case, we can say like that. So I think that really understanding how the business works, understanding needs of stakeholders, looking at the trends across the market, looking at other competitors, and there are also conferences per area that I think staying curious is the most, uh, important aspect. And then being open to challenge yourself. But stay patient. I come back again to what I said with the delayed gratification since it takes months and in some cases years. You also need to figure out what are your success metrics. Proxy success metrics. On the way. Whether you are building something complex that doesn't scale.

Speaker A: Yeah.

Speaker B: Or is this complexity just, um, MVP on the way to simplicity?

Speaker A: Yeah.

Speaker B: But there is, you know, there are advice here, advice there, advice here. But I don't have a scalable.

Speaker A: It's not. That's because it's not that easy. It's not that simple. Like what's, what's funny is as you're talking, I'm thinking, and Marilyn, will. This will resonate with you. Um, as you, as you're. As you asked the question and as a Katerina answered, I was thinking that one of the places where I learned this was by running office hours at Amazon. Because in order to launch anything outside of aws, in order to launch anything, you had to come through the payments platform. You couldn't launch without coming to me at some point and saying, I need, I need to launch this thing. And I would sit in this room and people would say, I need to do Bitcoin in China. And I'd be like, okay, that is not a priority, right? Or, I need to do this. And there. And I'd be like. And I always laugh because I always say that everybody who ever came to office hours was like, this is very important to Jeff Bezos. And I'm like, no, it's not. Uh, I'm like, huh? Uh, I know. M. And so you have to play this game, right? But what happened for me across time is I could sit in the room and be like, all right. I could. As they described what they needed from the platform, I could sit in the room and be like, yeah, okay, I've got about 40% of that. Okay. I've got about 80% of that. Okay. I actually am already building that for that person. And I could just tag this on and that can stay in the box, but you're going to need to build this piece. And my brain could start putting the puzzle together, but that was because I understood the architecture of the box. And so when someone asked me for something, I could be like, well, that doesn't exist at all, right? That's not even a real thing you just described to me, right? And so I. And so I think what happened across time was that I thought in terms of themes, right? I had broken the box down into. I mean, this is where microservices come from, right? You break the big box down into bits and pieces and you go, oh, this. This use case needs only 50% of what I build, and I've got it all. Or it needs 50% of what I build, and the other 50% is somewhere else or I need to build it, right? And so you have all of this, like, this little puzzle that has to come together. And again, I think that's why platforms need product managers, right? Because in the absence of that, engineers. I love you engineers. Don't take this wrong. Build every time. We tend to go out and build every time, and it's like, you don't need to build anything. I just want you to add this, right? And don't. Don't do anything. So my job was to come up with the theme. And then the other thing that you said that really sticks with me is really having to help platform folks and technical folks and say, you need to come up with a measurement of what you are actually making possible. It is not about volume for you. It's typically. I mean, if you're running Amazon's payments platform, it is a volume game, but in general, it's not a volume game. And so what are you enabling? And so I Would always say there's this enablement metric that you need to figure out how to calculate. What did I make happen this year? What did I enable this year? Rather than I launched something fancy and innovative, like, what happened? Because you did your part.

Speaker C: Yeah.

Speaker A: And I think figuring out how to measure that will make people who have to really spend their life down in that space light up. Because they'll be like, I did a thing instead of, I built a box. Right. So because it can get sort of. You can get really in the weeds and be like, I just over here building boxes. Right.

Speaker C: Yeah.

Speaker A: But if I look at the box and go, I built a box and it enabled this and this and this, this, this, this, then you have this, this real energy behind what it is you do.

Speaker C: Yeah.

Speaker A: Product management. Right. So.

Speaker C: And I think the easiest, the easiest description of that box that I've heard, someone that's not in the box or doesn't build boxes talk about is, uh, Stripe. And I think we've talked about this before, Leah. They made it easy for anyone to integrate payments. Simple. And minutes, not weeks, months, like, whatever. And so I feel like platforms enable speed, they enable flexibility, they enable experimentation. They actually enable the edge to move faster because they're stable, secure, they have published APIs. You know how they're going to behave. I think platforms are the key to speed.

Speaker B: Yeah.

Speaker A: Yeah. I mean. Oh, go ahead.

Speaker B: Yeah. I was just thinking, because we're, uh, so, uh, paying so many compliments to the platforms. I think at the same time, one needs to be. Again, we come back to the craft of product management.

Speaker A: Yeah.

Speaker B: It's expensive for it to scale and enable business in such a fundamental way. It needs to be built in such a way that it scales, but also that it evolves. You never with any product, you cannot build the product at year one in such a way that it actually empowered you at year 10.

Speaker A: Right.

Speaker B: Uh, that's not. That's not possible. You also need to rework it along the way.

Speaker A: Yeah.

Speaker B: So I think also having that mindset of what's the right skill now? And then potentially changing it and having that humble approach that I built. I did my best. Two years ago, that was the right decision, but now we're in new circumstances. Now we need to rebuild it. So I was also thinking about that, that I think platforms are extremely powerful. But also, as any kind of power, you need to take it with care. And.

Speaker A: Yeah.

Speaker B: If it's okay if the business decides not to build platforms.

Speaker C: Sure.

Speaker B: And decides to build individual logics or buy things, because that otherwise one might invest a lot of money into something and then it will be a waste of time and effort. Yeah.

Speaker A: No, And I think I 100 agree. And I think, Marilyn, I've talked about this before as well. Like not everything is a platform.

Speaker B: No.

Speaker A: And not everything needs a platform.

Speaker B: No.

Speaker A: Right. And so, and, and I am a big believer in don't build stuff that someone else already spent $10 billion to build. Right. Like, I mean I was, we all know. I, like, I was basically, you know, berated for not building a Salesforce replacement. And I was like, why would I do that? Right. It's a bad idea. You know, like until it gets easier, which now it is getting easier. With AI, there's ways you can do that and that makes sense. But then it didn't make sense for me to rebuild that it existed and it took them years to get as good as it was.

Speaker C: Yeah.

Speaker A: Right. And So I think I 100 agree with you. Like, they are expensive, they are high risk. If you do it wrong, then it takes a long time. It can take a while to get in there and fix it. Not everything, because if you build it well, you can, you can make, adapt, you know, adaptations quickly. But, but there are, there are real, um, consequences. And so everything is not a platform.

Speaker B: No.

Speaker A: And I think sometimes we throw the word platform around when we, what we mean is a group of services that all talk to each other. It's like, congrats, you don't have a platform. Right. So yeah. 100.

Speaker B: But then coming back to where we started this discussion, how do you two differentiate a technical product manager? How do you define technical product manager versus platform product manager?

Speaker A: That's a good question, Marilyn.

Speaker C: I think part of this conversation is that we keep coming back to the same place philosophically. Product management is. Product management is product management. Um, personally, when I'm talking to um, the organization or a set of people that are less familiar, I'll say my technical product managers, their interfaces are APIs, not UI. Uh, because it's just sort of like an easy sort of like snap to make. Um, but I think the obligation, I don't want to diminish what it means to own services or platforms because again, when you talk about, um, when you talk about the speed and adaptability. Adapt. Adaptability and the cost of being wrong. Like it's easier to bring on a junior product manager and teach them on the ui. It's really freaking expensive and hard to bring in a junior product manager, teach them about platforms. So I think there's ah, from from my easy definition perspective, it's what's your interface? Um, what's your time horizon? Katerina, you see, you sort of articulated that very, very well. What's the, what's the cost of being wrong? Um, and the speed of delivery?

Speaker A: Yeah, for sure.

Speaker C: How would you define it?

Speaker A: Yeah, I mean I think, I don't have, I don't, I don't disagree with anything either of you have said and certainly not how you just described it. I think there is, I think when you move into platform product management, there is sometimes a need for technical product management when the product itself, um, even if it has an interface is more, um, is more directed at other software developers or at other businesses who are needed. So often in B2B product management you'll find more technical people. Like not only, I'm not saying only, but sometimes you have, you need, you have a need for a more technical product manager who understands the uh, infrastructure, the uh, technical pieces, how it all comes together when there's not a platform. And sometimes you need a platform person who isn't a, an engineer. Right. I'm not an engineer. Right. But I think in puzzles and I think in structures and I think in processes and I think. So I didn't have to be an engineer to be a great platform PM Right. And so like for instance, you might need a more technical product, uh, manager to run really heavy data platforms or really heavy AI and machine learning, if that is what you need and that technical person has that technical background. That's not me. Right. But if you want to build a platform, that could be me. Right. You know what I'm saying? So I think that there are some differentiations that happen here. Um, and sometimes it's for, you know, like you can pop people in and out. But like anything, it's really about in like, like you said Ekaterina, curiosity, willingness to learn. How do you think, how, you know, how does your mind process the complexity of this information and what does the product need practically? So we're back to what, why we talk about these things. Right. I don't need, it's the same thing I've always said, like if I'm running a payments platform, I don't need somebody with deep payments knowledge all the time. I need somebody who I can pop in and who can understand the puzzle and get in there and get it done.

Speaker B: Yeah.

Speaker A: I don't need industry expertise in that space. Right. But I might, if I was building FDA approved medical devices, I might want somebody with that kind of technical product knowledge. Yeah, right. So I think there is, there's some lines here that I think are get muddy and that we again we use words in multiple ways. So.

Speaker B: Yeah. And I think this also the example that you made with very specific in industry knowledge. I also reflect that whatever area I worked with, uh, whether financial services or developer products or you know, consumer facing apps, being able to build that and build that empathy towards the customer, I don't think it needs to come with from, from the start but it's almost becomes a prerequisite for the product manager to be successful to be able to build that system understanding of how it works. Yeah. And um, in with the example of accounting then maybe sit side by side with you know, accountants or CFOs to understand what is the workflow. The same for developer experience trying to write some code. It doesn't need to be the new uh, top technological startup. Right. But at least understanding and I also have done that now in my role in the previous roles. Just trying really to see how day to day of the users and customers look like. And I think that uh, it connects to curiosity. But I was also wanted to highlight this importance of empathy and building the empathy and really putting the effort into being able to operate in this industry even it doesn't need to be a very specific technical knowledge but it needs to be this workflow. Customer need jobs to be done. Understanding. Yeah.

Speaker A: Uh, yeah, well, and I think what you just did was just, you know, if we went back to the, to the podcast where Marilyn and I talked about what we think product managers, the skills you need to be a good product manager, uh, everything you rattled off is on the list. Yeah. Right. So it's not like, oh, there's this one magic skill you must have. Nope. You can, you can learn it, right? Yeah.

Speaker C: Yeah. I don't think it's terrible. Uh, I think that there's, you know, technical product management tends to strike terror in the hearts of some people and it's not terrifying. Like I, I would even say every product manager is obligated to understand their technology. Obligated.

Speaker A: Yeah, 100%.

Speaker C: If you don't, you're not going to be a great product manager. And you're also, regardless of where you sit in the stack, obligated to go sit with your users and almost do like main campus exercise. Like, um, the skills are the same.

Speaker A: Yeah, yeah, 100%.

Speaker B: 100%.

Speaker A: All right, Katerina, I'm going to throw you a um, curve ball. No, it's not tied necessarily to technical product management, but maybe it is Tell me what you're excited about when it comes to product management. Right now

Speaker B: I'm excited about the challenge. I think there is so much uh, around another wave of hype with Gen AI and uh, figuring out because I think in that huge wave of hype there is also a very strong stream of transformation of how we work. And this is where as with any hype wave, it's very easy to jump there and you know, uh, start building something that doesn't help the customers or it doesn't deliver business value. But at the same time it's also changing what knowledge do we need to have, what understanding we need to have, changing how we learn. So then at the same time there is an aspect of can we actually do something not delivering value but on the long term that would build the foundational knowledge so that we could actually leverage it uh, in a few years. And these are challenging trade offs. So this kind of challenge really excites me and makes me really curious how others do that. Trying to figure out, with stakeholders internally trying to figure out, you know, how other leaders are thinking about it. And uh, I think it's uh, at the same time not only to ride the wave but also seeing can we steer some of the wave. So absolutely this is, this makes me very excited and very motivated waking up in the morning. But I also, I'm very excited about uh, challenges that we can solve these days. So it's not on the um, hype wave if we park that one. But overall the technology is reaching such maturity that the use cases, uh, how we can help uh, uh, my customers internally as well as uh, other people around the world, I think that's uh, really powerful. So I'm very curious about that and that makes me very, very interested. How can I bring in my knowledge and skills into that?

Speaker A: Yeah, no, I love, I love what you just said because I think that when something new comes along and I'm old enough to have seen several waves, Marilyn's not, she's really young.

Speaker C: Oh, whatever.

Speaker A: But, but I, I love what you said because I think that there is, there is jumping in and being like we're going to dive with both feet into this thing and we're going to totally do something new and there's burying your head in the sand. And often what we need to do as product managers is find the middle. Uh, like how do I know enough to help us move forward but not, I'm not afraid of it, but also not necessarily diving into something that's totally not relevant yet for us right because all of our products, we didn't wake up on Tuesday and say, okay, now everybody stop what you're doing and go do this. Like, that doesn't make any sense, right? So I don't know. That's just my thought. I don't. Marilyn, did you want to add.

Speaker C: No, no, no, no, no. I'm a hundred percent aligned, I think. And it comes back to, um, you know, where are you investing company time, money, and resources, and what's the return on that investment? You can't hide your head in the sand. Um, and if you think back to, like, you know, when. Before phones became ubiquitous, you know, uh, for those of you that are. That are young, ah, there was a time when we all didn't have phones in our pockets all the time. Now everything is an app. Everything's very easy. I can turn to this little device and I can do pretty much anything I need to do. I believe some of the advancements in technology now will lead to a paradigm shift like that. We don't exactly know what it's going to look like quite yet. Um, but you're irresponsible if you're not exploring some of that, right? So that balance is really, really important. And understanding what and where you're investing your time and talent and directionally where you think it may or may not pay off for your company and your customers. But I don't. Yeah, don't, uh, bury your head in the sand. I am really looking forward to, um, the DJ on Spotify getting a lot more accurate with my recommendations at Katarina, because when I leave him alone too long, he gets a little crazy. But not just.

Speaker A: Also, we would like to have our podcast bump to the top of all the podcasts. I'm not sure if you're in charge of that or not, but how did

Speaker B: you tell you run your office hours, Leah? Uh, uh, everything you said was duly noted.

Speaker A: Carol and I each call in our favors at the end of the podcast. Anyone who's coming on this podcast just know we may ask for something.

Speaker B: That was the fine print, right?

Speaker C: Yeah.

Speaker A: Uh, yeah, you missed. You missed a tiny little print in white on the email. And P.S.

Speaker C: leah, you know how we say, like, one of the most important jobs of a product manager is saying no? Yeah, pretty sure Katarina's telling us no right now.

Speaker A: I feel like I taught her too well, right? No, that's not true. She already knew how to say no before I found her.

Speaker B: But actually, talking about teaching and leadership, I think I wanted to connect with something. Uh, what we when we talked just before and about curiosity. And you know what I'm excited about, I think also as a leader I'm very excited how to uh, have this culture of learning both for myself but also for teams that I work with. Because there are some, I think there are a bunch of ceremonies that everyone invented along the way.

Speaker A: Ah.

Speaker B: But I think actually now is the time when people really need to be able to pause all the operational chaos, pause all this fear of missing out and like step by step learn. So when you said uh, something that you taught me Leah, but I think I also was reflecting that as a leader, this like teaching of curiosity, uh, and giving space for the team to learn that I'm uh, I'm both curious about that, excited about that, but also in full transparency, also slightly scared how to set up the teams for success to be able to both learn but not be overwhelmed with that. So I think it's more there call out um, to other product leaders and uh, uh, other leaders overall across the board. How can we make sure that there is good learning structures and processes in day to day operations when everyone is uh, working a, uh, hundred plus percent in some cases and very busy operation in there.

Speaker A: Yeah, I mean I just, I just read a statistic the other day that said something like um, you know, I don't remember the number so I'm not going to try to quote it but well over half of employees are saying they would not leave even when the market shifts if they feel their company is investing in their growth and learning. So I mean we all know that the market is hard right now and so people are sitting still.

Speaker B: Right?

Speaker A: A lot of people are sitting still and sort of waiting. And we know that if the win, win, because it will when the market picks back up, that there will be an exodus. And one of these games of shuffle, right, like these people leave, these people come in, these people go here that like that game will happen again. But if you don't want that to happen, you need to be now investing in the learning and growth of the people that you're, that you lead.

Speaker B: Right.

Speaker A: Um, because that is what will make them say I'm not going anywhere. I don't care if the market's good.

Speaker C: So I think the precursor to that, um, and Leah, you're gonna tell, you're gonna kick me off my soapbox one of these days because I think everything comes back to this. I think as leaders, the other thing you really need to consider when you're talking about learning and growth of your people is how do you not lead with a culture of fear? And when people are delivering at 110% and we are working very, very hard, um, it's really easy for leaders to get punitive. You didn't deliver like, you failed at this. That culture is pervasive and it will stifle and kill innovation. If your people fear punitive action, if they didn't hit a number or they didn't hit a goal, and you're not treating everything as growth towards something,

Speaker B: you,

Speaker C: um, will kill your company, you will kill your stock. Ultimately, it just won't work because technology is all about exploration and learning. Um, and that needs to be cared for and fostered. Uh, so that. Anyways, that's my little hype jam.

Speaker A: No, I think it's super important. I mean, we, you can't say we're all about failing fast if you're not also about failing. Yes. So you can't, you can't have it both ways. You can't be like, let's, let's get in there and try some things and fail fast if you're not also okay when the failing part of failing fast happens.

Speaker B: No. And I think many people, uh, when growing also as leaders, they're like, yeah, of course I'm fine with that. But I think that you can really see that on the examples. And I think being able also to be there and, and be there and support there as a leader. And that's, uh, both give feedback, but also say, look, this is the real growth. This is not the theoretical growth that you read all over the articles and books, but this is the real growth that you will remember and you will learn from and be a better leader tomorrow. And also say the same to yourself. So also not to have the fear, culture of fear towards yourself. Because that all starts with the, with us and us being able to accept that, um, we make mistakes and we get. Any times we get tough feedback. How can we learn from that?

Speaker C: And we should share. So if, uh, if, I mean, mistakes are mistakes, it's not really a mistake, right? We tried something and it didn't work. We tried something and it didn't work. So did you cover it up? You showcase to the whole org? Hey, listen, like, we tried this thing. Not the right way to do it. We're going to try a different way. Do we talk about it? Did we showcase it? Um, are we offering it up? Not as a, like, you know, hey, that Frank over there really screwed up and did this thing like, Frank, um, or are we saying, like, Frank was brave, He Looked at all of the data, he made a choice, didn't pay off. He's going to make another choice. And so at quarter end or at year end or at review time, we don't punish Frank for failing. We would reward him for making a risk based decision and then trying something else. So I, again, I think it's very structural. Fear is very structural. Um, and so when you talk about things like, you know, Gen AI, um, a lot of this sort of new technology that's evolving, if you're not celebrating learning along that journey, because to be clear, no one's figured it out yet. So if you're not celebrating what the team is learning over time and helping people understand what it means to make this qualitative decision or the quantitative decision and then allowing others to learn and build off of that and celebrating the journey, you will not win. You will not win.

Speaker B: No.

Speaker A: Yeah, 100%. Anyways, I love it. Good, good luck gathering. Anything else you want to share?

Speaker B: I think I just want to encourage people to be curious, um, uh, also to. And I think curiosity actually is one of the, um, one of the ways how we can conquer fear. Because if we address what happened with the curiosity or we see that it's a uh, learning journey, I think that's the most important. And actually we celebrate the learning and we of course as leaders we still need to deliver business value. But then how in on the truth it will be such a better route if it is a curiosity driven and learning driven and uh, I think that uh, only creates a positive spiral up. Um, but uh, otherwise, no. This was such a, such a great conversation.

Speaker A: Yeah, this was so much fun. Thank you for coming and talking to us about this and, and sharing your, sharing your learnings and your curiosity with us.

Speaker B: Thank you for having me. This was really fun.

Speaker C: Yeah, anytime.

Speaker A: Awesome. All right, well um, then we will see everyone at the next podcast. Thanks Katarina. Thank you, Sam.