Do You Need a Product Operations Strategy? | Ana Zrno

In Episode 17 of Talking Roadmaps, Justin Woods speaks with Ana Zrno, Director of Product Operations at Wrike, about why every organisation needs a clear Product Operations strategy. Ana explores how Product Ops connects strategy to execution, avoids “process for process’ sake,” and creates value through focus, context, and enablement. Discover how having a roadmap for your Product Ops function drives alignment, clarity, and continuous improvement.

Ana is a seasoned product leader with over 20 years of experience spanning SaaS, telecom, and tech, specialising in product operations, strategy, and growth. Currently Director of Product Operations at Wrike, she has held leadership roles at Sinch, Infobip, and Tele2, where she drove large-scale transformations, introduced Product-Led Growth, and launched self-service platforms. With a background in both software development and strategic marketing, Ana brings a unique blend of technical depth and business acumen. She also shares her expertise as a guest lecturer at Algebra MBA Poslovna škola.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we are talking to Valentina Thörner, Head of Product Operations @ ZF, Speaker & Coach. So watch out for Season 2 - Episode 18!

• Transcript

  - I don't think that CPOs have problem to justify product operations when they're doing the first hire, to be honest, because they do feel that pain. I mean, product, it's a tough job. If you have a head of product or chief product officer, VP of product, doesn't matter, or director, not being able to feel that his full focus is where it should be. And that's kind of strategy, coaching people, you know, scaling the product team, thinking about the vision of the product. But instead, he or she's spending time maybe on the things which are less worthy.. I don't think they have a problem to justify hiring the first hire. I think the problem then comes when that first hire needs to show the return of investment.

  - Welcome everybody to the "Talking Roadmaps" show. In series two, we're talking product operations. And I'm really excited to speak to our guest today, Ana. Ana, you've got an incredible history in product management, product operations, telcos. Introduce yourself to our audience, please.

  - Okay, hi. So I'm Ana. Ana Zrno is the full name, which means like Mrs. Bean, which is kind of funny when you translate it from Croatian to English, but okay. I'm from Croatia, I still work in Croatia and Zagreb. And I'm what I call myself product person. So I was lucky that actually, I'm an engineer in the background by the first education, let's say. And then somewhere in the early 2000s, telecoms picked me up to work in the product development. So I was very lucky to kind of lend my vocation by actually a good hiring process, to be honest. So they kind of spotted my talents to put it like that. And from that day, that was, I think in 2023, so for more than 20 years, I'm actually in different product roles. And let's say that a little bit over half of that was spent with telecoms. And then I joined in 2018, Croatian unicorn, first one as growth product manager, actually, where I worked for some four and five years, I went up to the director, whatnot. And after that, I actually pivoted to product operations, and I did it on purpose, right? Because I felt that's the missing piece in many of my previous head of director of positions, I was missing product ops, and this is why I decided to explore that role. And at this moment, I'm actually a product operations person at Wrike. And Wrike is a leader, established leader in the CWM, which is collaborative work management, which is even fun because then we run product operations actually in Wrike. We call it Wrike on Wrike.

  - If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Ana, I love that. I mean, it's eating our own dog food, as we might call it. I've done similar for companies that I've worked at as well, but it's a great way of testing out your product. And also as a CWM system, as a project/product, road-mapping, planning type system, what better system to be able to plan and manage and demonstrate why product operations is so important. So, I think that's fantastic. Ana, I can see how the richness of your career has led you to this point and why you've placed yourself into product operations. And so my first question to you might be, why do companies need product operations?

  - Well, first is why you need product management, right? You need the product managers to be expert on value, right? That's the way that companies actually live or die, grow or not grow. You need them free to do their job, right? And in order to make them free to do their job, you need a platform in which they operate, kind of free to allocate their time, where that time is needed. And then how to create that platform. There are different ways how you create actually the environment in which product management is done and product development is done, right, and all software development process and everything. So one of the way is actually to call it product operations, as we are calling it. It's the whole environment around the product management. And why do you need a separate function for that? Well, simply because it's a huge job, right? And many times, product leaders simply come to the position where they lack time to take care continuously about improving the environment in which the team is operating. That's why you need product ops, like somebody to actually have an eye on the platform, internal platform in which the product teams are operating.

  - Yeah, no, I really resonated with what you said. It made a lot of sense, you know, the Wrike on Wrike. The fact that running the company or the processes, the operationalized part of the business is a full-time job or multiple times, you know, many people's jobs in some ways. And if we're not taking care of that, are we really compounding the efficiencies, the benefits, the opportunities that we could have? And so what was really a standout word that you mentioned, Ana, there was value. And I think that's one of the reasons why I think product operations has been even as successful as it has been because when you tie your work back to value, it makes it very easy to sell and justify in the company.

  - That's the reason why businesses exist. I mean, everything should connect to the value, otherwise, why bother? It's a waste of time otherwise.

  - I totally agree. But what's maybe profound is that I think, especially in the last maybe 5 or 10 years, we've seen companies spin up around a solution and not a problem, and then sometimes have problem as a result. And so I love that kind of that more veteran-style thinking that you've got, which is absolutely, we should be able to tie things back to value. But I think sometimes companies or departments can struggle with that.

  - Yeah. And specifically if you don't give, you know, doing discovery is not easy. So if you let people just, you know, without a system, which is kind of removing the obstacles, go and release them to do the discovery, it's tough. So you need actually a system to support removing obstacles from the people so easy so that they have an easy way to do their job. That's the whole point.

  - Yeah, absolutely. So in fact, you've just used another term, which I really like. So we've got value, we've got removing obstacles. Would they be the main purposes of product operations, do you think, or would you add other parts to product operations? What is the purpose of product ops?

  - So the purpose is to have this enablement structure for everybody to work in. Enablement platform, let's call it, not necessarily totally structured. And the other part is, let's say, the role that product ops usually can play and is playing, in, let's say, translating strategy or ensuring that everybody is aligned on strategy. And that's not that much technical role because product ops needs to be kind of half strategic brain, half technical brain, right, to actually enable the teams to row in the same direction in a way.

  - Yeah, absolutely. Well, what does product ops help in the organisation? Is it just the product managers or is it serving the entire company? What's been your experience?

  - Well, my experience is that product operations in general, and let's say from the four companies where I actively participated, either by holding this role or by being a director who was actually doing ops, it's very contextual. So it very depends on the system, on the evolution state where the company is, on the culture in the company. You know, my strategy was always the same. When you come somewhere, try to discover what's the biggest pain and try to solve that biggest pain. And then it answers, is it only serving product leaders, the whole product department, or is it maybe sometimes actually building bridges towards the stakeholders? It depends pretty much contextually where you put your efforts. But your final goal, and always, it's always the same goal, make the product operate as smoothly as possible because this is where the value is created.

  - Yeah, that makes sense. Before we hit record on today's session, we were talking about product operations. Sometimes people do it, I mean, I mentioned that I've done it a level of product operations or operational thinking when it wasn't necessarily specifically part of my role. I was a product manager, but I was doing those types of activities. I guess, how have you seen product operations set up across different organisations?

  - Well, to be honest, in the first company, so yes, every product leader in my experience also, even from telecoms, we were doing also the operation work, let's say, creating the environment, creating the culture, doing the coaching, putting up systems, which are kind of enabling people to work. That was kind of part of the job of the product leader. And the first company where we actually felt the need to kind of officially hire product operations was in the Croatian unicorn that I mentioned, where at one point, it was simply too much. So six product directors were kind of, you know, I would say, democratically splitting up the ops work on the six of us, plus our boss, the chief product officer. But at one point, we were simply spending too much time as the operation was scaling on putting in place the processes. And putting in place the operation process is not an ugly word, you know? Yeah, anyway, I will not do the digression now, but you know, you need some kind of ways of working. When you have more than two people in a room, you need ways of working, otherwise it goes bananas very quickly. Anyway, so we were putting that kind of ways of working, implementing different tools to support those ways of working, you know, pivoting, iterating, trying to scale product analytics, trying to scale discovery, trying to scale. And you know, at one point it became simply too much. We needed somebody, or few of them, to actually concentrate on the job. And for example, in that setup, I know it started as a part of, let's say, product operations was a part, was directly under the chief product officer. But later, as far as I know, that role in that particular company is actually now together with the user research and product analytics, you know, as a share pool, let's say, serving the many, many product managers. In the other company where I was, that company was growing by acquiring by a series of M&As. And therefore, example product operations was directly under the top, almost the C level, you know? Not directly even chief product operations, it was more chief operations, I would say. Because the need was to connect those product teams to kind of, you know, speak the same language and collaborate much better. And in the company where I'm now, so at Wrike, it's actually, I'm one of the directors, right? So we have our chief product officer, and I'm actually one of the directors. And my prime focuses is operations, while others are actually product management directors.

  - Excellent. So you bring that skill. I can see how at the moment your current role brings both of those parts of you, product management and product operations at Wrike. It was interesting that you said about mergers and acquisitions, M&A, because that's obviously a critical part of when companies start to merge and acquire other companies, you are actually having to merge and merge different companies or different product management groups that are now coming together with different working styles, different products and things like that. And that's obviously a really important area where you need to kind of try and be able to standardise that in order to make it one cohesive company, not just an umbrella company and just have lots of different companies within it. And so I can see how product operations would really work well in that space to try and standardise. And they've got a lot of work, a lot of work to make that happen that maybe isn't seen as being directly beneficial. We just think, oh, we've just acquired another company. They're part of us now. But it doesn't work that simply, does it, Ana?

  - No, no, it's always a big project and a big task to actually do that. And in the product domain, actually, I mean, even Wrike recently acquired a company, Klaxoon, so visual collaboration company. And we are just in the process of onboarding product managers. So we simply created the process to onboard the, you know, assigned the mentors, created the way how to, and not even onboard on one processes, on one type of working, but kind of share the experiences, you know, because we can learn. Two cultures can learn a lot from each other. That's something that product operations can orchestrate in the product domain, right?

  - Amazing. Yeah, that makes sense. And so there's one part that I'm curious about where you said that you have your product manager, product management director or product operations director. How have you managed the collaboration between product operations and product management? Can there sometimes be friction and overlap? And how have you helped smooth that out?

  - I don't think it's overlapping, to be honest. Everybody has their goals. So product management is kind of focused on the customers and users. And my customers are those directors. It's a different word. You know, the focus is different, and then we don't overlap much, I would say. You know, we collaborate tightly, specifically, I'm trying to enable them and kind of remove the obstacles, as I said, different kind of obstacles. It may be reporting, it may be planning, planning the planning, right? Like, giving everybody the same context, putting all the pieces for decisions to be made. So I kind of help bring those pieces in place but I'm not making the decisions about product myself.

  - Yeah, that's a really good point. That's a really good way of putting it. You are bringing all of the pieces together to allow the smooth process that needs to happen. It could be alignment roadmapping.

  - Yeah, but one also important, sorry, important question maybe, important thing to add. I mean, product directors have freedom to organise their units how they want, you know? I was never as a product operations like a process freak to go down to the team and tell them how to work. What we keep live is human APIs, right? So we have a quants of work and quants of standards where we interface with the other teams where we follow the rules. I mean, not all teams are created equal, so that would be I think a waste to kind of dictate the process to everybody. You know, everybody has their own flavour of agile, their own flavour of whatever the company is using, you know? So where my focus is, it's mainly in the orchestrating between the units, between the teams, towards the, I don't know, G2M teams for example, or engineering teams or whatnot. So this is where I see product operations, at least in the companies where I was. So more on the, let's say, strategic orchestration level, not so much on the team level.

  - Really nice. Yeah, that makes sense to me. The beginning of the conversation, we talked a about value and removing obstacles. I'm not sure if some of the companies that you've been in, you joined when product operations was already a thing and happening. But I think there's some companies where it wasn't and you adopted those roles. My question is, what advice would you give to people listening to the show at the moment, if they feel that product operations could be beneficial, how should they go about justifying product operations? Have you any thoughts on that?

  - Well, usually I don't think that CPOs have problem to justify product operations when they're doing the first hire, to be honest, because they do feel that pain. I mean, product, it's a tough job that knows everybody who was in product management, it's a very tough job. It's interesting, it's kind of fulfilling. it's the, you know, rollercoaster of life. It's something worth doing, but it's tough, you know? And simply, if you have a head of product or chief product officer, VP of product, doesn't matter, or director, not being able to feel that his full focus is where it should be. And that's kind of strategy, coaching people, you know, scaling the product team, thinking about the vision of the product, but instead, he or she's spending time maybe on the things which are less worthy to put it like that, for that position. Important, extremely important, but kind of taking the focus from the vision strategy and business, let's say. I don't think they have a problem to justify hiring the first hire. I think the problem then comes when, you know, that first hire needs to show the return of investment. And that's shown by actually, you know, doing a good discovery, spotting where it's burning, and solving the burning issues for the influencers in the company. That's also important to have in mind. So you have to, you know, your first focus is, there are millions of problems, you know? You can't solve them all. You'll never be able to solve them. Even with the AI, no. You will never come to the end of that backlog, you know, for the product ops, and that's okay. So you have to pick actually where you put your efforts in the beginning. And I would really advise to anybody coming to that role to spend some time on discovery. So to cover the pain of, yes, your first boss, also the main stakeholders. So to fix the bridges from product to other departments, which are usually not perfect bridges, at least in my experience. So to invest your time there and then simply go by the list of, these things will be visible and these things, if you spend, if you have a concrete planning, if you spend, let's say, focus time on, I don't know, doing the trade offs when you do the roadmap. And if it feels good, efficient, informed for everybody that's involved, that's a visible value. And it's really justified the role of the product ops.

  - Brilliant. That's such a good response. And I love that product operations is almost born out of a problem to solve, and then they stay for the continued value that they demonstrate. Yeah, I mean that's a great way of putting it. And you've done product operations, a number of companies. Are there some best practises or good practises that you see product operations teams doing?

  - I mean, the most important thing is not to become the process freaks. And I know that there is a discussion, a big discussion on the internet ongoing for a few years already between the gurus, right? Fighting of, is it the new process or new project office, or whatnot I mean, it's a trap that people can fell in because it's also fun to create processes, you know? It's fun to do that. But you know, don't be in your little black box and stay in the contact with your users and customers and, you know, keep the eyes on the goal. In the nutshell, it's the same principles as the product managers, as the product management is. So you have your objective, you have your key results, you have your audience, you have your users and your customers, and keep the pulse there. I mean, the worst thing is to create something that sits on the, I don't know, SharePoint or in Wrike or wherever, and nobody's using it. That would be a waste of your time, life, and the life of organisation, right? The advice is actually, yeah, if I may go back, that's also the reason why actually ex product managers or people who experience doing product are probably the best choice to start the product operations because they know the craft of product management, then it's much easier to be observed to the product management department.

  - Yeah, I fully agree. It's not a progression, it's a spur off of product management. A lot of people get into product operations because they just saw a need and they fell in love with the problem that is there. It doesn't mean that product management is the only path into product operations, but I think often the first hire can be because you've got somebody already in love with solving problems and demonstrating value, and isn't that the whole point. I also love the bit that you said about processes. It's delicate balance. You know, we can't standardise without having some level of configuration or standardizations or process. But also we don't want it to be process out of control. I think it has to be just enough process. It's certainly something that, as you said, that some of the gurus or the people more prevalent in our space have kind of talked about a bit more. But I think it is necessary because if you don't standardise on certain things, then, you know, your mergers and acquisitions are gonna be operating in different ways and you won't get the portfolio roll up that you need. And so it's just enough.

  - And you are spot on, it's just enough common sense. Processes are there to serve you, you know, just to establish the basic ways of working, not to be a dictatorship. And you know, something which is kind of very nice in a diagram, but not living. That's the whole point. It should be a living thing, you know? And also, you know, the best processes are those that people don't notice, you know? This is the way how we work.

  - I wonder if there are maybe some mistakes that you've seen people make in product operations where they've maybe gone in with good intentions, but it's not worked out well. Are there common mistakes that you see product operations teams fall into, or trap?

  - I mean, the trap is, beside the processes, the trap is being too operational. So simply reacting to, so not having a strategy, let's say, or a roadmap for product operations, however you want to put it. It's simply not having a goal. Maybe it's simply, you know, when you come to a company as a product ops, everybody will come to you with a list of the wishes, requests, pains, desires, you know, things they think should improve process improvement. Even there are product people who also come with a list of processes that should be improved and how to improve them, right? So it's easy to fell in that trap specifically for the people who are, let's say, junior positions maybe, or not experienced in product in general, or not experienced in the years of working in any working environment, to be honest. So let's say, younger people with less experience. That's the common trap, right? It simply becomes, I'm serving everybody, but then you miss the point of, you know, demonstrating that value that you're bringing. So you are bringing pieces of value here and there, but that's not the whole point, you know? You should concentrate on the strategic moves, and prioritise and say no. Same as everybody else, right?

  - Yeah, that's a really good point. It's not a wishlist of improvements that we prioritise without some form of strategic alignment or bigger purpose that we go through. And I think that's why there's a lot of parallels between product management and product operations just because the techniques and the mindset is often quite similar as well. So that makes sense to me. Ana, you mentioned about product operations involvement in kind of like discovery or roadmap. From your perspective, what's product operations involvement been in roadmapping? Have you seen where product operations have got involved with that? 'Cause that's often a heavy lift for product managers.

  - I mean, I can tell you what we have, for example, in Wrike and what we are using. So we have a different flavours of roadmap to be honest. So first you have the customer-facing, then you have internal for the discussions with the stakeholders. Then you have may have a roadmap for investors, then you have operational release calendar internally, right? So it's a different flavours of the same thing, right? And it includes discovery and delivery, both on them. Of course, those customer-facing is choosing which discovery to choose, to show, right? And internally you'll go much more open, but there are many flavours of it. And for example, for creating those, let's say, templates, ways, it doesn't matter if it's in the tool or in the PowerPoint, honestly. It's usually something where product operations is helping kind of orchestrate and synchronise and standardise in a way because, for example, roadmap as a communication tool, you need to standardise that one, simply because you don't want people reading different stuff from the same document or the different layers of the same document. And that's for example, something where, so, as product operations, you're not of course making the choice what goes on the discovery or delivery roadmap. That's product management job. But you are making sure that your customers, your stakeholders and your products on both, let's say, strategic level and technical operational level, that we know what we are reading when we see that in the tool. So this is how I think we, and in my case, and specifically in Wrike, I'm involved by organising the quarterly planning in events. And by organising, I mean kind of, you know, assuring again that all the pieces needed for decision are there. It doesn't mean that I'm bringing all those pieces, by all means, I'm bringing probably a small portion of it. But, you know, ensuring that we do have all the pieces so I'm that we can have a productive plan, which will result in the roadmap.

  - Exactly. And using a tool like Wrike gives you that central version of the truth, but those multiple views that you need. And so you have the same core data, but then you are choosing to share that out in different ways to different audiences.

  - This is where, for example, Wrike excels. So we do run the operations in Wrike because we can spot those different views rather easily. So you have one kind of document where you edit your work and you keep track of your work, and that document is then showcased in the different versions of calendars, dashboards, whatnot, you know, depending on the view that you need to extract for the audience. It always depends on the audience, right, who is reading that, who is consuming that roadmap. And then you have to adapt it. And for example, that kind of thing is product operations doing and, you know, iterating. Because once you put it, then you spot on one meeting or one roadmap presentation, how it goes. You see where the friction is, okay, you go back home, you iterate. And this is how, for example, you're doing a small product work, you know, and your product is the roadmap.

  - Yeah, I mean, it is. It's so meta. But you mentioned, you know, Wrike on Wrike, and I think that's so important. You know, you get to use your tool, you get to demonstrate your tool, you are using your tool to help you to do that function better. It's a beautiful thing. And actually it answers the question, the last question which I had, which is, do you need a roadmap for your products operations function? And I think the answer for us is yes, you do, and we are using Wrike to do that for us, which is incredible.

  - Yeah, don't add me, yes, but you know, it's for the product operations, I look it more in a little bit less B2B enterprise way. It's not so B2C, it's more lighter version of like, where is the focus now? What will be the next focus, and what we'll wait a little bit? So maybe a little different flavour of roadmap, but yes.

  - Yeah, exactly. Well, I'm really passionate about roadmap, and that's why Phil and I started up the "Talking Roadmaps" channel. My company Roadmap Heroes is trying to, whilst we're a tooling implementer primarily, we are really looking at actually looking at just what are good roadmapping processes. There are so many different tools out there in the world that there'll be always, you know, a different tool will be right for different customers. But actually it's just, are we even bringing the right mindset? I think a lot of product management companies don't even bring the right mindsets about product management and roadmapping, and a tool isn't gonna solve that. So that's kind of where I sit and why I'm passionate about roadmaps in general.

  - I mean, yeah. You need to know, you know, what your, as you said, roadmapping process is. And then you can put it in Wrike. But you need to be clear with yourself, how do we surface the discovery and how do we surface the delivery. So is it just, you know, an endless list of features and when they're going to be released, or do we inform also what we are working on and where we are not certain will it actually land in the delivery lane or not. So those things, yes. And those things are strategic and, let's say, culture view of how the product is done, and then it lands in the roadmap. And it's visible. Honestly, when you see the company's roadmap, you usually know the style, how they work.

  - That has been one of the biggest things I've found over my eight years of working in roadmapping, is that roadmapping is product management, really. And so, when you look at a roadmap, you can very much see inside how the company even thinks about product roadmapping. And one of the things you mentioned, Ana, which I loved, was the fact that roadmapping is a communication and alignment tool. And so audience-centric roadmapping is critical because if you want to communicate and align with a certain audience, your roadmap has to communicate their language. And so I love that. That's a big thing that I'm passionate about, is audience-centric roadmapping.

  - I mean, if you are going to speak with your stakeholders and your management board, then you need to speak outcomes, otherwise don't go there, you know, honestly. And on the other hand, if you are going to speak, you know, with your, I don't know, even the help centre people, you have to go to the level of the user story, right? You have to go to the level of the smallest quant being released because there needs to be a documentation for that part too. So it really depends on the level of what you're showcasing and what is your... I mean, it's always the same story, but the narrative is a little bit adapted to the public simply to serve the purpose, right?

  - Yeah, absolutely. Brilliant. Ana, I'm loving the experience and the anecdotes you're bringing to the conversation. I'm wondering, whose advice in product operations do you listen to? Where do you get some of new ideas and who do you respect in the industry?

  - I mean, I follow John Cutler to be honest, usually. Do I follow everything? Do I implement everything that he talks about? Nah, no. But I love the way of the system thinking and, let's say, the wideness of his approach to the craft, let's say. And I do, you know, took the inspiration here and there. I'm against implementing frameworks directly and blindly. So sometimes I do find, I don't know, Melissa Perry or whatnot, I do find some good frameworks. Will I bring it back to the company? It's blindly not 100%, you know, because it's very contextual. It depends where the company is, it depends how mature we are, how ready we are for some frameworks. It depends if that framework will fit our culture and et cetera. So I do kind of pick inspirations here and there, but I'm not sure, one-on-one, do I bring it back? But you know, we need to talk about these things because this is how you learn also. You see others' experiences, you read the books, you kind of, you know, if you read one book, you lived 100 companies, unlike me in my real life, so.

  - I love your mindset there though, Ana, because I think when we blindly adopt a framework, we lose, like you said, the context of why that framework, where it was born from, what it was intended to do, what it means, whether the company that came up with it is even using it anymore, what their findings were. That's really important to do, is take these, look at these frameworks, critique them with the curiosity that John Cutler could kind of look at it and go, yeah, I like that bit of it, but I don't like that. That's appropriate for us now, but it isn't for us, you know, in future. I'm gonna take that bit and use that piece. And I think that's really important, and actually is a missing part within product management and product operations. Don't go and lift off a tool. Take a lift from a framework or a tool and expect it to be the magic bullet. Actually just critique it, take the bits you like. And so that sounds like that's where your knowledge and experience come from, Ana, just that curiosity and going, yeah, I could see how that could work. And that's really meaningful.

  - Yeah, but it's the same if you, you know, draw a parallel with agile. You need rituals, and you need cookbooks when you are young and you don't know what you're doing, you know? And then a little bit later, you kind of become, you know, you'll learn the principles, which are much more important than the actual frameworks. So always the principles in product ops and in any product role, they are always the same. Have a goal, keep an eye on that customer, do your discovery really good before you start to invest in changing whatnot, code, process, whatever, right? And that's contextual and actually building with a purpose. And you know, if you go back to that principle every time, then you can kind of look with the different eyes on the framework. I mean, John Cutler has a much tougher job because he's usually thinking very wide. My job is usually much more focused on the organisation where I am. So my job is much easier, you know? I don't have to find one that fits all in the thinking, but, you know, simply take his beautiful thinking and think, uh-huh, can we apply it where we are or not?

  - And I'm gonna ask you a tough question here and you can answer it in a couple of words or a couple of paragraphs if you wish. But if you had to distil your philosophy of product operations into just a few sentences, how would you describe it?

  - Make yourself useful. You know, apply common sense and first principles of product management and help that product, you know, roll better, and that's it. Well, I think we philosophy sometimes too much. We have too much philosophy of how to do something where in reality, it's kind of put a goal, see where the problem is, test your ideas, pick one, go and do it. And if it doesn't work, well, go back and iterate. You are not like a heart surgeon, nobody will die. You tried. It failed. Fine. Go back, do it another. You know, keep it simple. Keep It simple, be useful, and you know, remember what your main job is. Your main job is that the product operation, that the product organisation is functioning smoothly. Go from there.

  - Yeah, I couldn't agree with you more. I think sometimes we try and make it bigger than it needs to be. It's, as you said at the beginning, removing blockers, demonstrating value, applying product management first principles. I couldn't agree with you more, Ana. So Ana, it's been absolutely fantastic talking with you. I've learned a lot from speaking with you. I love the approach, the experience that you've brought here. I'm sure many in our audience listening are gonna really resonate with what you're saying as well. How can people get in touch with you? Is LinkedIn the best place for that? What would you say?

  - LinkedIn is probably the best place to reach out, if you need. And yeah, I also, I forgot to tell that, but I also do kind of teach product management at the MBA courses, yes. Yeah, I teach here in Croatia. It's sometimes on weekends, you know, I have a modules with the students, with the grownup students teaching product management and product development at Algebra University. If you want to study product management, come to Croatia. It's a beautiful country, you know, in the middle of Europe. Very sunny. Very nice.

  - I was gonna say, and a growing product management and product operations culture, which is so important.

  - Yes, yes. We were lucky in Croatia too. You know, there was, if you speak product like 10 years ago, it was like empty space here. Now, due to few very good companies locally, which kind of brought the product community up, we even have MBA with the product management courses in it. So that's kind of big change for a country in a decade I would say. Or even less, even some six, seven years.

  - Yeah, exactly. It's fantastic to see growth coming out of those companies and it's fantastic to see product management and product operations experts such as yourself really advocating for our craft and being proud of your country. So, thank you. All that leaves me to say is thank you so much for joining us. Really enjoyed speaking with you, learning from you. There's a couple of little real golden nuggets in there that we're going to be able to share with our audience. So Ana, all that leads me to say is, thank you so much for joining us/

  - And thank you, Justin, for having me.