Product Operations Manager at Adevinta: Jonas on Trust, AI & the Quiet Power of Product Ops

Hello, hello, and welcome to another episode of Product and Cake. Here with me in the virtual recording studio, believe it or not, it's Gonsha. How are you? Hello, I'm really good. Berlin is sunny. Birds are chirping and we are in the summertime. By summertime I don't mean the actual summer. I mean just the times of. So I'm really happy about that. Yes, we enjoy the light and we also enjoy the light of our awesome shining guests today because here with us in the studio is also Jonas Kniehl. Hi, Jonas, welcome. Hello, that's me here. Jonas is Product Operations Manager at Adavinter. I think Adavinter is one of the largest classifieds company in the world, right? I think you serve about what, four billion users, months or something. Quite a lot. Definitely quite a lot and you are in the forefront of mobility, and we will dive with you together in Product Operations. That is super interesting because so far we only had Product Managers and VPs of Product and Tech. And now we are super curious to learn and to hear from you what the Product Operations Manager is doing, how you land into that role and what awesome product knowledge you can share with our audience. Excited to get into it. Before we do that, we start our podcast episode like every good meeting with a deep and thought through check and question. This time at Ziegontje, what did you prepare for us? It's not very deep and thought through unfortunately, but at least it can be. It can be. For me, it's a very fun question. What's the most recent thing you've regretted? It can be a small regret. It doesn't need to be a big life choice. It can be very small. Like, why did I order pizza instead of burger? Should I start? Or are we off sharing? Yeah, go ahead. Yeah. So actually this morning, I can share this morning, so in Berlin right now, the trains are a bit crazy because there's a lot of construction and like British almost collapsing. And this morning I was driving to my friends place to do some working together from home. And the trains were super packed. And I decided to take a train and it ended up going to the wrong station. I changed where it's going. And I had to get out to the next one and I couldn't catch the next train. And at that moment, I really regretted that I couldn't get into it because there were too many people trying to get onto the train. But then when I took instead the bike to my friends place, I ran across a friend of mine who I haven't seen with her new born child. And I hadn't seen her for like, I think almost a year, and we just like ran into each other by accident. So in the end, my regret turned out to be super, super, super nice. And I was already in a bad mood after that. But then I was in the most, most amazing mood. So everything kind of happens for a reason, I guess. That's really sweet. That's a very nice way of looking at it. How about you Paul? Is yours also as shiny and nice? Look what our Berlin public transport is doing for us. That's very bad. Yeah, I have also a regret from the last days, basically from yesterday, because OpenAI was publishing their new image generation for all. And I had a day of answering every message I am receiving. It was a very well fitting picture of mine doing something. And it was a great fun. And it was, but in the end, I spent so much time waiting for this thing to generate images for me. That was, yeah, in the end, I regretted it. I thought it's, I need to check the future. But in the end, I spent so much time waiting. And I have a lot of funny pictures now, but it does not bring me forward. What about you, Gonja? My regret happened very recently. I tried to, I'm trying to paint the wall in the living room. We bought a couple of white couches and against the white wall, it's just like, it's really, yeah, it's like not visible. I was a big fan. So I thought, okay, we need to paint the wall. So the couches pop. And I tried to do a line wash and it's not going very well. It looks really bad so far. And I don't know if it's because of the, I think the color is too dark for the line wash that I wanted to do. So let's see how it ends. So far it's not going great. A nice check in question. So you hear we are all humans, right? Still. Yeah. And we all have our regrets, but we are so happy to spend now sometime here together in the podcast and learn more about product operations. Yes, exactly. And Jonas, I want to start with a very simple question and for those who don't know you, how would you explain your job and a very short sentence? Oh, short sentence. Maybe I can actually steal something or go into disappeared, but I'm sure she will join us in a second again. Right. So short, I can give a short explanation of the topic. I'm actually going to steal it from because I was talking to a product operations person from Kleinerzeigen. I think last week, and he had such a great explanation that I think I need to steal it. So if you think of the James Bond franchise and you think of the whole organization around James Bond, there's of course the 007 James Bond out there, which in our case are kind of the product managers, but then behind them. And they're really monumental to his success is the technical organization, Q, which supports with tools and in later stages also data and other things. And I think that's very similar to how I see product management and product operations with product management being the agents in the front and then product operations being Q in the back. And thanks for thanks for giving me this, I think very accurate description. So that means you show up with the product managers and saying, Hey, look, I had all my awesome AI tools I have, but don't press this button and the product managers come and always press the button. Sometimes product managers, sometimes engineers or management also often so different, different people. There is always someone who wants to press that button. But how did you end up here? And was there a defined moment that you ended up in product operations? So for me, my journey to product management actually started kind of already during my bachelor time. I was working in mechanical or as doing mechanical engineering as a comprehensive study degree. And I was working for a mechanical engineering company. And I was doing a lot of process optimization topics because I for some reason really liked doing this and looking, yeah, primarily looking at processes and how to do them better on this mechanical engineering front. And then afterwards I switched into tech as we kind of oftentimes do through many different ways. I mean, UX research before that, but when I went into product management to create a bit more of an impact on the actual product after doing research, I always kept on doing and asking myself about processes, about tools, how to optimize things further and recommending tools and processes to others. And then at some point, I guess that was that was hard and seen by our managers at the winter. And when we're doing a restructuring, I think one and a half years ago, I believe, I was just asked, hey, we have this new position that we think we need to fill in our organization with this need. And would you like to step in? And that's it, yes. So we are talking about quite a big product tech team, right? And a lot of product managers, can you quantify it a little bit? So if I check our select channels, I think it's like 80 or 90 people inside of the product and UX organization. Wow. And I think I believe around 40-ish people are from product. So it's quite a large chunk of product managers. - Definitely. - Yeah. So what would happen if all product operation manager would disappear tomorrow? What would break first? - So I think product operations is something that never really disappears. So maybe like the people would disappear with a designated title, but someone else has always been taking on the jobs that product managers have been doing. Sorry, that product operation managers have been doing. So oftentimes it was leaders of some sort, maybe management, their parts that lie with research functions, their parts that are typically more connected with data, or product managers were taking on these tasks. So I guess different people have always been doing the kind of work that I'm doing now, but just not at the scale and with the focus that product operations managers can do. - Yeah, interesting. And I think it is so wise to have designated people who have the time and the mental capacity to think about certain things to make them better. Because as you said, if you don't specify that and give a clear responsibility, someone will do it maybe at night or late in the day or during a boring meeting, and the results of that kind of work, right? It's never excellent. So that is interesting. Maybe you can tell us, what is a misconception people have about what you do? - I think oftentimes it is really associated with creating strict processes that people have to follow. Now there's this role, and now we're gonna have like a million processes that are gonna get introduced, and people have to follow these seven steps, and I'm gonna annoy them when they don't follow them. Which I think is sometimes true. So there are, there are sometimes needs to be processes in place, but of course only where necessary. So it's not a role that tries to create overhead for people, but rather tries to fix user problems that product managers have. So it's very similar to the product management role actually. And as you myself, still as more of a product manager, for product managers, then I see myself as like a specific operations rule. - That's very interesting the way you put it, that you're a product manager, that your users are basically product managers. And I want to understand what is the biggest challenge you're facing right now in your current role? - I think a challenge that typically people, or like at least what I've been talking to other approach operations people that are also having the same challenge, is when you're starting out with product operations, you're kind of like a lone wolf rule, you're one person, you're part of a greater organization. And operations is kind of still quite new and undefined. So it's not really clear where your boundaries start, where things end. So all of this needs to be figured out and settled. So I guess the biggest challenge right now is still that starting out with product operations, there's typically just one person, and a bit more of a lone wolf trying to work into a certain direction and having to explain a lot of people why they are there and what they're trying to do and how they're trying to help. - During this process and being a lone wolf, do you see you need to onboard a lot of people to what you're doing, so make sure to get their buying and gain their trust, is that also part of that challenge? - Yes, for sure. I remember, so I think I spent the first, maybe three to four months with a big focus on explaining what my role is, how I'm here to support, also spending a lot of time just listening to people, obviously, trying to understand what the challenges that people have. And I remember after this time, I think after maybe five or six months, one tech lead reaching out to me and saying, "Hey, I was really skeptical of you and your role when you were starting out and why you're in this position, but now that you've done some of the work and you've explained why you're here and what you are trying to do and I see some of your work, I'm onboard a distraught thing." So there was a small success moment. - Yeah, very great success. Maybe you can elaborate a little bit more about your strategies to explain your role, because I think in such a big organization, it's also somehow complicated to get attention. Everyone is already overworked, everyone is confronted with a lot of new roles and changes all the time. So what was your maybe your key things to reach the people and to get this positive feedback? - So I think I was in a very privileged situation because at least from product, everyone was really looking forward to the introduction of my role. So if we're talking, if we're looking at the whole organization, leadership had a big buy-in that this is the right thing to do. Product, I think a lot of people at that time were like reading books from our decadent and that included part of the operations. Everyone was getting fired up that this is the next new thing that we need to introduce it. And yeah, so I think leadership generally had already a buy-in that this is the right thing to do, which is of course a very beneficial. I didn't really need to convince others why I should focus on topics and why I should have the time to focus on these topics. For product managers themselves, I think it's typically, or I would say, it should be very easy for product operations managers to convince product managers that they're helpful because every product manager is so focused on optimizing things, on fixing stuff. And then when there are things in the organization, I think I've never talked to a product manager where they didn't have at least like 20 minutes of things to share like, hey, this is what's wrong. This is what's not going so well. I wish we would do this differently. So in the beginning, I think a lot of the sessions were almost like, I think basically called myself more but therapist than product operations manager 'cause I was just listening to people like, finally there's one person who listens to me and who thinks about some of these topics more holistically. Then for example, like my manager and our silo would have done, but then others would have done it differently. - Great. I love the title a lot like Senior Product Therapist. That makes it very clear and gives a good picture. Thank you for that. Awesome. So basically someone where I, as a product manager who's already overworked or maybe also as an engineering leader can just offload my ideas, right? That are not fitting very well into the current situation maybe or okay, I could write an email to the CPO but if that is read or not, it's questionable. So you are basically the open ear and you can fly around in the organization and collect all the changes, all the moods, all the stuff that is going on. - Yeah, it's an enabling function. So I'm trying to make product managers lives easier in the end. And yeah, for that I do a lot of listening. - Awesome. - You know what also enables us a lot? The two big letters, AI. So how is AI shaping your role or your industry even? - I'm thinking how many touch points I have with AI. I feel like it's already become such a normal thing to work with AI that sometimes I have even, not even sure how often I'm using it because it's just so integrated. So for me personally, I think it's helpful to have AI as a part natural bounds ideas. And yeah, I think that's a big use case and then also for, I do a lot of communications work. So if I try to put a change like, I don't know, I have a process that I think should be optimized or should be introduced. in the company of our size or that's that's maybe actually a little techlet from the other side. I wasn't a startup beforehand. And in the startup, I was also sometimes optimizing things. And when I was looking at the way we were, I don't know, deploying features, typically a change should have process, which is to be me thinking up some kind of idea, maybe challenging it with someone who also works on the topic. And I'm going to the team of three people next door and saying, hey, by the way, that's the thing we're doing from tomorrow. That doesn't really work on the organizational scale of other venta, because we have so many people that are impacted by changes. So a lot of the work is also around communications. And AI really helps with creating templates and communication plans and everything around that. Yeah, that is a very beautiful thing to use AI as a sparing partner. I think for me, most of the times it generates from scratch very generic stuff. But when I've write something or do a presentation, whatever, and then throw it in and I say, okay, you are a super critical product manager who don't want to have anything changed at all. Give me your toughest three questions. Then you get really valuable insights that is maybe something you were not expecting in the beginning. I should copy that. That's I'm going to attack that super critical product manager. Yeah. I have one one quick follow up question. And do you think it would be possible to have one product operations manager and replace all the product managers with AI agents? I mean, never say never, but for now, I would say no, because the role, I mean, I'm not I'm not really overseeing product managers as much as I'm enabling them. So I think in that combination, I mean, I wouldn't come to me and say like, hey, I have all of these challenges that I need that I need help with. So I'm not really like a manager of product managers. Maybe that would be an easier life also when I are AI agents or the product managers. There is no need also for product operations role because there is no one complaining. But I'm sure that the challenges themselves. Yeah. Talks to itself. Like, how can we solve this? I want to go look a little bit back and ask you, what's one thing you wish you've learned earlier in your career? So also outside of product management or within product management. As you wish, you can you can specify to product operations to your in general to your career. What's one thing you want to go back in time and tell your younger self? I think this doesn't apply to all to all functions. So for example, if I would be an engineer head down in my tasks, maybe I wouldn't need that so much. But for me, I think it would be like never underestimate how important people relations are. And building a strong network of and like knowing the people that you're working with from different scales, I think this is really helpful in a corporate environment like at the winter or mobility. Maybe in the startups where I was before, it was easier to get to know everyone and know their stances and their problems. But at mobile, it's, I feel like it's almost a full time job to be even updated on what everyone's doing, what their challenges are and getting buy in from different people. So I think people relations and is something that I think is very valuable and oftentimes overlooked in the beginning of someone's career. Yeah, very true point. And I think it is also very important to remember that you are working with people together right now. But but in five years from now, they are spread across all other companies, right? And countries maybe even so you definitely want to invest into that network and know people who are working maybe at the company you will work in the future too. Or actually, I have another another thought to this and it's actually a learning from you Paul that I that I still remember and that I'm trying to apply all the time, which is I like how you oftentimes say, okay, I want to do more stuff that I that I really enjoy doing. I believe it would oftentimes talk about prioritization and how to prioritize things after like I was talking about like ice and rice frameworks and how to do this and like different kind of mapping with stakeholders and you're kind of talking about like, hey, I think I just prioritized by what I also want to do and what I'm excited about and I think that's something that's that there's something really, really cool about that. And I believe I would love that my younger self would have taken that more into consideration because I think especially in business, sometimes we forget. We're like so business focused about KPIs and we forget ourselves a bit and I think that's awesome to have that as a component in it as well to go by okay, that's a super awesome topic and I'm burning for it. So I should go further into it and I think that's nice. Yeah, thank you for remembering myself also on that and yeah, it is very true doing things you enjoy doing can give you a lot of energy and you can invest that energy again into the things that must happen. Now you are looking back already for quite a few years or in the product world what's the strong product opinion you have that not everyone agrees with. There are too many analysts. I think that's the one thing. That's so funny. I think I think I'm going to like a lot of people are going to hate me for this, but I think and I think oftentimes it's it's not the analysts fault. If I look at if I look at some of the organizations that I've worked in the past, a lot of like when I was actually trying to get an analyst to help me with a topic oftentimes the backlog was so long before they could actually help me with analysis because they were like trying to oversee kind some kind of systems and like figure out things in Google analytics. So actually maybe it's not so much about the analysts, but the systems behind it, but I feel like it's just way too complex. The whole systems around the analysts have to work with there's just there's just too much complex work that needs to get done in systems before people can actually do the analysis. I think I'm going to like one thing to have an analysis and then analysts telling me okay I can do that in three months and I was like, but I need I need the analysis now and I know that I myself could do it not super well, but maybe within half a day. So I was always like why does it take so long, but yeah, I guess sometimes to get it right to have to take longer periods of time. Fair point. I think how I would rephrase that is the aim for quality over pragmatism in the data analytics world is too high for the liking of product managers. Yes, I think as product managers, we are really boom, boom, let's get things done. Let's go and like break things and like very. I had the same I had the same coming from UX research actually in UX research, I was always like I went in from UX research into product management because I was like, hey, as UX research, I'm doing all of these like research and finding all of these amazing findings and then the product managers never do the things that I'm telling them that the user is required. And see that that's how it felt me so I came going to get into product management and it's going to be different because then I can create impact and I can do the research and then going into product management, I realized myself being like, okay, yeah, that's. It's a part what you're saying, but there is a lot of other components that I also need to consider. So I'm pretty sure that now you're, you're so sure looking at me the same way that I was looking at product managers to beforehand. You're likely, but similar to this we have we play a game and it's called yay or nay and we go through a couple of centers. and you just need to say if you agree with that statement or not. You can add your reasoning and then we can see, if you're short reasoning, then we can see if you're aligned or not. So the first one is a PM should always take the side of the users, even if it goes against business schools. Oh, I would say in name. I would, I think generally I would love PMs to take a user side, but sometimes there is a strategic topic from that that the company needs to go into and then it's important that product managers take that into consideration as well. And in the end also, like, we need to create value for the user, but it also needs to work for the business. So yeah. I agree 100% with your opinion. A big important part of the product role is to understand business needs and we can always contact with this famous sentence from Henry Ford. If I would have asked the people what they want, they would say faster horses. So users are also not always right or maybe like the UX analyst you mentioned, they don't see the big picture right and you are in a special position being able to talk to everybody and then condense it. And to build your decision. Yeah, I fully agree. So the second statement. Every new feature should require detailed business case before development starts by feature here. I mean bigger features, not not changing the color of a button. Every big new feature should require detailed business case before development starts. I would say. It's also tough. You already have tough questions. So like I could argue in both directions. So I would say I would say may on this one actually. I think sometimes you build a feature and it develops from there. And then you start suddenly like define or find a business different bigger business value behind it. And also it's a product manager's job to sometimes like measure something through a B testing, which can then quantify some of the business case logic that was done before. I think if you do like super fast prototyping to validate things that could be an alternative to business cases or an addition to business cases so they don't always need to be. All right. My answer to that is a is a yeah, I think I think for even. I wanted to say even for a change of a color of button, you need a business case. The business case doesn't need to be necessarily that oh, we believe this brings this much revenue, but you need a why behind every single thing. And I had a feature template document, which I think you're John as you have seen. And every feature template for in gyro, trill or whatever needs to start with the why that's why and they impact that's my opinion. I would I would agree to your why and I totally underline it explain at least in one sentence why and for me, as you mentioned before Jonas, the why could also be hey, this is a super fun thing and we want to have some fun. Then it should not be super complicated. Obviously, but that's a for me, sometimes a reasonable why, but a why is a complete different thing to a detailed business plan. Yes, our business case. Right. If I would ride two or three pages and explain and forecast all kind of numbers and business case evaluation stuff upfront, then you spend maybe the time with axle instead of prototyping your feature. Yeah, I still think you need a business case for the big features. And even we are building something for fun. Fun is a business case in my perspective. I think the issue here is with the detailed business case, maybe in the building. Yes, we can detail a lot of different things, but I love the why for sure. I would if I can add to it, I would love if the business case behind it and the why is based in user needs. So there's like a business benefit, but based on user. User problems user needs. Exactly. Thank you for bringing us off to it. I wanted to say thank you for operation, realization operator. I can't tell them say the word operator for us. Yeah. And I don't think business case means a case for the monetary value and just for the business business case can be a needs to take into user as well. And last one last statement. Let's see if we agree or disagree here, a B test can be skipped because of the team is confident in their instinct. Oh, so I actually, I spent a lot of time working on discovery practice at mobility, a not going to go to be a big enter topic, but I love the idea that I think it's a good land. So it brings up where it says, okay, there for every investment in development time that we do we should have a certain amount of confidence that this is the right thing to do. If we spend a year on a topic and the team team thinks this is a really good idea, but they have no confidence for it, probably not a good investment. So I think if this is something that's like super small, like change of a button or like a color of a button or something like that, you can skip sometimes a be testing. But I think if there is a certain amount of investment that made to make I don't know a month or more, we need to do a certain amount of we need to have a certain amount of confidence and that could come from maybe testing or something else, but just got feeling basically gives no confidence at all. But I also want to bring in the context because you live in a very comfortable life with a high traffic website and you do an A/B test and you get significant results within what days or hours even. If you are living the start of world or maybe the product life of a product that has not so much traffic, then trusting your instincts is valid from my side and also I would always ask if your need for a B tests is coming from shying away from taking the decision. Because it is so easy to say I don't know which color is better. Let's I don't want to think about it. Let's do an A/B test and let the user figure it out. I think you should start always with a good assumption. What is the winning variant in this test to not comment on it? Yeah, of course, please. I agree. Sometimes I think I want to take it a bit bigger than just a B testing and just saying like some kind of evidence for it. For me that doesn't need to be a B testing, even in a startup. Again, talking about how much time we have to invest into a topic. If you would say, hey Jonas, your team needs to work three months on designing feature why? Maybe I can't do a B test, but maybe I can look at competition and see, okay, do they have it? Maybe I can interview some users, some rapid user testing, I can talk to internal people and just do some quick prototyping, some other type of discovery. And I think if we include that into there, I think I would always love to have some kind of evidence if it's oriented for the amount of time that we have to spend into it. Very, very good addition evidence and also early proof points. If you have a feature for three months, what could you do in one week and get early science that this is the right direction? This is a very important thinking practice for product managers or product people in general. Yeah, I fully agree and I will not open the conversation about where does the gut feeling come from. But that's a conversation for another time, but gut feeling in general comes from experience. I also value that even though it might not be necessarily very obvious evidence, but we all have some gut feelings that proves to be true due to our experience. And especially with the technical background you tend to not trust your gut feeling enough and there are studies showing that our gut feeling is actually pretty good and pretty advanced after a while of experience. Definitely. Exactly. So many follow-up topics. I love the discussion. Fantastic. But let me ask something different. What are you learning right now? Is it a beard work or live related? So live related, I'm starting to surf or I started to surf in the past eight months and I have become absolutely obsessed with it. It's very nice but it's also kind of scary. It's cool new hobby to have. Work related. I'm still working a lot on my change management practices or helping with change management. And it's a topic that I'll probably be continuing working on within the next years as well. So I'm right now focusing again on the topic and diving deeper into it and understanding how I could support it. So that's something I'm learning on the work side. Nice. Amazing. Thank you for sharing this with us and thank you for joining us on the podcast. Where can people find you? On LinkedIn, just with my name, I'm Jonas Kniehl. You can find me there. Fantastic. And then we will follow your social media career on LinkedIn from now on. I'm ready to be a product operations manager influencer. Nice. Nice. Thank you so much for joining us on this chat, Jonas. Thanks a lot. It was really fantastic talking to you. A lot of inspirational thoughts and a very interesting role. I'm looking forward to learn more from you in the future. Thanks for having me. It was really fun. And yeah. See you next time. Bye. Please don't forget to subscribe and like and recommend and do all the nice things that you do to the podcast you love. Bye.