When should you introduce a productops team? | Paulo Garcia

In Episode 11 of Talking Roadmaps, Justin Woods speaks with Paulo Garcia about the evolving role of product operations. Paulo shares practical insights on when to introduce a product ops team, how it enables entire organizations—not just product managers—and best practices like scanning the room, building allies, and balancing tooling with human connection. A must-watch for teams considering formalizing product ops.

With over 10 years of experience in product-related areas, I am a product leader who is passionate about building user-focused products that solve real-world problems. I have a background in product operations, product management, UX design, and software engineering, which gives me a holistic perspective on how to drive product vision and execution in cross-functional teams.

Currently, I am a Principal of Product Management and Operations at Twinkl, where I am overseeing the ecosystem of Educator products and end-to-end product portfolio cohesion. I'm responsible for the conception of a learner management system and a handful of newly born products. Part of my time there is also focused on helping the product teams and the company grow their product mindset and operations: this includes product practices, product evangelism, and helping the company pivot into a product mindset.

Besides my role at Twinkl, I am also an author, mentor, speaker, and teacher, sharing my insights and expertise on product-related topics and career management through various channels, such as my Substack, the Product-Led Alliance, and ADPList. I enjoy writing, teaching, and mentoring others who are interested in learning more about product operations and product leadership. I am always eager to connect and discuss how I can contribute to your team and help you achieve your product goals.

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

When should you introduce a productops team? | Paulo Garcia

Paulo Garcia and Justin Woods

In the next episode is a big one we are talking to Melissa Perri, Product Management and Operations Expert. So watch out for Season 2 - Episode 12!

• Transcript

  - Just to harness that power. But then again, as a best practise, choose to humanise us as I mentioned earlier, choose empathy, choose through strategic thinking, choose relationship building.

  - Welcome, everybody, to Series Two of "The Talking Roadmaps Show" where we're talking into product operations. Today, I'm joined by Paulo. Paulo, it's great to have you here. Would you please introduce yourself?

  - It's really good to be here. I'm Paulo. I'm 33 years old, born and raised in Lisbon, Portugal. I'm a principal of product management, at tiniest bit of operations as well. I work at Twinkl, and my whole career has been pretty much squiggling around from software engineering to product UX and UI design and then product management.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Amazing. And I think all of those different experiences in your career have kind of come together to make you who you are today and kind of be the best of product operations and product there, which is great. I wonder if we maybe go straight in and dive in at the deep end of what is the purpose of product operations? 'Cause some people may not have even heard about it. So from your perspective, what is product operations?

  - Operations might mean different things depending on where look is within the industry. In operation, I'm sure that if you would be interviewing someone else in my place, they would have at least so boxes in the kind of this, the commonality across pillars, across foundational areas. But then I think that product operations becomes really different depending on the context that we operate in, maybe that we operate in tools that we need to solve or help facilitate. So in my sense and my view of product operations, it is pretty much about enablement and ensuring that no matter the product individual or the product stakeholder and whomever sits around the product organisation, we enable everyone inside out. So anyone that takes about a certain specific product problem that should be solved, the inside or feedback that we should be responding to. So also, for example, any kind of product discipline that naturally lives and breeds products such as product designers, product managers, UX researchers, data analytics, engineering, anyone we need the product organisation will benefit from having a product operations individual, a team, an organisation, that will be sitting in the intersection of everyone around this product organisation as I was saying. And pretty much remove roadblocks. Also operational support, perform the heavy lift that possibly some other product individuals cannot afford the time or the effort to do because of everything else that is happening around them and within their day-to-day tasks. We'll then pretty much have lift that one for them and help the product management start and skillset and work to scale well and accordingly to whatever the company needs, whatever the product organisation needs as well. But also fulfilling the expectations that customers have. The adding on the company that you operate in, I think that the kind of insights that you will be consuming will change naturally. The kind of strategies or processes that you need to put in place might be different because we as well may not be able to compare, for example, a company that is transforming into a product mindset versus a company that has been born with the product mindset at the core. So that's why I said that ultimately it's a backbone of action, product organisations, and making sure that insights and frameworks and operational excellence are there. But then I think the last mile of it and the implementation of a product operations function will change and a purpose will change from organisation to organisation.

  - Such a great response. I think two of the things I took away from there was that product operations is not just to take some of the heavy lifting for the product managers. That's the important thing, right? It's a product operations for the entire company, it is to help all of those. And because product is the entire company as well. People that think product is just product management. It's not. We all work together for product and product operations is there for all of those functions. The other thing is that a lot of companies are going through a transition. Some of them are becoming more product led, some of them are becoming more empowered teams. And you see product operations very much being an ally to product management and the rest of the company to help everyone go on that journey. I'm seeing a big need for, it's more of the product management thinking that needs to happen. And so product operations can really be there to champion that and help the entire organisation think more about product. The more I think about that, the more I think that it's even more of a vital role than it is already.

  - When it comes to a company choosing to adopt product operations versus realising that product operations is already breathing in within the organisation, that makes things still where things start to get tricky because don't need to have it as a function if they don't really need it. And if we choose to adopt product operations at the wrong time or if you don't have the product maturity for it, it'll be like extra headcount and extra people adding to the mix, which if you are not choosing the right people to be there on those conversations, naturally you're just adding to the mess and naturally that's not up to the best intent of the product team. But then assuming that you know the needs product operations to be, there's then two angles of it. The angles, the first angle will be that takes product companies in its absence, because product operations is a core set of traits that product individuals, they cherish, they should practise, but mostly they cannot cope with everything that they have to do. Plus securing that operationalizing product needs to be done, that's when product operations might come in. But then when the second angle, which is companies that know that they need a facilitating function because of everything that I've said and they feel that they are ready to adopt product operations in that's when product operations can really make a difference because there's space for this function and this team, it's given space and authority to influence processes and to sit there side by side with product managers. And things around the industry, there's always naturally, some conversations around like the overlaps in between product management, possible friction that you have. But really I think where we can draw the line in between product management and product operations is that while product managers will continue to focus on the strategy and delivering the best possible product that they can, not be focusing on the administrative tasks or the process firefighting that product operations can be there to alleviate. Rather than seeing this as an overlap or friction, I would say that as long as you can draw this clear line between the functions, you should be good to carry on.

  - I like that. 'Cause actually, you've naturally answered one of the questions there, which is what is the natural collaboration between product ops and product management and can there be frictional overlap? And I think what it is is about sometimes just making it more distinct, the two roles. I'm a tooling implementer. And so when I work with companies, I'm often working with product managers where they don't have a product operations team. And that extra loading on them from having to implement tools and processes, you can see it on their faces, you know. There's a big weight on their shoulders while they're doing that. So having that clearer differentiation between product management and product operations certainly makes sense. And to your point, to some extent, we're already, some companies are already doing product operations, even if it's not explicit by a function.

  - Yes, by all means. If companies that's a product, they naturally have product operations one way or the other within their just two individuals. It's just that when they choose to complement with the product operations function or team, we are sitting side by side the product operations individual and the product manager individual and both they coexist and coordinate their ideas and their functions together. But when product managers and product operations people coexist and it kind of, they will share the same kind of core trait and the same kind of skill sets, there will be naturally tonnes of overlap in terms of concepts and product mindsets and I think those overlaps, they naturally become trickier to tackle when the rules aren't cleared defined. That's when I think that the friction starts to come in because as a product operations individual, you're naturally to the product mix, you contribute to the strategy, you are trying to see things from the outside in. But individual product managers individually, they are seeing things from the product roadmap and the product strategy, and the kind of insights that they want to go after from the inside out. The friction comes when those overlaps and those roles are not clearly defined. And I think that's as long as you are able to draw those lines and have clear competence profiles and knowing what each of the product individuals and I think this is not just applicable to product operations, I think it's product managers, product operations, designers, engineers, as long as everyone knows what is the kind of expectation that they are that to contribute with but also that they are empowered to do so, I think the strongest collaboration will then ensure that the product manager will continue to own the what while product operations will own the how, ensure that whenever we want to tackle the why, product operations will facilitate the why in such a way that the product manager can understand it. I think that when it comes to any kind of friction that these two individuals might find, I think it's really up to you and your peer to decide and own it and choose to see them as partners and really not a product opponent, because product operations is really not there to do that.

  - Yeah, that's so true. I love that thing you just mentioned, the term you mentioned, a product opponent. I think that's absolutely important here is we do product operations, whether it's explicit or implicit. And I think when it becomes separate roles, just to have that open dialogue about how things are working and just test and learn how we go there.

  - Your own product operations if you choose to see it, right, and if you choose to pick under the hood, you will see that product operations most of the time it's really about counselling and also allowing some safe space for venting with product managers and product individuals. And most of the time, you'll also end up being federalizing your product members as well. So more than the processes and the KPIs and choosing the right whys and et cetera, product operations, they are really like, the best possible humane individual that a product individual could have around because they empathise with your cause, they have been in some way, shape or form before a product individual, they have contributed with product work, they understand the discipline. So that's why I mentioned that it is not about opponent each other, it's really about cherishing it and enabling us to.

  - That's a nice perspective and a nice response to that. And I know, you know, you yourself, you've had a rich career in product management as well and now you're kind of doing product management, product operations. You've got that appreciation from both sides there, which I think is valuable. Paulo, I'm curious how you may have seen product operations set up across different organisations. So is it always a separate team? What reporting lines have you seen work well or have you heard of? I'm curious to see your perspectives.

  - What I've said earlier, because product operations changes so much or can change so much from company to company and knowing that the product org will then change to be adapted as a constellation to the kind of business org that's following then product operations naturally, as a discipline of product, will follow the product team, organisation or constellation. Where you look at, not only because of those problems and those complexities that each company might have, you'll see naturally different constellations of product ops. In my own case, in the past, I've been part of a team of several team members where all of us, we had really different experiences and backgrounds. I was the only one coming from a combination of an engineering background, plus product management, plus all of the other different disciplines. The other team members, they all come from product design, which was an amazing combination, because we found a way to complement us so greatly. I mean, naturally the entire product organisation around us benefited from it or due to some, yeah, company constraints, one thing before a team of several team members that I was part of became a team of one, which was only myself. Doing a team of one versus doing a team of several, I think it naturally imposed some constraints to what was common across those two contexts was that an operations team belonged to or was reporting into a product org. So we were reporting into making a senior head of product, which was then reporting into a VP of product. There was some some challenges back then because one of the anti-patterns that I would be seeing there is that by making product operations sitting too far away from any kind of product decision core area, it makes us or reduces our realm of action or our ability to give back to the team because it kind of be jumping on to reaction modes too much other than proactivity. The roadmap from other companies around the industry as well, there is cases where I've seen, because a company might have different product organisations within the same companies, so more than one, every team might have, every product team might have a dedicated product operations team. And that same thing happened with us at Farfetch back then. So each product organisation had their own product operations team and then we found ways to collaborate across the board, end to end across all product operations. Because as a discipline, even if we would be solving different problems within each of our organisations, we share the same discipline, we share the same bias. It was good for even us to vent with each other, not just accommodate venting from product managers to us, it was good to if others would share same perspectives within the organisation. But then just to close up that one, some other product orgs this they get, because the other companies will have different complexities as well. I've seen as well some multiple of product operations organisations up to it be team level. So every product team squad you should be in constellation or product to you was also made of a product operations side by side with the engineer, the designer and the product manager, plug and pull. I think the sizing and the setup will then, or at least should be informed by and some of the problems that you'll be solving.

  - It's great that you actually, within that scenario, you just described the different product operations people still came together and formed a virtual team to share learnings, even though organizationally they weren't the same team. I think that's a really special setup and shows just how collaborative product ops can be.

  - Also really important for us because the organisation was really wide and naturally by coordinating end to end across the different products organisations using the product operations function. It was really good not only for us to absorb information that was important across the board, across other product organisations, and possible some key decision points that we needed to inform our own product organisation, but it was also very good for us to then broadcast as well things that would become a priority for us. But also if someone else within the organisation had tackled the same kind of problem that we were going after with a process or change to ways of working their own, also really good to know that someone else tried to solve the same problem and then repurpose their own work onto the same context that we were trying. And I think the key advantage there is that rather than looking elsewhere within the industry into one that tried to solve that problem, but because the context or the problem was already the business was not precisely the same or even the product maturity wasn't the same, having peers that we could relate to within the product organisation was really, really good for us.

  - That makes sense, and I think really important to learn from each other. I wonder if you can share with me what you think some of the key responsibilities of product ops are.

  - Everything that I've tried to exercise as an idea that product ops becomes really flexible depending on context and whatnot. I would say that's the first key responsibility that I would see as a product operations team is to observe and get to know your context, and knowing how to scan the room. That first step will inform what is the kind of maturity that you have on your product individuals, the kind of problems that you should be solving, the kind of processes that you should be having in place, for example, inform what will be your course of action in the future. So number one would be definitely observing and reading the room, and understanding what will be the game rules that you should be setting for yourself as a team, but also as a collective of product. The second step would be them knowing that you have now scanned your context, you are familiar with what will be the problems to solve, what is the kind of structure that you have on a product team. I think it's a time for you to then start asking the right questions. So what does your product context require from you? Use that to inform your practises and where do you set the boundaries of your realm of action? Because depending on where your product team might be at or the product maturity might be at, their immaturity might be at as well, you might find yourself at very different places. Your team might be needing some support of mentoring. For example, if your team require is quite junior on their tenure, and possibly mentoring is something that suits this particular Team A, but not Team B, which is more senior and definitely is not in a stage where all works. So if knowing that you have scanned the room and then you have set the boundaries for your realm of action, whenever stage would be possibly then deploying those practises and work, but with a slight caveat, which is not just deploying for the sake of deploying, not just launching frameworks for the sake of launching, but do that in a way that wins friends, product friends at the same time. So not just make them see the advantage of having someone outside of what, well, the product trio, which is design, product management, engineering, choose to see that having someone which is a product operations individual pitching into a product practise, a product strategy, a product roadmap, how choose to explain your rationale and the reasoning behind it, make them see the advantage in doing so and while you're doing this deployment of practises and showing them the advantage and the value of everything that you are delivering to them, hopefully, you'll start gaining friends and creating rapport, and making sure that at least people will come back to you even if they might not choose to adopt or to pick up on any kind of change from day zero on everything that you do, at least you start building the foundation of a really good and long lasting with other product individuals. And the same thing applies with stakeholders. For instance, in the past, even myself as a product operations individual, even if I wouldn't be the one contributing with a given mode or to a given product strategy in the sense that I am not the one choosing the best possible or the opportunities to go after that's up for these measures. As a product operations individual, I was still quite close to a context where a product manager or a product trio needed to influence stakeholders and win their confidence to what would be the key decisions that a product roadmap should be concerned about and also win them onto our side. And as an individual of product operations there I had like the privilege of sitting in between those two on every important stakeholders, which for me was like external stakeholders and then product internal stakeholders and ensuring that I was able to debunk the two different languages that possibly they would be speaking and kind of mainly important for me to gain trust and gain their confidence, in this case for product managers, and I want them to trust me as a product operations individual, because so I can be called into the context and areas where possibly in the beginning why wouldn't be referred to, but I would be called into areas where enablement would be pretty much needed. And enabling stakeholders and enabling product individuals, I think it's also then again one of the key responsibilities of product operations. So, I think, and the key responsibilities that your product team might be tackling might be really different from company to company because of the context. And I think that even if, for example, and something that we haven't touched, which is like the contribution of artificial intelligence onto this one, even if AI becomes open that product operations can trigger and leverage to analyse trends, automate reporting, optimising decision making, generating documentation, et cetera, doesn't really come to the point where the product operations individual will be there in the room to humanise the relationship in between the product individuals. So I think that ultimately those three stages plus seeing product operations as a humane team that will humanise product development processes, I think it's part of those key pillars outside of like insights that we should be collecting and all of those pillars that as a product individual we might be familiar with.

  - Really enjoyed that response, Paulo. I think the term product friends was lovely and kind of brings everything of what you were saying there together, which is it's a group effort, we are there for each other, we're an enabling function, we're advocating things, product friends is a great way of putting it.

  - So mentioned like all of the most obvious one associated with the actual operationalizing of product from best practises to managing, tooling, Jira roadmaps, all of the tools, owning data, owning insights, exporting insights, making insights human readable and understandable, streamlining collaboration, all of those things will be there. But I think you should treat product operations as, for example, an engineer who would be treating any kind of, I don't know, JavaScript frameworks, as long as you understand and are able to debunk the problem that we're trying to solve, I think you should pick up your processes, frameworks, everything according to the best one yet your judgement of that problem and not try to hammer down like all the solutions and hammer down all the problems just using one tool. So product operations is more than the tools and the frameworks, that's why I've skipped those from the answer. But try to focus more on the most abstract humane side of things.

  - No, I really, I really enjoyed that, 'cause I think we can often think about what operations means from a tool and the frameworks perspective and the processes perspective, but actually maybe missing the humane aspect of it and so that's why I really enjoyed that. So, thank you for sharing that perspective with us. You mentioned about roadmapping. I'm wondering what product operations involvement in roadmapping might look like? And again, I guess, it may depends on the context of the company, but from your experience, what's that look like?

  - I've seen this differently across organisations individual that product operations in my experience has to roadmapping to a contribution that adopts or manages a backlog of initiatives or manages a backlog of priorities for product managers because that's really for product managers to do that. So just from my own experience, we've been always about setting up the right foundations for roadmapping, visuals tooling, the processes, the ins and outs, who should be engaged, what should be the cycle, what will be the best possible framework at a given time that the team would require to prioritise, for example. Then again, picking up on tools versus solutions and understanding your problems as a frame from just looking into like sticking or making the company or making the team sticking to just one tool before is actually solving the problem with something else that would be simpler, free, and that would alleviate the workload that comes naturally. From roadmapping you alleviate that to product managers and product leadership. So for us it was about like establishing what will be the cadence of planning, what should be the cycle of planning and also the key tools that would come in play for those roadmap cycles. I'm sure that the right stakeholders within the product organisation, from UX research into data service design, everyone had the seat at the table at the right time. So rather than tossing everyone into a room, making sure that they all speak roadmaps, they would be all dot voting priorities on a whiteboard, we made sure that the right people would be in the room at the right time, and we would ensure that over the entire planning cycle, we would not only have the right traceability for initiatives that the team would be pursuing, we would also be ensuring that the teams knew how to consume that data, so how could they react to the KPIs that they would need rather than chasing some kind of vanity metrics. We would try to consume real-time data too as real bottlenecks that the team might and would have. So, for example, over committing into product initiatives apart a huge long list of a backlog that would need to be to be dealt with. Those things would be KPIs that we would be collecting through time. And upon a certain cadence we would be then giving back to the product team, the product leadership and we would try to, at every planning cycle, at every roadmapping cycle, we would be optimised for the next possible just to a deal scenario of a roadmapping strategy. So setting up roadmap and the foundations was pretty much what we went out to do rather than just managing a tool. To be honest, we didn't manage the tool, we tweaked it based on what we would need, but we didn't get overly obsessed with the tooling aspect of it. We're definitely owning like the roadmap transparency. We ensure that everyone knew how to and when to when they would need to, of course, data. Where to find the roadmap, how to engage with the product team, how to provide and influence the roadmap of a given quarter and also secure that by those rituals that I've mentioned before, that all of the product stakeholders, they would be aligned and solved, in doing the problems that we would be solving and the plan that the team should be safe and guarded to pursue over a given quarter, over a given year. Now we know that all of this might become either vertical at points because, yeah, businesses are businesses, and you need to react on the fly to things that were yesterday's requirements, but at least product operations will be there to ensure that whatever becomes like a yesterday's requirement and at least doesn't harm the process. And the roadmapping strategy that the team has in play will ensure that there's ways for us to tackle those yesterday requirements and overarching strategic activities that someone has thought about and we will treat this isolatedly and accommodate onto the roadmap in the best way possible. Yes, owning roadmap transparency, aligning stakeholders, ensuring that roadmaps are, the ins of the roadmaps are based on real data not just gut feeling itself. So the roadmaps, the tooling, the KPIs, those are also actionable. The process are repeatable, lower the effort on planning as well. I think that's kind of involvement that I've seen on roadmapping. But then again, another anti-pattern might be product operation all of the sudden is asked to mediate product strategy or asked to take decision making on product strategy. And if I'll be honest, I wouldn't see the contribution of product operations doing that, but rather to enable those decision makers onto the right data.

  - That's very suited response there and I appreciated some of the different elements. As you were talking, I was kind of rounding out my understanding of that in my mind, which yeah, definitely makes sense. I'm curious, you mentioned some anti-patterns there, what do you think are some best practises or some good practises for product operations, especially for people that maybe aren't as experienced as yourself? If someone was thinking, hey, I'm listening to what Paulo's saying. I like it. I think we have a need to maybe at least make product operations more explicit within our organisation. What recommendations would you give them to just kind of set them up with some good practises?

  - Just reading the room, scanning the room, making allies would be like top of the list for me and anyone that does product, but particularly for product operations because it's quite a function that depends on influence and our team behind the curtain scans the room and is really, and can easily navigate in between the low level details and the high level strategies and details as well. I think knowing how to listen and knowing how to make friends is something that it's very important in my opinion, if you choose to enable someone within the product organisation. So best practise as well could be ensuring that tooling and the data infrastructure can around, yeah, depending on product context as well, you can enable individuals rather than hindering them or swamping them as process that then hinder decision making process or framework as such as the roadmapping that we were discussing just now. It has to be repeatable, it has to be scalable enough. Processes should be, you should be able to plug and play, and somehow even if, yeah, last mile would be you would always need to adapt a process or a framework to your own context, to your own team, to your own product individually in front of you. I think you should find ways to create systematic approaches to the work that you do, such as, for example, documentation practises. Make sure that they are repeatable, make sure that they are templatable, make sure that whenever someone chooses to create documentation, which we all know that is better on everyone's plate to focus on any kind of documentation, make sure that at least the efforts and the entry barrier, it's as short as possible. Don't over complicate it. And I think then again, choose to embrace these roles that might be able to optimise not only yourself as a product operations individual, but also choose to adopt those and suggest those to your product individuals. So choose to embrace, for example, artificial intelligence, as I was saying before, as a product individual no matter if I'm a product manager and/or product operations, speaking Paulo here as a person. Then I kind of do accommodate artificial intelligence in my day-to-day tasks because I do understand that it alleviates, even for myself, a lot of the manual work that for me would take ages to do. And to use those tools or team members that also you can use to rubber duck your ideas. AI definitely can be used to rubber duck ideas, but it can also be used to enable workflows, certify any kind of insights and to harness that power. But then again, as a best practise, choose to humanise, as I mentioned earlier, choose to empathy, and through strategic thinking, choose relationship building. And I think that that's one of the best practises that I could see applied to any product individual. On a personal level, some of the best practises that I've been involved in is from documentation practises, confluence, as I mentioned earlier, roadmapping practises, what will be the kind the right prioritisation mechanism if it should be RICE, MoSCoW, what should be the kind of assets that we would be generating with roadmaps, mentoring as well, all of that jazz that constitutes actual product would be ideal for us.

  - That's gold, Paulo. I love that. Yeah, I don't have anything more to add to that. I think that was a really well-rounded response there and I'm seeing how our audience can take some of that and apply it to themselves and to their situations, so thank you. Paulo, you are clearly very experienced in product and obviously within product operations as well. I'm curious whose advice or guidance or resources that you've been able to leverage to help build your knowledge of product operations. What sort of resources or people do you recommend other people might consider?

  - I have some of my own, which I think, if you are product individual within the industry you might have heard of them. But I would like to step back even before I was a product operations individual or a well-versed product manager. I think as a tech individual, I think I've always felt really, or as an engineer, frontend developer, UX and UI designer, I always felt that finding the right people to look after, industry leaders and whatnot, I found it to be not only a task that you would only discover the right people to search or to follow. It could be really into it naturally. And if you are into it, then you'll find ways to find those people. But on the flip side of the coin, it was always very hard for me to deal with the fact that what if I'm not following the right people within the industry? What if I'm not, I cannot cope with or adapt anything that possibly anyone might be saying within the industry that I should be adopting. So when I've jumped onto a product operations role and understood that not only, given the background that I had, having had my own squiggly career, having had multiple experiences as well, finding a place such as a product operations team, which I found a couple of years ago where other team members had their own squiggly careers as well, where I felt that there was a safe space for me to bring in my experiences and bounce ideas around with those profiles as well. Back then, it made like a tremendous effect on how I did see the discipline, product operations, and product as an entire discipline, but also how would I like to shape my influence and give back to the community and the product industry. So yes, I had my own Marty Cagans, Melissa Perry, John Cutler, all of those most, the most well-known members within the industry. But then again, at the same time, I found that some of my closest colleagues back then were really influential for my own development and changing my perspective onto the product community. And I think that as soon as I realised that more than the actual industry leaders, complementing that with people that sit on the vicinity of my own expectations and my own contributions in my team, such as team members directly that do product and product operations, but then complementing and choosing to go out there in my own product community here in Portugal, in this case, but then extending that into Excel communities, being exposed to communities out there like Product Alliance, Product Ops HQ, choosing to go to local meetups, virtual meetups, you start seeing that those not so well-known industry leaders, but they are always there. You start seeing that the community isn't that wide, even if we're speaking a lot about like a worldwide community of product influential members. So my advice would be to, yes, choose to follow the right industry leaders because they can act as North Star of what it means to be a transformed team, what does it mean to apply product operations within your own context, but choose to also make it really sensible and choose to keep things real. So go out there, choose to engage with your local community and choose to look after your colleagues, because you'll see that just because you have changed heads and experiences within people that does the exact same discipline as yours expectations are so different, ways to implement and solve problems are so different. So the best possible advice would be to choose industry leaders and choosing local team members as well.

  - Brilliant response. And Paulo, that's one of the reasons why we really enjoy speaking to practitioners and experts such as yourself that might not be as widely known as some of the other product people, but actually you've got real-world practical experience and so I love the fact that you are getting a lot of your learnings from just your immediate peers because they have the context of the company, they all bring their own special parts of their squiggly careers to it. That's why we love, you know, having people like yourself on the channel to share that exact experience with our audiences so thank you for sharing that.

  - I think it, for me, it was also important to normalise that because I came to a moment in my career, within my product career that it was quite pivotal for me, which was to find ways to connect with other peers or even pivot within the industry to other product companies. I find it really hard to, for me to be well understood when it comes to exposing my own experiences. Having started as a software engineer, having combined with UX and UI design background, combining with a non-consultancy or non-product company working for a retailer, and finding ways to organise all of those thoughts, finding ways to organise that product individual sales speech, and knowing that it was hard for me back then, I think that's why I found it really important for me to go out there into the product industry as well and try to then again make friends there, make them see that it is really okay that someone has a squiggly career. And everyone within the product industry benefits from it. I think we start seeing that today. Then again, because of the usage of AI, you start freeing up more space and more time for you to do other more creative work. And what if right now, as a product individual, because I have collected all of those experiences before, what if I'm the best possible person in the room to help influencing product decision making? And that's why I wanted to give back to the community back then, because I wanted others to feel that they should be empowered to go out there and experience other areas, gain different skill sets, squiggle around their career. Because ultimately, if they wanna become like better product individuals, better product leaders, you'll be only as good as the collection of experiences that you have, the collection of problems that you have solved, the collection of people that you have influenced, the collection of customers that have made an influence on. So yes, giving back to the community and talking about product operations and product management, better management, has been something that I've been really into 'cause I wanna help normalising the industry in this sense.

  - Yeah, brilliant. And if you only follow the same experts and guidance from those, then you're not necessarily understanding the wider context and experiences of everybody else. And we run the risk of kind of that sort of herd mentality or that kind of common thinking, actually, there's so many more places that we can learn from. So Paulo, I totally agree. I've learned a lot from the periphery of product operations speaking with you, and I'm sure some of our audience will have as well. If some of the stuff that you've spoken about has resonated with them or they wanna get in contact with you, how can they best do that?

  - Well, they can find me on Substack. I have my own Anxiety Club, which I've started over a year ago, writing about things that triggered some kind of anxiety within the work context. Through LinkedIn, of course. I am an active mentor on ADPList as well. Just find or search for Paulo Garcia there. But I would say that the best possible way to find me is on LinkedIn and then we can chitchat and see what is the best way for us to get in contact.

  - Superb. Well, Paulo, that concludes all of the questions I wanted to ask you today. I've loved the direction that our squiggly interview has gone, and some of the human aspects that you've brought to the role. So personally for me, thank you so much for joining us on Talking Roadmaps. Folks that are listening at home, if something has resonated, please do like, comment, share something with your colleagues of a golden nugget that Paulo shared with us that you need, think someone else needs to hear. And if you want to get in touch with the channel and take part, then please feel free to reach out to us at talkingroadmaps.com. Otherwise, all it leaves me to say is, Paulo, thank you so much for being a friend of the channel and sharing your wisdom with us. It's been really enjoyable. Thanks, Paulo.

  - Thank you so much, Justin, it was a pleasure. See you next time.