ProductOps with Anabela Cesario

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray’: And I’m Murray Robinson.

Anabela: And I’m Anabela Cesario. 

Murray’: Hi, Annabel. Thanks for coming on and talking to us. We want to talk to you about product operations. It’s something we’ve heard product managers in big teams talk about recently so we wanna find out what it is, but let’s start by getting it an understanding of, who you are and what your experience is.

Anabela: okay. So, I’m currently the VP of Product Operations and Chief of staff to our CPO at Out Systems. And I joined our systems in 2016 to bootstrap our first product ownership practice. Back then, I was reporting to our VP of engineering, and then in 2019 I moved to product management and I led a team of 20 product managers.

And in 2020 I was invited to bootstrap the product operations area. And mainly back then, I was invited because we were in a hyper growth stage and our VP realized that having a product operations area would be really important for us to help us over overcome that phase. Prior to that, I was working on in information system consulting at In General Electric and also in Novabus and mainly I was guiding large teams and complex programs. I always had a really strong focus on customer-centricity. I’m based in Lisbon, the home of web summit, and nowadays has an exciting tech scene and when I’m not working, you can find me practicing yoga, jogging, traveling, and reading, of course.

Murray’: Okay. And what is Out systems? 

Anabela: Our mission is to give every organization the power to innovate through software. we have a market leader platform that help us and our customers organizations to build applications fast and for the future. Basically, we are a development platform.

Murray’: Okay, good. All right. So first thing first, why do we need product operations?

Anabela: Why do we need. We want to improve the life of our product managers and we want to make them more productive and remove from them, everything that is related with processes, tools so they can be focused on the customer and on the product. If you are in this scenario, you can have a product ops team.

Murray’: But what does product ops do? 

Anabela: We help product managers by standardizing tools, processes, governance also making sure we have key data. The data is centralized in a single source of truth as a way to allow our PMs to make informed decisions. We also share individualize best practice. We develop our onboarding program and promote other forms of training and coaching to develop our talent. And less but not least, we support our product strategy, definition, deployment and monitoring. Other companies do it in different ways.

Shane: Yeah we have a habit in the market right now of everybody taking the word and sticking the word ops on the end of it. ML ops, data ops dev. DevOps started it. And if I look at DevOps, it’s this idea of you build it, you deploy it, it breaks, you fix it. So that end to end process for a developer where they manage all the moving parts they need, there’s no constraints on other teams, and they’re responsible for something working and where the consequences of it doesn’t, the way you describe product ops, it sounds more to me like a coaching practice. So it’s a support network of, good ways of working, upskilling systems, templates proven paths that help product managers do their roles in a more efficient way. it’s still about automation to a degree, but it’s not really like DevOps the way you described it. 

Anabela: Yeah, you are right. What we did about systems, when I would strap the area, I decided that my team will support PMs and the counterparts, all the engineering roles, all the cross company areas, from marketing, from sales, from solution architects, all of the field teams. But we never make product decisions. So we are an enablement team that supports PMs on the growth

Murray’: But you also said that you do product data platforms, standard product deployment and monitoring. 

Anabela: In some organizations, data teams also can fit inside product operations. But we have a team of data analysts that is collecting and monitoring everything that is related with product adoption metrics and also initiative success metrics.

And nowadays our product leaders, they make decisions based on the data that we have. Three years ago, we didn’t have a lot of data at least organized. Nowadays we have. The other part that I mentioned is that supporting product strategy definition deployment and monitoring. So every year we review our strategy based on the market input, based on the customer feedback based on the priorities that we have. We review the strategy and we help the CEO on that exercise. And then we are responsible for creating a communication planning and help the team get buy in from stakeholders. And then every quarter we monitor the strategy execution. Mainly we go analyzing the metrics and then we do an analysis and we help the CPO understanding if the strategy is going on the right direction.

Shane: So do you set the product metrics or is it more a case you set? High level OKRs and then each of the product managers will set, metrics that they’re managing within their product. Let’s say that you need a metric, to determine product usage. Is somebody using a feature or not? So is that something that your team sets or is it you set up the frameworks and then the product managers pick the metrics that are important to them, but make sure that they’re in line with the way you do metrics across the organiz. 

Anabela: Okay, so on that strategy definition phase, we work with PMs and also the data team on defining the right metrics. So we define on this strategy definition cycle, and then we help monitoring the metrics. And if we are talking about adoption metrics we help them measure after the production deployment.

If we are talking about initiative success metrics, my team also help because for instance, for each initiative, we define success metrics, and my team helps monitoring. The definition is we do it together, but then my team supports all the measure and all the analysis.

Murray’: Okay, so I’m just looking at UNFI and I think then that you would be as a facilitation team for product managers? The difference from a platform team is a platform provides shared services. They build applications and things for other teams. But you don’t do that

Anabela: No, we don’t. No,

Murray: Yeah. Okay. 

Anabela: We’re mainly a facilitator among all the stakeholders of the company

Murray’: yeah, so why do you need this? How many product managers are there at out 

Anabela: nowadays. We have 35 of a team of, 55 as a whole.

Murray’: 35 product managers. Okay. 

Anabela: Yeah. Yeah. And then we have my team, we have the data team, other roles. So the size of the team is 55.

Murray’: Okay. And do you support product owners as well? 

Anabela: We have product owners in engineering and they are not reporting to the product management structure.

Murray’: So you said a couple of things about best practices, standard processes and governance, which worried me because that sounds like bureaucracy. 

Anabela: Okay. Fair enough. And I agree with you. You need to be very careful whenever you talk about standardizing process and so on. So you need to do just enough and simple process to help everyone. And I can give you an example. So when we started two years ago we did a discovery phase. We needed to understand what were the main concerns of our stakeholders that in our case are the PMs . And from that, we understood that PMs spend a lot of time on gathering customer feedback.

Each one of them had their own Excel spreadsheet to collect product feedback. We use a huge Excel spreadsheet to manage launches, releases and so on. So the process was really error prone. So what we did was we select a tool that is product board, and we designed the simple enough process on top of product board that allow us to run the process in an agile way. 

We called it our product management, single source of truth. We have all the product insights being managed and collected on product board. We have 80% of the company giving us feedback on product board. We have solution architects, sales people, customer success managers, engineering, PMs even our cpo give us feedback on product board, and then we also prioritize all our initiatives aligned with strategic drivers. So aligned with our product strategy, and we have different roadmap views tailored for each specific stakeholder. So the adoption is really something important for us.

So what we did, we sit down with PMs and design the, just enough and simple process for them to work. And I can tell you that we have a strong 75% adoption on using product board in the last one year and a half. So my opinion, and I always tell my team, that is, so don’t define process for the exception. So represent the main use cases that will take time for PMs and design it really simple so they can use the tool and adopt it. Because if you are designing a process with all the exceptions and with all the use cases, the tool will become very heavy. The process very complicated and people don’t use it.

Murray’: Yeah, that’s what I’m worried about when I hear about centralized groups that define processes for other people is that sometimes the processes aren’t very good or they might be old fashioned, or they’re too detailed and they get imposed on people who don’t want it, and it prevents them from doing continuous improvement. 

Anabela: What we did was we use a proof of concept For each one of the main use cases we use one or two product managers as a champion. They designed the process with us. We use a small example, we test it for three months and only then after improving the process we out to start involving other pMs.

Murray’: Okay. And is product board your main tool that you use with product managers? 

Anabela: Yeah, for the three use cases that I told you for, manage all the products feedback for prioritize initiatives and for share product roadmaps.

Murray’: All right. So what, when you started, what was the feedback from that you got from your stakeholders outside of product management? What were their concerns about the way product management was going? 

Anabela: Okay. The priority when I start was to improve the relationship with field teams and I’m talking about sales solution architects and CSMs because, the relationship was really fragile, they felt that PM didn’t listen to them, they didn’t understood roadmap, prioritizations , they even complained that they didn’t have all the information that they need to work. So this typical pm and the field teams problems

Murray’: Yeah, Okay. And did you have the problem where field teams were promising stuff to customers that the product managers hadn’t agreed to?

Anabela: Yeah, we still have that problem nowadays, but we resolve that with a different role inside the product management structure that is not in my team. So we create area that we called field strategy and support. So we have ex product managers with a lot of experience in our product that they support the big deals. So whenever we have a deal with a tier one customer, they help and they participate on the process to ensure that we are not over promising to our customers. And since we dedicate this group of people to supporting. Those problems reduce a lot.

Murray’: It’s so common. 

Anabela: yeah, it’s really , well known problem.

Murray’: And the other thing related to that is when the sales teams do all the estimating and costing without talking to product or engineering, that also often goes along with it. Did you have that as well? 

Anabela: Not that much probably because up until this year, we had only one product and it was a mature platform, so we didn’t feel that. Now that we are launching a new product. So probably we’ll start having that again.

Shane: So when you talk about 20 or 25 product managers, how do you segment your product then? If you’ve got one product? What’s the definition of a domain that a product manager will look after compared to the other product manager? 

Anabela: So we have a concept of product group where we have PM and engineering working under the same umbrella. We have our CPO and our CTO with a very good relationship in collaboration. Then our teams we use the product triad from Marty Kegan, the pm, the design person and the engineering team.

And now talking specifically about the PM structure. So because we are a platform and we support the full product development life cycle from building, from having the C I C D, the staging in different environments, so to go into production and so on, so we have our platform organized around product groups and each group is responsible for one part of the development life cycle. 

And then you have product groups with a strong leader from PM and from engineering, and they have autonomy on making the decisions on their own product group. And then what we need to help is, when you have intersections or when you need to collaborate, we need to help improving the collaboration.

But the groups are autonomous on making decisions about budget, about resources, even about scope. And for this to be possible, everything is stated with the product strategy. We call it level two product strategy because level one is the company, and then each product group has the detail on the level three strategy.

Shane: And so therefore, are the product groups working in iteration bases? Are they time boxing delivery?

Anabela: We have quarterly plans, high level planning but then we are working on sprints and two, three weeks of sprints. So then we follow the, agile process and you go picking the thing that is more priority to work on. So because we have our backlogs prioritized,

Murray’: But, it sounds like while each product team is doing part of the customer workflow, each product team can deploy their feature changes independently of the others. Is that 

Anabela: yes and no. We have different release lines and you are autonomous to deliver in the release line that you are. But if a release line has one or two parts of the platform that live together, you need to align inside that release line.

Shane: So, I can probably guess that one of the product groups is around APIs or a subset of the APIs. Would that be a boundary for a product group ? 

Anabela: You can call it platform group. You can see it as an api. Yeah. It handles the main part of the product and serves the others. I’m not using API in the exactly technical sense of an api, but, we can use it as an analogy.

Shane: So what I’m trying to do is I’m trying to figure out the product groups and your development life cycle and the interaction between those two, because we know that handoff between groups is the most dangerous area. We have a shared language, then we have dependencies, we have context and interpretation, and that’s where with a flow-based model, if it’s not a factory where there’s a contract and we can see the part going on the car and it fits right. And that’s not what we’re doing, that’s where we have all the dangers. So can you give us an example of maybe, two product groups that are closely coupled.

Anabela: For instance, we have two groups is our platform group and also our cloud. Because our product you have on-prem and cloud offers. So the on-prem and the cloud have different release lines, but you have a relationship between the platform group and the cloud group. Because the platform builds stuff for the two groups, so you have always a relationship between the platform and the cloud group.

Murray’: I’m a bit confused about the responsibilities of the different product teams are the product teams organized around feature sets, for example. 

Anabela: So the engineering teams are focused on assets and we are focused on use cases and the value that we want to deliver to the customer. So is the work of the triad to get this use cases that we need to deliver to the customer and map them to the assets and the structure of the team. And then we have people inside engineering that helps controlling the dependencies between the assets. Because it’s more complex, to manage the assets

Shane: So if I think about Spotify. There’s a set of features around recommendations and there’s a set of features around if I want to go jogging. So in the Spotify app, I can see features that are then bound to a product team. That’s what you’re doing, you’re breaking up these sets of features or value to a customer. There’s a product manager in charge of that and that product group is now doing it. And then you have an engineering layer that kind of sits across everybody because they need to do some work to make that feature real and deployable and that kind of stuff. So you have a very big platform engineering team underneath and then product teams that are focused on customer value that then need to be supported by the engineering team to deliver.

Anabela: Yeah, exactly. Yeah, 

Murray’: Okay, so what does a product team look like? 

Anabela: We are using the triad model from Marty Kagan. So we have a product manager concerned about if the product is valuable. We have a senior product experience guy that is someone that is responsible for the experience and for the ux. Focus on understanding if the product is usable. And then we have a product owner, an engineering leader and usually 5, 6 developers and a person focus on the quality issues. In some cases we have also an architect working with the teams when we have new pieces.

Murray’: Okay, good. And are they all full-time allocated to the same product team?

Anabela: Yeah, we have that nowadays. In The past we use not a hundred percent module. We split the person between different teams. And it didn’t work well.

Murray’: So what is the difference between a product manager and a product owner?

Anabela: Okay. In my definition, I don’t like to separate product owners and product managers. For me, they are all product managers. The difference is the experience they have. So usually a product owner is someone in the first three levels of the product management career. It’s someone that understands what we need to deliver to the customer, but works with engineering grooming the backlog, find the user stories giving engineering teams all the context, supporting all the agile dynamics and the PMs are the other levels of the career, and they are much more focused on understanding customer needs, the market, defining the strategy and so on.

Murray’: Okay. I’m interested in how your organization tests their hypotheses. It’s very common for people in sales and senior management to tell product managers, I want you to build this, and then they go and build it. But if you listen to Marty Kagan and Jeff Got Health and everybody else, what they say is that all of those requests are hypotheses and they all have to be tested before you put them into the build pipeline. So what does your company do about that?

Anabela: Okay. We used the TORS continuous discovery methodology. We work with her and we had some coaching from her back in 2019, I believe. So we have the pm someone from experience and when needed an engineer working on the continuous discovery topic. Teresa has a model that is called Opportunity Solution tree. So he lists all the opportunity and then she interacts and tests some of the opportunities to understand what they are. And this continuous discovery is one or two steps ahead of development. And in parallel we have the continuous delivery track that is the engineering team. The hypothesis was tested is valid, so now we are working on it.

Murray’: Is continuous discovery, done by the product team? By the same people. 

Anabela: Depending on the size of the team. If you have more than 1:00 PM you can focus 1:00 PM on doing one thing on the other. In our case, we have the same PM that works in two places. He dedicate sometimes to the continuous discovery, building the future, the next things to do. And also works with engineering team on delivering. The same with the product experience guy. The engineer comes when we need support from an engineering to build a POC or or to create specific AB tests or something like that. The PM is also has a secondary role in here that is ensuring that what we are discovering, he’s somehow tied it with strategy of the product. They are responsible for ensuring that we are working, align on the strategy. Sometimes we have teams focus on innovation, and in this case, you can have an idea that doesn’t need to be connected with the strategy on a short time, or we use the horizon one, two, and three to define the strategy. Usually the innovation is more focused on the horizon two and three, and for the horizon one, we work in this continuous discovery and delivery mode.

Murray’: And are your product roadmaps based around feature sets or are they based around outcomes and key results? 

Anabela: Outcomes. Yeah we call it value milestone. So the way we do it, a product manager needs to understand the customer problem that we are trying to solve. We call it use cases and when you have a big use cases, we drill down in value milestones.

And the value milestones is organized around the outcome that we wanted to achieve. After that, we work with engineering in the triad and we translate the value milestone to the solution. But PMs are mainly focused on defining the right problem. 

Murray’: That’s good. Cause what we find is that product managers and project managers go from outcomes to features and solutions almost immediately. And then everybody forgets about the outcomes and nobody even tracks it except to say, did you deliver the feature. 

Anabela: In 2016, we were in that stage. Some PMs came from engineering and it was really difficult for them to focus on outcomes and not thinking on the solution. So in the beginning it was really difficult, but, year after a year, they are more thinking on outcomes, thinking about this value milestone and working with engineering on the solution.

Murray’: So how did you get that organizational change to occur? 

Anabela: I think it was the work that we have done in the last 6 years. I think the two main things that promote this change was Marty Cagan triad. I really love this model, but it was difficult because you need to have an experienced product manager, and then experienced engineering leader. So they can work in collaboration, but sometimes is very good to have some friction between them it, This doesn’t work when you have one that is stronger than the other.

So in the beginning we faced this challenge. Some of them were more seniors than others, so this imbalanced the relationship. But I think over time we were able to try and some higher new ones. So we resolve this problem. The second one was the transit towards the opportunities solution three, the continuous discovery, continuous delivery way of working that I think, changed and helped the teams moving to this mindset. So they really understood that investing on continuous discovery, talking with customers, testing the hypothesis would move them to the right direction. And in between we had some products that we had to sunset, because in the beginning, were not that good on this, so we try and fail. But we learned along the way. 

Murray’: And it sounds like that’s a important role for a product ops team, the way you’ve described it as a facilitator to help people in the product management area develop good practices and implement things like continuous discovery. 

Anabela: Yeah, it is. What we do mainly regarding this part is that we act like a facilitator. So we have all of these practices and then we help them execute.

So our main goal is to help them. It was to help them define, and nowadays to help them, whenever they have a blocking a roadblock or something, we go there and help them. Also, I have people on my team that is constantly monitoring the processes, interviewing some key people inside engineering and the product. So every six months we conduct more formal round of interviews. We call it the discovery phase, where we talk with all of the key roles, 

And we ask, okay, so is the process working better? What are the things that we need to improve? And they are correcting this the process and simplifying and this basically what we do regarding this.

So helping the definition, but then also helping, improving the processes. And identifying the main pains and find solutions for it.

Murray’: So I wanted to ask you about dependency management between product teams and engineering because it sounds. There are quite a lot of dependencies and it sounds complex And There are very different ways of managing dependencies. I wanna put two options to you and see what you think. So the most popular option is safe scaled agile frank work for enterprises where basically you just accept all the dependencies and you manage them all through dependency maps and their famous red string boards and a lot of program governance. That’s one way of doing it. 

The other way of doing it. Is to remove the dependencies. You do that by restructuring your teams so that they are as independent as possible. And if they’re all dependent on a common api, then you set up a real api like a commercial api, which allows teams to operate pretty independently because they know the API is staple.

They can see what the next API release is cause there’s a test version available. And the dependencies are managed by simplifying them and removing them. So I’m wondering what your approach to dependency management is between product teams and engineering. 

Anabela: Yeah. I like the second one where you try to remove the dependencies and the way we are organized around the product groups, around having this triad on the product team and having senior people on which team helps a lot. But even though if you use this, sometimes you have dependencies.

And when you do what I believe helps is that in the beginning of your planning cycle, based on the priorities that you have for your backlog, you need to upfront identify the mind depend and work with the teams to understand what is the best way to plan according to that dependencies.

So they don’t become a surprise in the middle of the sprint or in the middle of the planning cycle, but whenever, possible, I really defend removing the dependencies so teams can be much more autonomous.

Murray’: All right. So you’ve got 25 product managers. How does your organization decide how much resources each one gets, what their budget is? 

Anabela: Very good question. So based on the priorities of the company and our product strategy in the beginning of the year, we assign budget. Based on, our strategy. And then each product group has their own budget to manage throughout the year. And they are autonomous on deciding what are the roles that they want and so on, what are the features that they prioritize based on the strategy. Whenever you have an exception, something that changed market, we go and we review the strategy and if needed, you cross correct it. Imagine if for some reason that group needs more budget. We review the budget, but we tend to do it in the beginning of the year based on the alignment with our strategy.

Murray’: Okay. Alright, so last question from me. Product ops is pretty new. What have you learnt from doing it over the last couple of years? 

Anabela: I learned that organization and planning can improve the performance of the team. Someone understanding the main problems, and focused on solving the problems helps the team to be more performant. In our case, we have a lot of PMs coming from the startup and needed to be trained for this hyper growth mindset because the skills are different. So we need to train them or you are supporting processes, removing, working from them. So trying to summarize you have product ops in your team, you can have someone that is focused on improving your performance as a team. 

Murray’: Okay. That’s good. Shane, did you have anything else before we go to Summ? 

Shane: No, I’m we good? 

Murray’: Do you wanna kick us off? 

Shane: Yep. Do indeed. So when I’ve heard product ops, I automatically think DevOps, I just think it’s another thing with the ops word on it and. The way you describe it is for you, product ops is a team of people supporting the product managers. So you don’t do the work. You don’t make the product decisions, you don’t tell the teams what to do. You’re sitting across watching the ecosystem and then figuring out how to influence it and improve it. So it’s the same as agile coaches, where we sit outside, we look at what’s happening, and then we help make suggestions about, looks like there’s a bottleneck there. Looks like that team over there is rocking it. Would you like to try that? So that kind of improved the system, but not actually working in it ourselves. If we actually caught ourselves Agile ops, then it’s probably gonna be a little bit clearer about what we do. Agile ops heard it here, let’s go write that book. 

So interesting your data analysts don’t report into the product teams or the product groups. Good that you got them. Good that you got the stats. Interesting they sit outside and then seconded in. 

And then the idea of the product triad is the same as the three Amigos, it’s three senior people with three different lenses. A lot of alignment between, the three amigos out of agile kind of ways of working with that trio out of product ways of working. So often, we see the same patterns, we just use different names.

I like the idea that when you described about putting product board in, you said you focused on the happy path, on the like processes. And that the anti Patton is actually figuring out every exception and trying to deal with it. I have a intense dislike for Jira. I think it is one of the horribles products to use in the world, and I don’t understand why everybody uses it. But I think part of that is because whenever somebody configures it, they try and take care of every exception and they make it even more unusable than it is outta the box, and it is an ugly, unusable product outta the box. So I might go look at product board. 

I like this idea that your product groups are backed by a product organization and an engineering organization. Product led by your cpo, chief product officer, engineer lead by cto. They have a good relationship, but also there’s that friction. What should we build and how should we build it? that friction’s important. 

And then this idea that your product teams are self-sufficient. So the tree ads that’s across the top of it, pm, UX and engineering. And then five to six devs in a QA and then an underlying infrastructure platform, team or organization due to the complexity of the way you deploy your product, so it’s a supporting service effectively because bringing those back into each of the teams would cause you some problems. And then you talked about the architects being specialists. If we use un fixed terminology they drop in, help out when there’s some complexity that’s needed.

And then we also talked about the idea of a product owner. And for your organization, it’s really based on level of experience. Start off as a product owner with a delivery team, help ’em do that work and then, get yourself to a level where you’re experienced enough to bring on those product management skills grow into that skill set. So I like that. I haven’t read a lot about the continuous discovery cycle or the tree things. I’m gonna go read off on that.

Murray’: We’re interviewing Teresa Torres next week. 

Shane: I don’t have to go and read the book. I will listen to her and find out what it’s all about. How cool is that? And then the last ones for me was I really like the idea of H one, H two, H three for Horizons, this idea of saying these things we’re gonna worry about right now. These things we should worry about in the, in the next lens, next future.

And these things that are big problems that we can solve long term. And we’ll bring them in when it’s time to bring them in, but that real focus on where in the horizons is something live, I find helps of conversations. And then the last one for me that I found really interesting is this idea of value milestones. So that the roadmaps based on value milestones, on achieving outcomes, not on features. That one intrigues me of how the hell do you define a value milestone without making it a feature, cause that’s what we all do.

We love to make solutions easy. Define the solution. That’s so much easier. What was the problem? So like I said, product ops not what I expected, but hey, that’s part of the cool stuff about this podcast. I learn something new every day. Murray, what do you got?

Murray’: Yeah, I’m looking at the unfixed model from Yugen, Appella, and your product teams. are basically the same as value streams and your product ops is a facilitation crew, and then you’ve got a large engineer platform crew because of the way your technology works, which is providing services to the product teams. I think that’s the way I see it. You’re not a platform team yourself because you don’t provide APIs to product managers. You are coaching and supporting and helping with processes. So that all makes sense. That’s all good. 

Organizations have a tendency to become very bureaucratic. They, when they talk about best practice and centralized processes and standard processes that can often mean that they’re forcing everybody to follow a bad practice because the people who develop the practice, Don’t understand what the teams need. So I was really pleased to hear that you see your team as being a service provider to the product managers, not as a controller of the product managers. And that you go and talk to them and you ask them what do they need help with? And you help develop products and, using product board and other tools to help them do their job better. And then you go and review how those processes that you’ve implemented with them are going to find problem areas and fix those.

That’s really good. There’s just so much of a tendency. For organizations to mandate standard processes that everybody has to follow. And then it’s just prevents continuous improvement by teams, which is absolutely critical for, business agility and product development. So I was pleased to hear of your approach and your attitude.

That typically comes from the manager’s mindset. Somebody could come into your position and become the police if they were allowed to. Cuz they’re definitely lots of people like that in management when they’re looking after best practice. So I like your approach.

I guess you need product ops because your product team is so big. I think if you had a small product team of say four product managers and you had a vp a product. I would expect the VP a product to do coaching, mentoring, supporting, helping, improve processes, governance. It’s just a management responsibility. I would say, 

But you have so many people that you really need to spin it out into its own team. So it’s it’s a good model. It’s a good approach. I really like to hear that you are following Marty Kagan’s model and Theresa torres’s model and I dunno, if you’ve been looking at lean ux, you should have a look at that as well. That’s really good. Lots of people talking about this stuff and not many people actually doing it, so it’s good to hear people doing it. So that’s what I’ve got out of it. Did you wanna comment on anything we said?

Anabela: Yeah I think I would like to highlight something that you said that is really important that if you are a product ops manager or a VPO product, you always need to be careful with a lot of process. And if you are not careful you will not have adoption. If you do it really complex, PMs will not use it. And probably you will not be successful. You need first to focus on the things that are more important, that move the needle in your organization, but also find solutions that are easy to use. If not, people will not adopt it and you will not be a successful product ops team. Don’t overcomplicate it. If you do, people will not adopt and you will not be successful.

Murray’: Yeah. It’s so common. So it’s a good point. Now do you write, do you blog? How can people find out more about what you think? 

Anabela: If you want to find me you can send me a message on LinkedIn. I do some pro bono sessions about product operations, so helping people that are starting in the area or want to discuss some product topics. So send me a message on LinkedIn. And also , I’m speaker in some conferences, so if you Google it, probably will find some of my talks on the internet. Oh, and I have something that is really important. My team, we have a product ops and rap talk series where in the last two years we have sharing with our product operations community what we have done, the story of the first year, and then we have episodes that are explaining how we select and implement product board, how we launch our internal B2B product Management Academy, how we manage all the communication across stakeholders, how we measure the success of product operations and how, what are the metrics that we monitor inside our product team. It’s a mirror board that is available to all the community and you can find also in my LinkedIn for that. 

Murray’: Okay, great. Hey, thanks very much for coming on. It’s been great.

Anabela: Okay. Thank you for having me here.