Should Product Operations be involved in roadmapping? | Valentina Thörner

In Episode 18 of Talking Roadmaps, Phil Hornby speaks with Valentina Thörner about how product operations can unify distributed teams, strengthen communication across functions, and improve roadmap alignment. They explore async collaboration, documentation habits, process design, AI-supported workflows, and the realities of scaling product practices inside a complex, multinational organisation. A practical, candid look at where product ops adds real value.

Valentina is a remote product and ops person, supporting tech companies at the executive level to create a distributed reality that works for their specific setup - offices optional. At ZF she leads the digital transformation of the groups legacy software towards an agile future. She runs on trails to think.

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).

Should Product Operations be involved in roadmapping? | Valentina Thörner

Valentina Thörner and Phil Hornby

In the next episode we have a returning guest from season 1 Becky Flint, Founder and CEO @ DragonBoat is back to talk about Product Ops this time. So watch out for Season 2 - Episode 19!

• Transcript

  - So we kind of make sure that everything is in one place and accessible to the level of detail the different people need it. Everybody's complaining nonetheless, but that's just, whenever there's a roadmap, people will be complaining. That's just a fact of life that I've come to except.

  - Welcome to "Talking Roadmaps" season two. Well we're here talking about product operations, today, I'm joined by Valentina. Valentina, we've found ourselves working together at ZF with me taking a job recently. I'd love to know, just to just introduce yourself though and tell us more about what you're doing in the product operations space.

  - I work in one of the software, let's call it software beds of ZF. So it's kind of a small division, 700 people, and we are building the new orchestration platform that helps fleets to manage all of their assets and their missions. Personally, I'm doing product excellence, why do we call it product excellence? Because product operations in a manufacturing company obviously means some, means something completely different to what it means in SaaS. So we had to invent a new name as to not confuse everybody else in ZF. So product excellence is what we call the department, but we do what product operations do, which is basically helping product managers to do the best they can with the resources they have a available, which sometimes includes training, sometimes include actually finding new tools, analysing where are the gaps that we actually have, figuring out where our product managers at the same level, where do some maybe need more help than others. And yeah, that over three different business lines within this software division and over officially four sites but with several remote people adjacent to it like satellites. So that's why I came in because my background is product and remote because remote operations require a little bit of an adjustment to everybody in the office operations and that what I've been doing in the past 18 months from now.

  - If you're enjoying the channel, subscribe, hit the bell and give us a like. Very interesting, yeah, I actually helped another organisation rename their product operations team. They ended up at product execution as opposed to excellence partnered with agile delivery leads within that same function and as well. So it was a, they needed a different name, I thought, I can imagine product excellence also in ZF. I can imagine someone thinking is that a quality function?

  - Yeah, I get a lot of questions, but actually I like it when people ask the question because like there's nothing worse than assumptions in product and that also happens for our role. So I prefer people to be confused and ask, "Wait, what are you actually doing?" And then I can kind of set the record straight that them assuming that I'm organising the delivery manufacturing plant, which is not what I do.

  - It's really, really interesting that kind remote focus because when I worked for a competitor of what you do now, that's when I started my remote journey back in 2008. So yeah, to me it's just, I can't think of a different way of working. I would never work any other way, but I know for many it's still a, COVID forced the hand of many and it's still not really mature.

  - Yeah and most don't really appreciate that remote is a different way of working. You can't just send people home with a computer, fingers crossed and hope for the best. Like that's not how humans connect. And even if you have, if you have more than one side, you need your operations to be set up for a remote environment because the people in Dublin will look at the people in Lausanne, will look at the people in Belgium like everybody will be like "What are these people doing over there?" So unless you have like some kind of mechanism to bring these thoughts together, you'll just end up with like people building in isolation.

  - I remember when COVID hit, I actually sat down and wrote my five dysfunctions of remote teams, not as a book, I didn't try and replicate Lencioni's work but I you know, hit a nod to Lencioni's "Five Dysfunctions of a Team" it's like what are the five things I see going wrong in remote teams? I'm sure we could unpack that but that's going really off piste. So let's dive into product operations then. So why do companies need it?

  - As soon as you have more than two product managers, streamlining what they do is really difficult. Let's say more than three because with three people they can still sit together and figure out, hey, how did you do this, what can I learn from you, which tools have you discovered? But as soon as you scale, it becomes really, really difficult to kind of figure out who is ahead of the curve and how can the others learn from that. Traditionally the head of product or VP of product or whoever's at the top was supposed to do like both having kind of the product focus but also the managing the team, developing the team focus and also the how to set up the operations. But at this point it becomes so complex that having only one person doing this, one of those three areas is going to drop off the radar and it hopefully is not the product area because I mean that's what you have the VP of product for. So the easiest, and I'm saying that in quotation mark to kind of give to a different function is the whole operations part because you can do a lot with looking from the sidelines, analysing what's happening and then figuring out how to improve the what is happening without having to influence the product itself.

  - Okay, so that kind of seems to suggest that the purpose of product ops then is to improve how we do product work. Is that right, yeah. Can you unpack that a little more for me?

  - So I think it's like to do find a way to do it better and also to do it in a more similar way and not in terms of streamlined that everybody does the same but if, and now with AI coming into products operations, we're seeing this more and more. If one person figures out hey this is how I've used very basic, this ChatGPT prompt has made my feature page so much more accessible for the development team, how can we make sure that this learning does not stay with this one person! But actually also reaches everybody else? And that you then have incremental learning by people actually trying out different things. Like that's from how can we do one-person learning and scale them and then from the other side, okay maybe our, the data we are looking at does not have the quality that we need to make actually informed decisions. Who's going to spearhead that? Getting even a bit like getting a new data tool or getting everybody trained on the data tool that you already have or asking the right questions of the data tool. Like it's these kind of things that everybody knows they should be done but nobody's really responsible and whoever points it out knows that they will be responsible. So nobody really wants to point it out because it means adopting more work on top of what you're already doing. So that's where we can come in and actually kind of can help to structure this both the research and so in terms of what we need but also the how do we then implement it.

  - You you're reminding me that I need to take that system prompt I developed for Claude for helping to put, pull together the initiative that I did it within my first couple of weeks to fit the format that the team has and maybe share it in the broader team because it allowed me to do it very quickly and efficiently.

  - And then also do a blog post about it. Well that's when no one will ever agree to find it. Do a public one, like make it, anonymize it a little bit and then like give it to the world to use it.

  - So if we're there, we're improving it. And you've already, obviously we've already hinted at the fact that you've changed the name here. How is it set up differently or in fact how is product operations set up in your org in your team and how have you seen it different?

  - I think product operations at the end of the day is different in every single company. Like whenever I talk to another product ops person, we are both like, "Oh this is interesting, this is also way how you can approach it." And I think it mostly comes with what was the initial reason why the position was created. In my case it was definitely the okay we have people in different places and we don't quite know how we can make them work together better so it's kind of the remote aspect that came in which isn't, ZF is not remote, it's actually just okay this is a distributed company, how can we make the work distributed and still work? And so on my team, I have one person who's basically programme manager looking at the incoming information like working with the commercial teams, with sales teams, with customer success to make sure that the insights that we get from the market actually read the correct product managers or actually reach anyone for that matter. And then I have somebody who works with the engineering teams making sure that their needs coming like towards product are met that they get the information they need that they're the feedback loop is actually working so basically looking into both direction and then bringing it together with the product managers. And then I have a specific person who works, who does the same but specifically with the marketing and the go-to market team. So it's like really a bridge function, how can we bridge the gap and also translate because engineers, they have a, they did they speak a different language to product people and speak a completely different language compared to commercial people. So like sometimes you need somebody to like translate commercial into product into engineering so that they actually talk about the same thing.

  - See that's such a weird thought process there to me because that translation is fundamentally the heart of product work to me. Like if I can't speak all those, all the like, I expect to be in conversations with all those different teams, like, on a daily basis.

  - But it's one thing to be in conversations and another thing to be in meetings, and in meetings if you and me are talking and I see that you con, are confused, I can kind of refine, I can give more examples, I can kind of make sure that we are on the same level. But as you scale at some point you reach a point where you, there is no more time for more meetings in your calendar so you have to go as they say, async, like you have to go into the written word whether you want it or not. And that's when the translation problems happen because product can translate into both directions but the other parts not necessarily. True very true oh yeah, I, what I found is increasingly product people don't translate like they've got into their own language, their own domain. But I think, you know, I'm an old school product guy from too many years ago and that was always a core part of what I did. Like I having done sales, having done marketing, having done development, it's like that's also where I've built that craft of speaking their languages. And I have noticed with the growth of product management in particular over the last 15, 10 to 15 years, it's become a thing in its own right with its own language and more insular, less engaging with other.

  - Definitely. And also, like, if we look at, like, Scaler our platform specifically, we have a lot of, because we are rebuilding, improving, like, there was a a software and we are building this new platform but obviously a lot of pain points that the old platform solved and now also need to be solved in the new platform but it's a new programming manage language, it's a new, like, the entire, safety, privacy et cetera everything is revamped like everything is new on that side so we hired a lot of new engineers and developers who have the skills that we need to build this new platform. But obviously the product people, they, because we need them because they have the deep market knowledge because they have a lot of experience. So a lot of them have actually been with the company for a long, long time because we really, really appreciate this deep knowledge of what our customers need, where they're coming from what the old software used to be to do so they are not just kind of stuck in product but they have known the old product for so long that they have forgotten what it is like to be somebody new. And so you get an engineer who probably never has worked in transportation but who knows whatever language they need to use really, really well. And then there is a disconnect, and it's not because, like, it's not bad intentions, or trying to not be crystal clear to somebody as is just different languages and then add on top that they literally not all speak English as their first language. Like there are several levels where you can actually get the translation completely wrong.

  - Yeah I mean I do, I've spent a lot of time in Germany over the years and yeah there are definitely cultural differences and even just simple things, like, I do, I always love a German email when it says I need this until, and it's a bad native speaking lang, translation. It's like I need it by is the actual, is the, what a native speak would say. So you can always tell it comes from a German and at first when I came across those sorts of emails, it felt really aggressive, demanding, giving a a date! Until I realised actually no it's empowering, it's telling me when it's needed, not when to do it, and those kind of cultural differences, as a Brit, if there's no date we just assume it it's needed right now and that kind of cultural shift 'cause of the different expectations, like, the timeline is expected

  - And also fluency. Like, when in doubt I tend to think okay, maybe this person just doesn't speak as well English as well as other people. So like maybe they don't know, they just say, "Can like please do this?" Because they don't know how to say, "Would it be possible for you to maybe like to like put all of these nice," specifically the British are really good in that like they're nice buffer words in it. So like kind of always add a little sprinkle of kindness yourself while you're reading it because they probably didn't mean it like that direct.

  - I mean and I'm a fairly direct Brit compared to most so I even even I come across aggressive to many Brits so it's quite amusing.

  - I have to say the culture map is one of the best books that anyone in leadership or anyone actually who works in intercultural com like yeah I think you have it I also have it one of the most like marked books that I have. It's so helpful.

  - If I remember writing an assignment about that sort of thing in my, during my MBA like I think it was lost in translation or something like that I wrote like how even American English versus British English and the differences sometimes the same two words that are closely related transpose almost in their meetings, it's quite interesting when you really spend time trying to understand it and I guess that all comes back to that broader kinda team and cultural environment that we're trying to build excellence in.

  - Yeah, and I like, it's one of the reasons why I like templates so much because it helps people from different backgrounds to structure their thinking and their results in a way that is then legible for everybody else. Like if we look in the culture map there are some cultures who like they need to understand the background first! Like unless you have calculated pi yourself, you do not believe that this is what you use to calculate the radius. And then there are other cultures who are like, "Okay I guess this is what it is and I'll use it like more pragmatic approach." So if you have like a kind of a template where you can bridge this, okay, explain me why you want to do this but also how would you apply this? You kind of can shortcut a lot of the conversations that otherwise just go in circles.

  - I'm generally a big fan of templates as well. If for another reason then it gets past the blank page. Like it's often much easier to fill one section than start with an empty page and figure out what is it I need to do here. But then sometimes, and this is one of the things that's leveraged as a criticism often against product operations, it gets hit with the deady, dreaded P word of process.

  - I mean I have a process even to stack the dishwasher.

  - I think it's John Kotter who said a few years ago, "Your process exists whether you acknowledge it or codify it's there, it's how you get things done." So it's better to actually give you some conscious thought.

  - Yeah, it's a bit like if you want to think outside the box you need a box first. So I create the box and then if anybody has a good reason to do it differently, that is totally fine but they better have a good reason! And maybe the reason is so good that we then change the process because it's not, I'm, we are not putting it into stone at the end of the day it's a suggestion because I mean any process you create doesn't survive the impact with reality because that's just how it works. And then you learn and you adjust and I think often we forget the learn and adjust part because creating something new is kind of more exciting than actually review and redo something that you have already checked as done in your like to-do list but then again that's agile like review, see what works, see what doesn't work and iterate and go back and do it again.

  - I do love how as a German you just quoted von Moltke the Elder as well or paraphrasing him. But yeah, I mean and so it's interesting and kind of, I mean, I think it was my first, one of my first product management leader bosses, he said to many years ago, "Good process shouldn't get in the way of good work, or good business." And to me that's always stuck with me as a fundamental foundation of how we do our work. Yes there is a process but if there's a good reason to go to do something different we should because if it's, it's about doing the right things, not about-

  - But it's the good reason because a lot of people who hate process just hate process because it's process and if you don't have any process that doesn't mean automatically you get good work done, very often you just get crap work done.

  - And so okay we're creating that frame, we're creating that frame or that box through products operations, what, so put a put a bit more sort of flesh on the bone for me here. What are the key responsibilities of product operations?

  - Awareness building, there's a lot of kind of coaching not in terms of personal, I'm helping you with your career coaching, that for me is something that the direct manager is responsible for but definitely for specific skill coaching, skills that I used for this job in this situation right now. And I think it very much depends on the company that you're working with and the homogeneity or lack of that of the product managers that you're kind of responsible for from the sidelines. Because if you are in a startup for example, at the end of the day most profiles tend to be fairly similar on the younger side experience in SaaS, probably white and male most of the time, so it's kind of easier to manage that because you don't have many different profiles there. If you go into a multinational company and then you have like this little software bit on the side and then we have somebody who was hired a year ago and somebody who was hired 20 years ago, definitely not the same experience with modern software theories. And it's an interest, it's an interesting challenge because I, my background is a startup and then like this is, it's very interesting because it's very different and I had to relearn asking myself is this an assumption or is this actually fact because I assumed so many things. Just because somebody is a product manager doesn't mean that they are the type of product manager that I might envision when I think product manager. So like doing this initial okay so what is your ex, what is your hands-on experience with the product that you're managing? Like are you actually managing a product or just a part of the product? Like understanding this world took a good part of like the first six to maybe even 12 month and still like I have a reminder in my computer that comes up from time to time. Which assumptions are you running on that actually need to be verified?

  - And so I mean you're clearly identifying a key relationship there of product management and product operations working together.

  - Yeah, product management is the product of product operations. So you can use exactly the same methods that you would in product management but then you use the product manage like do product managers are kind of your customers and then the product management practise is what you're trying to improve and to deliver.

  - And so do you find that there's ever any sort of friction or overlap there between like the product operations people and the product managers essentially being, sounds like almost being told how to do their work?

  - So I have gotten a lot of pushback because we are essentially asking people to write stuff down. But that is because historically how things were done was through meetings and because the legacy software came in through an acquisition obviously that part of the company was a lot smaller and they were all in the same location. So it was actually feasible to just have meetings and do things. But now we have developers in Ireland, we have developers in India, like it's, even the time zones don't overlap so we cannot do meetings all the time. And I know that a lot of our Indian colleagues, they go to meetings even though for them it's like 8:00 PM 9:00 PM and that's something that I don't want, like no one should be in a meeting at 9:00 PM just because they are in the wrong time zone, wrong in terms of where the current action actually is from product management. So it's kind of, they need to learn how to write things down and we are experimenting with a lot of like how can, how can we create prompts that help them fill in the feature page so that they just have to read and kind of review and don't have to come up with the words themselves because I also understand that not everybody enjoys writing or is naturally good at writing. Writing gets better through writing. It's definitely a learnable skill but it also not necessarily a skill that everybody wants to learn because maybe only for that it's not good enough so how can we actually help them to put their thoughts on paper, well on Confluence, so that it can then be used by other people without having a meeting with 25 people, like this whole, we can do the meeting remote, the meeting room does not have any capacity problems so we are going to invite 35 people and like it drives me crazy because if you are in an office, you would not invite 35 people to a random status update meeting.

  - The way I found to sometimes help with that is do a quick calculation of what that meeting just cost. I did that way before we had video meetings. Like I remember sitting there and thinking we just spent close to 10 grand on that meeting.

  - And the outcome was that we need another meeting to actually make a decision great.

  - Very, very interesting, yeah, and I've seen some similar things in terms of sometimes the only place I can get action right now is in a meetings like I've sent a bunch of things asynchronously, it's like, so you can think about it in your own time and I'm now sitting there twiddling my thumbs it's like hmm, is anyone actually going to respond to these?

  - I have booked meetings into calendars of people so they can think about the questions that I ask them, putting into the invite, I'm not going to show up at the end of this hour, please just send me an email with your thoughts. That works surprisingly well because people usually underestimate that in order to think you actually need time in-between meetings, like you cannot think and be in the meeting at the same time. So like sometimes you have to kind of help people because if I book the meeting into their calendar I know that no one else going to book over it. So I'm kind of giving them the excuse to actually be there half an hour or whatever and think about this and then answer back to me. So sometimes I mean they could probably block it in their own calendar as well but not everybody feels like they can do that.

  - So we've got these, we we've got product tops, they're working with product managers. You've mentioned a programme manager in there, you mentioned someone who's working with development. You've mentioned someone who's working with go to market, what makes, what sort of background makes a good product ops person?

  - I believe you should have worked in product in some kind of capacity so that you actually understand what you're trying to optimise. And most product ops that I know actually do have a product background like either product manager or head of, my previous position was head of product at our startup and I optimised the heck out of everything there as well. So it kind of, it's something that I like, I solve problems, and then customer support, no, customer success, I've also seen some people transition into the product part and usually because they are so frustrated with product not doing what customer success wants that they feel like they can do it better. And then once you're inside you're, "Oh holy shit there was a reason why not everything was as fast as I wanted it to be," but it's kind of it, I think it's a very interesting role because you can shape it very much into what you want it to be. So it's kind of a combination between what are the skills that you're bringing to the table and I think analytical skills, being able to succinctly explain what the problem is and also helping other, kind of helping other people to grow, this is, it's independent of whether you are like a product person or an engineer or whatever. Like you can learn these skills and once you have them then you can apply them anywhere. And then it depends like what does the company need and how can you match your skills with that. And I say my background is product but like I studied political science. No it's basically seeing big frameworks, connecting the dots and then making the best decision and reviewing what is actually, do I assume people are bad or good and it changes from day to day but like it kind of this questioning your own assumptions. That is something that you learn in a lot of philosophical careers. So I don't go into the interview with that background but it really helps to have like a more of a bigger background.

  - Interesting, oh, that's an interesting background, yes, 'cause I mean, 'cause I came through that engineering route into products having had a managing director who was a product manager back in the eighties who kind of brought product ways of thinking just throughout our company and then we were acquired and someone from the senior leadership team needed to become the first product manager, that was me, and then found my very much my home and I've tried to stay in the product space ever since then with a few deviations into some sales and some marketing and this sort of thing. But I've always considered that cross training quite useful because of the ability to speak the other languages and understand and empathise essentially what I want to do with my customers. I built an element of with all the different functions at earlier points in my career.

  - Yeah and I think it's like this also kind of teaches you to think about what is in for the other person. Why would the other person want to change? Because I know why I want them to change but unless there's like a really good motivation for them to also change, it's a really hard sell.

  - So let's switch gears a little bit. What do you consider to be best or sometimes that's a loaded term, good practise when it comes to product operations?

  - Visibility and accountability. And that is I think good practise for product managers just as well as for product operations but product operations because it's not quite clear what that actually is because it's a relatively new function. It's kind of showing what we are doing and kind of showing what we are learning because a lot of product operations is kind of trying things out and then they don't work and then you try something different until you find something that works. But kind of showing the things that don't work I think is just as important as showing the things that do work or showing the things that only work for specific people and that is fine too but kind of showing this entire mosaic basically of different options that there are because otherwise it's like especially if you're in a remote setting it's like what are they doing the entire day?

  - I mean I think the same is true for product management as you say, we try a lot of, we have come up with a lot of hypotheses we run a lot of experiments or do a lot of discovery and a bunch of it leads to nothing or it leads learning that it's the wrong thing to do and a lot of people just kind of put that in a box and hide it away and then the question, the comments come that "Oh you're really slow," "You're doing all this discovery," "You're not delivering anything." It's like "Well actually what we did is we delivered this learning that enabled us to, that's the wrong thing to do, we should do something different."

  - And it's very important because if you don't visualise the things that didn't work you're going to do the same discovery next year all over again to come to exactly the same outcome because no one knew that you had already gone down that rabbit hole, and the other way around maybe five years from that from now you're like "Okay when we looked at this in 2020 it did not work but now there's new technology like the market has changed, there's no terrorists from the US, so like how maybe we have to unpack this again and look at it like from this different angle," but you can only do that if you know what you looked at back then, which obviously also means document your decisions.

  - It's an unpopular one with engineers, product. I mean nobody really likes to write things down but, yes.

  - And then oh but they always go with, "Yeah can we just record this meeting?" I don't know how much time have for people have to actually watch recordings. It's kind of, it's really nice that you're now giving me, I'm coming back from vacation and I have now access to 25 meetings that were recorded, just give me a summary.

  - I mean the recording and then a bit of nice sprinkling a little bit of AI to get a good summary can be an an efficiency saver.

  - But I mean that has been, that was invented like I don't know a year ago or something. It's not something that was widely available and it's getting better, still, somebody has to check the summary of the recording specifically if you had non-native speakers on that call because otherwise accidentally you are and I don't know a lot of people who actually check the AI summary and make sure that it's accurate and you can introduce a lot of wrong like decisions or wrong like data through bad AI.

  - It's very, very true, I mean, I do, prior to joining ZF I was using Fathom mostly, which I found was better than most. I've heard really good about Granola recently as well, but I, instead of using the autogenerated summaries, what I always did was still create my own summary but it has, most of these AI tools nowadays will have a a prompt where you can treat it like you can interrogate the meeting, like you can interrogate the text and Fathom for example would bring also the snippets where it was pulling the data from and then you could go and play the short snippet and that allowed a very quick inspection of what was going on. I've done similar things with taking transcripts and feeding them into GPT and Claude over the years as well 'cause Claude typically I found will hallucinate a lot less than the other platforms.

  - Oh yeah, I agree, I agree.

  - Which is quite useful in that respect. But even still there's misinterpretation and so on.

  - But to be honest, if you can't summarise the meeting you just were in-

  - Depends how long they are. Sometimes they're too long. That's part of the problem.

  - Yeah but then it's really, that is good, a good moment to look at why are we having this meeting? Is there a way that we can shorten it? Is there a way that we can kind of front load some of the prep work? And I know people also hate prep work, but sometimes, very unpopular opinion, they are paying you to write things down and read stuff. It's totally fine if as a manager you expect people to get come prepared to a meeting. Like I don't think that is out of this world.

  - I mean I'm also a fan of turning meetings more into workshops as well. So spinning up a mirror or mural or something like that board to capture a note as you go and that becomes your summary almost as well because you've got a relatively succinct board to work on.

  - Or if you already have an assumption at the very beginning use the first 10 minutes tell everybody "Hey here's a document, get off video when you're done reading, put on your video so that I have like a visual indication of who is done reading and then we can start the conversation."

  - Yeah, I've used that reading in particular with execs I find that that's a useful technique because they just don't have the time to do the pre-read but they are, they want to, they're hungry to have the facts before they have the conversation and so giving them that, you know, Amazon-style kind of memo at the start can work really effectively. So Valentina, what do you think is the biggest mistake people make in terms of setting up or running product operations?

  - Probably doing it too late, which I think is the, is the same with what's the worst mistake when hiring the second product manager? You're doing it too late. And not having clear, like, not, I think it's a great role to find somebody who's kind of an all rounder and who can help shape the role. But I do think that the pain points need to be really, really clear before you hire so that you hire somebody who can actually help with those pain points. For example, right now the roadmap is mostly driven by engineering because they are the ones who have to kind of organise 27,000 people, well 6, 350. But like they have to organise all their teams and because we are in the middle of migrating people from one platform to the other there is not that much of a strategic decision from a product point of view but rather from an engineering what does make sense to build more so if you now get somebody in who's a product is who's a roadmap wizard that might actually not be what you need at that moment. So what's the pain and what do you want to solve because the clearer you can be with that the easier it is to find somebody who matches that.

  - Interesting, oh no, that's actually is a perfect segue to, I mean the channels called "Talking Roadmaps." So I always have to add, what product operations involvement with road mapping.

  - So it's a tool thing to be honest. So how can you make sure that whatever roadmap and whether it's product or engineering or, I mean in some places it's the commercial part of the organisation who basically drives the roadmaps through sales, requests, whatever it is like how can you make sure that it's in one place that it's visible for everybody and that it accessible from different functions so that they actually talk about the same thing. Because as soon as you have like three different versions of the roadmap and I don't mean different levels of detail but like three completely different disconnected things then like things go south really, really quickly. And when I started the company was still on product board but there was kind of a big disconnect between product board and our Jira instance. So engineering, like there was a lot of manual copy, paste, update, et cetera and I know it can be automated like there is a pretty good integration between product board and Jira, but then you also kind of need the right people to do the integration and there was kind of the making it happen threshold was too high so we ended up migrating to Jira Product Discovery which by default is like super integrated with Jira because basically the system product and that was super, super helpful. So we don't do the roadmap but we make sure that everything that is in Jira Product Discovery has the right information attached to it we have created the different views that are needed because obviously the commercial team has different needs in terms of what's happening than the engineering teams and product leads have different needs than commercial. So we kind of make sure that everything is in one place and accessible to the level of detail the different people need it. Everybody's complaining, nonetheless, but that's just, that, whenever there's a roadmap people will be complaining, that's just a fact of life that I've come to accept.

  - If they're not complaining you're probably not doing it right because if you're, because you are giving everyone what they want, which means you'll never deliver it.

  - Correct, that is very true. You've gotta make some hard choices, they're gonna be people who aren't happy.

  - And estimates are wrong always anyways, always add at least a quarter.

  - I mean we could get into a philosophical debate of whether they should have timing on a roadmap. I think in some context you should and in some you shouldn't. I'm currently working out what the road mapping philosophy should be for the team I'm in.

  - It's a very difficult thing because specifically, like, there are some sales, like, if, as a salesperson you are selling the tool that exists right now you don't care about estimates because you are selling what is there. And then if there's another great thing coming around the corner, cool, like you have an upgrade or whatever upsell option three, six months from upgrade. But if you are selling the future then it's a problem because you kind of have to say when the future is going to be delivered because otherwise your potential customer won't buy the future. So I think whether you need estimates or not depends, unfortunately, on the sales strategies, which is something that as a product manager, or a product you have zero influence over, unless you want to go into sales enablement and like reteach people on the sales side how to sell.

  - Oh yeah, I don't think I'd agree with zero, zero power, but I think it's a hard fight in some organisations.

  - And so then the question is okay, like we are selling the future. I mean in our case we are migrating people so obviously the people who are on the old platform expect a certain level of feature service on the new platform and not all of them may be ready right now. So obviously the salespeople have to sell the future but then it's very different if you can tell the customer "Hey, this will be ready in Q3 or in Q3 2030."

  - It's a constant balance of trying to give that confidence to buy and even if you're, I've generally found if you are talking about something that's a month down the line or three months or six months down the line, it's still a great excuse for people to not buy they can have today. And so some, sometimes actually putting a timing goes against you even still, you need to know the audience, ultimately that's what it comes to is your road roadmapping of your audience. So we're gonna start kind of bringing ourselves to a close I think Valentina, always like to ask kind of three-ish last questions. Whose advice on product operations do you listen to?

  - I am really, really, really bad with names, but Melissa Perry is, oh, I mean, I discovered product operations through her book. So she has definitely had, like, an impressive, like, she has left an impression on me and I very much go back to that book whenever I'm kind of lost basically to find like new ideas and see how else could I look at this. And so like her podcast is also one of the few that I actually, relatively regularly, listen to and then whenever her name pops up I'm like, "Oh there's interesting." So, fan girl for Melissa Perry.

  - Well Melissa and Denise are both also guests on this series season.

  - No I'm really looking forward to that episode. The other person who has actually been quite interesting to me is Petra Wille.

  - Yeah know Petra well she was in the first season.

  - Oh yeah okay, so because, and I mean she's not product operations but I really, really like her very humanistic style and like you can learn a lot about product operations and how to kind of support people not just on a human level but also on a process level. Bad bad word! From her teachings or from her book. So those two are probably my favourites.

  - And in fact I'm actually meaning to read the next book, the product commun operation, the products communities book that she co-wrote because I think that could be an interesting one for us internally. I always like to ask people towards the end, if they had to distil their philosophy on product operations down to one or two sentences, what would it be?

  - We solve problems. If you're stuck, we're going to find a way to unstuck you, you being the product manager.

  - I love how succinct and how direct that is. We've talked about a lot of things and we've gone down some interesting rabbit holes. Is there anything I should have asked you about product operations that I haven't?

  - Something, and I don't even know if that is a really a question, but something that I am thinking a lot about lately is how much the buy-in from product managers, because it's usually not the product managers who request somebody for product operations to come in, but it's basically usually it's leadership or it's the head of product who needs like somebody who helps them out but then that person ends up actually working more with the product managers than with that leader or impacts the work of the product manager in almost a disproportionate way. And like one of the questions, and I don't have a good answer about this, like, how do you get people to row into the same direction if they didn't, like, if you were suddenly in that, like, you suddenly, you're there and now you're like "Okay we all have to row in this rhythm" and everybody's like "Well I've never rowed in this rhythm, oh I thought we have a motor, isn't this a sailboat?" Like how do you actually streamline all of this? And I'm still in the, like, I don't have a definite answer for that but I think it's an interesting, it's an interesting question to ask, like, different people, like, "How do you influence more than direct?"

  - Yeah, I mean it's the classic kind of change management problem I guess 'cause change managers are brought in when something to be changed and actually the people who are, that look to be changed often feel like they're being criticised and the product managers in this case maybe look to feel like they're being criticised 'cause they're not doing it quite so well or quite in the way that has been asked for and therefore could create that rear guard action that kind of fight against the change.

  - Yeah and also like with, like, this whole analysis, like, one of the things for example that I love to do is sitting down with a product manager and go through their calendar to see where their time goes but getting the balance right between I am here to help you figure out how we can save time, like I don't want to rationalise you away, I just want to get rid of three meetings for you so that you can actually talk to more customers. But like this fear that somebody is coming in because, and then I'm lose my, I'm going to lose my job and I'm going to be under the bridge and then I die. Like that's kind of where the human brain goes to directly, like that is an interesting balancing act.

  - Yeah, it's an interesting challenge, very human one.

  - But that is the challenge for the future. How can we put more humanity in work given that everything is becoming AI, I think the human touch will be kind of the differentiator in the future.

  - I agree, and so it sounds like product ops you see as an enabler for that.

  - And I wish I had the budget to get everybody together at least once a year on site to like work on some challenges together, role playing customer interviews, like things that you can do in person. So having dinner with wine together to kind of create this personal connect connection that can then take you over the next six months. And I think it's a very underutilised and not very expensive way to actually create motivation and create collaboration and create kind of this companionship that you don't necessarily have if you're not in the same office.

  - Yeah, it's an often overlooked part of remote patterns or one of the things I talked about when COVID hit was how one of the things that enabled people to go remote so quickly was because existing relationships were frozen in place that had been built in person. Like one of my classic onboarding techniques in my previous life was to take someone on a mini tour of the entire business, the entire team and introduce them personally, one-on-one, to each individual and tell them a little bit about each other to you know, boot up that relationship quickly 'cause it was so much easier to work together after that point.

  - Yep, and every single fully remote company that is successful has regular meetups and that's something that is often overlooked. Remote does not mean you are never, ever allowed to see any human being ever again. It means okay we are going to meet in these contained boxes for a week every four to six months because then you have enough kind of human connection, human bonding that you can survive next months because you know who's sarcastic, you know who has a dry humour, who knows who's like always has anxiety through the roof and needs a little bit more calm down, because you've like lived with them for four days in an Airbnb or whatever or in hotel. But if you never meet it's very easy to conflate the avatar with the enemy because you kind of forget that it's actually also a human being with a pet and 15 plants that likes white wine, no pet here, but yes to the white wine.

  - Valentina, it's been absolutely wonderful chatting today. Probably time for us to wrap up for the day. Been absolutely wonderful having you here. As I say, thank you again for your time.

  - You're very welcome, it was fun, I love talking to you.