Kickstarting Product Operations Success in 2022

Read the Full Transcript

The following transcript has been altered for readability. 

Hugo Froes: Hi everyone. I’m currently based in Lisbon, Portugal and I’m the product ops lead at OLX Group Motors in Europe. My background is in design. And over the years I started digging into more service design and design thinking, and user experience design. Eventually, it reached a point where I wanted to start looking at how teams grow. That’s why I went into the role of more design ops and design practices. And then at Farfetch, it was almost a natural thing. We were doing design, we were doing practice work there working on the design team. And then, it kind of happened where we pulled in product operations because they felt they wanted that in the product area. So that’s basically how I got into it.

Chris Butler: Yeah. Great. Well, nice to meet you. Great to be here today. I guess what really brought me to product operations is, over the last 20 years I’ve done a lot of different types of product management roles. I’ve dabbled a bit in business development as well, and you can see all the logos that are up there.

But what I think I started realizing over time, right? So the first book I ever bought on Amazon was Extreme Programming back in 1999. And that whole journey and the idea of, how do we start to redistribute power within the organization to better understand and better build things that are actually valuable to customers. That is something that you started to see with something like DevOps. You started to see it with even things like research and design ops. And then finally this idea of, how do we do a better job as product managers together within a team? That is something that I’ve been thinking about a lot for the last, say, five or six years.

And whenever I’ve been a manager on a team or been part of a team, I try to figure out, what are the right ways for us to improve our work as a group? Product managers are usually on a cross-functional team by themselves. And so, I started to see that as a real value. And so I’ve done what would be considered product ops work for a while at a couple of different roles. But this is really the first time where I’ve really had my incentives aligned with the work that I was actually doing. And so that’s, I think what’s really valuable or important about product operations. Anyway, my community is I’m a steward for a community of about 100 product managers and product analysts.

I also help coach and teach the way to do OKRs for an organization that’s about 15,000 people. And then, I guess I’m kind of the unofficial holder of the product mindset at Cognizant because I’m constantly doing workshops and teaching. And part of this is that I end up working on a lot of things that help salespeople or account managers, or architects or engineering managers. For us, as an organization, we need to improve our positioning with our clients to be more strategic. And so to be able to do that, we need to have product management be a key component of that. And it’s fallen on product operations to help drive that transition or transformation for a lot of our own internal organizations. So, that’s kind of my background when it comes to getting to product operations.

Becky Flint: Cool. Very interesting. So exciting to be here, as well. So, my name is Becky Flint. I am currently the founder and CEO of Dragonboat. So, as Bhaji mentioned earlier, we’re actually a platform built for product operations. And my background, similar to Chris is that I’ve done a number of things, definitely product management, a little bit of engineering management. I was a little bit of startup founder back in the 1990-something, dating myself. But one of the interesting things was that I got into product ops before it was even known as a product ops. My exposure to product ops was when I joined PayPal in the early 2000s. And I had a book on my desk. It’s called New Country Launch Playbook.

And that was really a playbook that was written by the first product ops at PayPal. It really helped us to figure out how to take a product that feels simple, but really is very complex to a new country that has the legal compliance, you name it, basically, every single function of the company basically would have a new flavor for that for the country to make it exist, right? Actually it’s funny that later on, we found out that some of the other, newer generation product ops companies like Ubers and Airbnb, started with the Country Launch. And it kind of became this roadmap to success for product ops.

We realized someone had to do it across all areas to launch a product in different countries. So anyway, I started at PayPal the role wasn’t called product ops. It was kind of like product ops. And then we built scaled and later on built portfolio management for PayPal.

And then, later on went to a couple more companies and Shutterfly, and so it went on to build product portfolio management strategy ops, and the product ops along the way. So, the journey to where we are today is to realize the practice varies in flavor, but the essence is very similar. Going back to extreme programming or agile. It is practiced in a way that’s somewhat consistent, but also different from company to company. So I’m excited to be here, and have more of a chat with everyone to know. It sounds like we have a lot of different journeys on where we are. So, I guess we kind of touched on it a little bit. I would love to hear your thoughts on the evolution of your understanding of product ops in your various roles. And how does it look like in terms of a success?

Hugo Froes: It’s kind of funny because coming from Farfetch, where we had built up a team of four across the whole product org, we had the support, we’d struck, we were creating an infrastructure and it was great. And we had things pretty much defined, but it was a very big organization. And now, at OLX Group it brings new challenges because I am suddenly that team of one again. What happens is I’m basically defining, what is the product op scope? What is the definition? And what are the principles? How do we work? So, it was very important to define that and set the baseline of what is the expectation, what it isn’t. Sort of telling people, okay, let’s say, for example, I like to use the example of tooling, right?

As soon as I arrived, everybody wants to throw tooling onto me. But I’m not going to manage the things like that. I’m not going to go down to the details. That’s the procurement team.” And it’s almost setting those parameters like, I’m not going to be worried about that. Because I think it’s about empowering the team, right? It’s about empowering the product team to do their best work, and that’s what I want to do. So, the thing is, it’s trying to find those areas where you need improvement, where you need to make them feel more supported and create that infrastructure so they can do their best work.

We started looking at OKRs. Chris, you talked about OKRs, I read some of your articles as a support as well. And we started looking at that and saying, “Okay, but how can we do this properly? Make sure it’s driving change.” And also looking at the decision-making process, looking at all of these parts. So, we’re starting to create here the infrastructure to then build up. But again, never to the point where it’s over, it’s too much process. To the point where it’s not adaptable, agile, going back to what you were saying, Becky. It’s keeping it constantly where it can move and change if need be. And if we find new things, we can organically adapt to them. It’s still the beginning of this journey, but so far it’s been super interesting. And it’s only been two and a half months.

Chris Butler: Yeah, for me, getting started inside of this role, I joined in March of last year. And so, there’s a lot. Whenever you come into an organization there are already processes that are in place. And not just from the standpoint of corporation processes, right? Cognizant is an organization of 300,000 people worldwide. And so, you could imagine there are lots of processes that is involved in managing an organization that size.

And so unfortunately I did get caught in dealing with procurement and administration of certain tools. That was very hard in a very large organization because the procurement team has a lot of very rigid processes. So, it doesn’t allow us to be as flexible as we want. I think when you first come in as a product operations person, the first inclination is to come in and try to build a process that makes more sense.

When the reality is, taking a step back and looking at the goals of processes that are there to then destroy the process is really the ideal thing. And so, I wrote a post about this on product-led alliance about how I believe product operations is about creative destruction. But I think that is really true, right? Like, the story I cite in a couple of different places was this idea that coming in, and we had a meeting called the council meeting, which is essentially where PMs that are on projects, right? If people are not familiar with Cognizant, we’re a consulting practice. And so, all the PMs will be on individual projects for clients as product managers. And so, we used to do something where they would have to prepare this very large slide deck.

They’d have to present this slide deck during a meeting, and it would be no room for discussion. And so, one of the first things I did was, well, one, I talked to everybody on the team. I would sit in all the different regular meetings that were already scheduled. And one of the things that I found was that this meeting was causing a lot of pain for product managers. It was something that they spent too much time on. They didn’t see the effects of it, and then even the goals that we had were not being actually in some way, met based on this meeting.

And so blowing up that format of the meeting and redefining what it meant, and we did this through kind of a series of experiments with certain meetings, seeing, and restoring what that meant, and then rolling that out to the entire organization eventually was really about that orientation that my customer is now the product manager, not the end customer.

Even the client that we deal with where the supreme kind of thing that we need to do is to always make our client happy. I actually don’t care. Between all of us product ops people, I don’t care about that anymore. I think there’s some good discussion to happen within, the product ops community because I’ve seen also other people believe that still, they still need to worry about the end customer. Setting the Table is a really great book about kind of hospitality in general. The author, Danny Myers basically talks about the way that he does prioritization of people.

He puts his employees at the top. He puts, I think it’s employees, vendors, customers, and then shareholders. And so, I think when I put this together, personally, I think of it as like product managers, product partners, so that engineering, architecture, whatever those people are, then management. I think that’s like a really important way for us to orient the product ops team so that we’re doing exactly what you were saying, which is like, we’re building a better practice for people to feel good.

And one of my OKRs is really just about making the product management community inside of Cognizant the gold standard for product management. And that’s a very lofty objective. The KRs that we start to look at are like, how much time are people spending with the community? What is their kind of like… I hate NPS, but their satisfaction score with regards to the community? How are we doing things like dealing with attrition and retention? And so I think if people want to talk about that, that’s how I think about turning this into a system that is actually tracked in some way, but also is about how good of a community do we have for product managers. And so that’s really, I think the journey that I’ve gone on.

Becky Flint: Right, right. I totally hear what you’re saying. Product ops definitely has lots of stakeholders, product manager obviously is day and day out. They work with you. In some ways, they’re almost like your team, even though they don’t report to you. And that’s like in, many companies where there was no product ops, the VP product, head of product basically played that role. You do product, you do ops, that’s product ops. When you have a big enough team that if you do too many ops, nobody’s going to lead the product strategy and all that stuff.

What I’m trying to talk about is one of the things that we realized is that people, a lot of times say, “Hey, product ops. It’s a new role. It’s a new function and it’s now,” but it’s not really true.

Before you had revenue ops and sales ops, the head of sales played that role. And then they’re like, “They don’t have time enough. They have to scale.” And then the sales ops role came into play. And now everyone knows what they do. Same thing for engineering, engineering ops, the same thing, the head of engineering doing that. And then, later on, they put someone else and the same thing for a product, right?

Since day one, like there’s a single product manager, that person played the head of product. Product ops and a product manager, maybe a designer at the same time. So, from that perspective, I think it totally true. Where the stakeholders, in terms of product managers is huge because they’re part of the team, working with them day in and day out.

It’s interesting you talk about customers. I wouldn’t think a product manager has customers. And then they are internal people, the business teams, the revenue teams, the customer success teams, because ultimately product team would get their input and also collaborate with them, and also build a product for customers externally, and also make sure that we deliver outcomes that supported our other functions. So, I think it’s very interesting where the NPS score, definitely, I think is something where when we started at PayPal, we had the function and what we were doing.

We called it product program manager versus technical program manager because that’s basically products. And what we’re trying to do, we really struggle on, how do we know we have done a good job? What is our measure? We spent probably a good 10 years, multiple iterations on, to make sure product managers are successful. They get the support they need to get, make sure the operation, the process is efficient so that we don’t have too many meetings or whatnot, or is it make sure that our different, the growing business, and not only you have different functions, the marketing sales, and all that functions, support, interact with the product organization in some form or fashion, also engineering. As well as we have now, we have a different business unit and we have basic markets, right?

You have different markets. So how do those people rely on products as well. So then we expand it to that group as well. And then ultimately, as the company grows from kind of products, still more like a product engineering, as a kind of group to really integrate it. Especially for product-centric and product-led companies, where product is an element of the whole realm. And sometimes, I think ultimately we realize that the product ops, at least for the companies that I’ve been through and the PayPal, like our final iterations, so to speak. Well final by the time I left, it’s nine years later, is that the outcome, the product team can create not just the outcome for today, not this feature, this release, not the outcome just for customers, but also for the markets, the regions, and across.

You don’t over-index in North America. Obviously, North America makes the most money, but if you don’t invest in AMEA and LatAm, then there’s no play, right? The company won’t have a future. So, I think ultimately what we did was like every role, we had a score card. Then we have to say as stakeholders across the board, where are we with the product community, our product teams? Where are we with our engineering community and teams? Where are we with the supports and marketing others, and the business teams? And then, we actually look at a score by different areas and I say, “So, we did a good job with the product teams, but not a great job with engineering or not a great job with the market.” Then we adjust that.

So, I think that the ultimate priority kind of changes as time goes on. Sometimes we did a really good job with the market and everything, but engineering is killed. Right? So, engineers, we don’t have good requirements. And then we’re rushing things through, we have a lot of bugs, we didn’t take care of the tech deck. And sometimes it’s like, okay, engineering, it’s good. We really move up this score. But then the region’s having problems because nothing happening, they’re losing. Scorecards internally also help us to say where we need to dial back and up and change our focuses. So, do you guys have something similar to that as well?

Hugo Froes: Yeah. I don’t have it at the moment, but I was looking at exactly that. And I was actually taking from the Kirkpatrick evaluation model is used for training effectiveness, and I was looking at the three levels and seeing if it couldn’t be adapted here, or the four levels, sorry. So the first level is around NPS scores, right? It’s like you were saying, sentiment scores, seeing how they’re feeling on different parts, and this can be done as soon as you finish any type of project or change or whatever. Then there’s a second level. This one, I’m not sure how to adapt, but it’s around a quiz. So, you actually ask a quiz to see, what did they extract from that process. Did they learn anything? Did they evolve in that sense?

Then you start seeing, you start measuring the behavior. And this has done more in a three to six month period. You start seeing if their behavior is changing if there’s a model change, and then the last one is around the actual reaction, and that’s the impact around the company. And so you start looking at, is the company, is the product org changing because of what you’ve done? Can you start seeing that? And so it goes almost from a quantitative to qualitative, but it sort of gives you the step ladder. And I’ve been trying to look at how I can adapt this, maybe to this model. So, that’s what I’m looking at, at the moment.

Chris Butler: I mean, I think this is like a really important aspect of when we think about these systems, and I had a very visceral reaction to the post that was on PLA about Taylorism in product operations. It made me angry, first of all, to hear the word Taylorism used with product operations. But again, I have the utmost respect for every product ops person out there. So, I will figure out how to navigate this in a way that is interesting and helpful. But yeah, I think like this idea of, are we talking about it as a system that can be established and the rules are known or are we talking about a system that is highly complex, that involves lots of different types of organizations inside of our organization?

And I think it’s more the latter than the former, but there’s room for both of those things, right? Like, this is something I’ve been thinking about with the difference between project management and product management is this idea of product management being a lot about embracing the uncertainty of the world. Whereas project management is about how do you build safe environments for software development, right? And those are two very different things that need to happen. It’s interesting because then in the product ops world, the way I’ve usually approached this is when I first got to Cognizant and was starting to map out all of the different causes and effects that we’re starting to see, that are in some way impacting each other and creating kind of loops or flywheels.

And so, the biggest problem for us was, we were being put on projects that weren’t ideal for product managers. They were more like scrum masters or user story writers or horrible, horrible titles like that inside of clients. We were not getting the bill rates that we wanted. People were not getting trained up to the levels that we thought they should be. And so, there was inconsistency in leveling. So all of these things end up being interconnected and it’s not like I can institute one policy as a product ops person that will just fix all that stuff or even multiple policies. And I don’t even know what would be a policy I could implement that would fix all those things. It’s more about this idea of, from a complex adaptive system thinking point of view, is this idea of interventions inside of the systems or probes.

And when I say probe, I mean from the standpoint of Cynefin, the Dave Snowden complexity theory is that you’re making small interventions into the system to see whether it improves a little bit, and those things all snowball together to become better and better overall. I think this idea of, what are the things that we need to make safe? And when I say safe, like we need to check the boxes that legal was talked to before this thing is released, versus this idea of, well, we want to have as much ability to be resilient and robust and adaptive of these teams.

Maybe a good example of this is that whenever I’ve read through all of these handbooks or playbooks for product management, there’s usually one page that talks about communication, right? And that communication is like, “We do it this way. The escalate is this. We use Slack for these things. We use email for these things, blah blah blah.” And what I saw when I came into this community was that there wasn’t really an issue about communication.

Like, there were a few ways that we communicated as a community, but it was kind of known. And then, for the most part, people were on client teams. And so it was whatever those client teams wanted to do as far as communication. So, actually writing some process around our standards for communication didn’t make sense because it wasn’t going to help anybody. It was just going to create more processes for the process’ sake.

And so I think that’s where I’m coming from when it comes to a lot of this stuff too is like, how do we understand, or we start to map out this complex system? Which involves all of the people that both of you are talking about. It involves all these partner teams. It involves all of these different groups. And so, I mean, that’s why that Venn diagram of product management is always the least helpful Venn diagram now.

And I hate the fact that whenever someone creates a new role, they create a new Venn diagram. It’s like the worst way to explain what you’re doing is a Venn diagram. And so, it’s actually many different things when it comes to product management, but the reality is like every other role too, because every other role in a cross-functional team is working together. So, that’s why I just think it’s maybe an unhelpful simplification of what we do. But it is about dealing, not only working with and stewarding the community of practice for product managers, but it’s now making sure that there’s not frictions or problems with other people. And that could be both from the standpoint of embracing uncertainty as well as building better, safer systems as well.

Becky Flint: Yeah, I think that you’re right. When you really think about it, every function today, regardless of the sales, marketing, product engineering, they are hugely cross-functional and has lots of communication and collaboration across and within, and up and down, right? And every function, the Venn diagram really is just that you have a ball with everything interconnected, you twist turn to the ones that your viewpoint, and then you think it’s going out. But for the other person, look at a different side of the same connected ball. That person’s viewpoints connect out. I think that totally is really where it’s interesting. A lot of people tend to think that if I’m a product manager, I’m more sort of collaborative.

But if you think about the sales, sales can sell anything. If it’s not there, they don’t have it. Every function including product ops obviously is very cross-functional now. Actually, that leads to a good question. I think that we just had an audience question about product ops and a product manager. What are the roles and responsibilities in your experience? What are the boundaries you think should be fairly cleanly defined between those?

Hugo Froes: Anybody who’s from Farfetch, where I used to work, all say it in a simple way. It’s focusing on the how rather than the what, right? So, it’s focusing on how the team works, how the team responds, and how the team makes decisions. It’s a lot on the how, and how we build the product. Whereas with the product managers, they’re focusing on the what, right? What is the product you’re building? What is the response, the problems you’re solving? And it’s focusing a lot on that. That’s how I create that distance between the two. And even earlier today, I was talking to someone who was thinking about implementing some ops roles in the company. So I told him, “Look, the truth of the matter is you’re going to have to negotiate because there are people doing those ops roles.”

Now, you have to negotiate that to take that away from them because there is that overlap. And now suddenly you won’t be able to have that overlap, you know? So I think, I like to keep it in that simple way, because it’s very simple. If someone comes up to me and asks me, “Oh, look, I’m having this problem with the product and everything like that, or the customer,” and I’m like, “Okay, how would you solve that problem?” And I can guide them through that problem, but I won’t tell them, “Do this with the product.” That’s the head of product, the director of product that will give them guidance. It’s not me, per se.

Chris Butler: Yeah. And I think the boundaries are really interesting. This may be an unpopular opinion, but I believe product management is a glue type of role a lot of the time. And I do think that product operations is also a glue role in the sense that we’re constantly amorphous and renegotiated. And I think that’s something that happens with a lot of roles that are focused on uncertainty. I think if you can write down 100% of the job requirements or specific things that a product ops person would do, you’re probably boxing yourself into a place that doesn’t allow you to now adapt to the circumstances. And so, I think some of the key things that… I mean, I think the boundary that is most concerning to me is when it turns into basically bullshit work.

And so, from the standpoint of product ops is not there to do the job that product managers do not want to do. That’s not what we’re here for. And I think that there are borderline cases where that starts to happen. And so maybe like, how do you identify that? I’ll tell a story from when I was a program manager at Microsoft. But, and this was like a long time ago too, but we would joke that my job was to get the engineers sodas when they were staying late, or order pizza for them. And it was half-joking because I actually had to do that as well as stick around and, what was my job to be there was just like, hang out.

I didn’t do anything other than soldiering, essentially for the fact that everybody else was there late, because they were trying to meet some deadline, and I had to answer a question occasionally. So I think the part around product ops being helpful is that we want to make sure that people don’t make the same mistakes multiple times. We want to make sure that they’re not getting caught up in the bureaucracy of the system, or that they’re doing something over and over again, that is in some way causing them extra pain, or work. That’s why I think a lot of early product ops, like the idea of Pendo or Melissa Perry focusing on things like collecting qualitative and quantitative results somewhere, is because they didn’t have great partners in those companies that were data scientists or user researchers.

And so, I think we need to adapt to the problems so we can make people most effective as product managers. Inside of Cognizant, a lot of the stuff that has been the highest priority recently has been, how do we thread all of the competencies and levels for product managers? By the way, I actually think the competencies and levels for product managers should be the same for product operations. We just replace customers with PM in every one of those places, basically. So that’s one thing that I’ll say out there, but the way that we thread that through recruiting and interviewing, performance evaluation, giving feedback, promotion, and then also the idea of enablement and training, trying to standardize that so that people understand across the board, how are these things involving all of these different stages of their career within Cognizant is a very high priority.

But what things are not a priority is like, user research is kind of nascent. So yes, I should. I’m trying to teach people to do a better job at that, but they don’t do a lot of it inside their clients. And if they do, usually they’re working with a designer or a researcher. And so, that idea of collecting all of the research somewhere is just not as valuable to our team. So yeah, I think there is a line definitely. And it’s when a product manager is like, “I just don’t feel like formatting this document. Hey, product ops person can you help me format this document?” Which in design ops is probably the same thing. Design ops is like, “Can you help me reformat this slide deck?” No, I will not help you do that. And so, that’s what I think we need.

Becky Flint: Yeah, yeah. Totally. Product ops is not a team admin. So, that’s just putting it really bluntly. I’m not here to take meeting notes, I’m not scheduling meetings for you. But sometimes when people are not talking, we kind of help out as well. So ultimately you think about the product ops, it’s kind of like the enablers. And because they’re really thinking about the categories of things, it’s like, “Okay, how do I enable people? How do I enable the process? How do I enable the technology and systems and platforms?” So that’s like underlying stuff. And I think that it’s interesting where once you have product ops, the first things you do is the people tend to, everyone in the product organization come to you to ask for random stuff.

And then the next thing you notice, everyone in the company comes to you to ask for random stuff related to the product. Now, I think in some ways the product ops do play a role. Almost you think about either traffic cop or sort of the orchestra person, right? So first of all, people, especially when you have product organizations start to get bigger, there are internal facing things. What are our cadences, where the product teams are having challenges and doing really well, which team does well in one area as the others?

So, that’s definitely something that enables the team to be effective and their performance better. The second part of that is really in a way, where nobody. Like product ops is really in this unique role. I don’t think we talk enough about it is, product managers, focus on their area. Their area is the goals, their area is the customers, their area is the product, their areas, their own universe connect to the others, but not so much as connect to the other product managers.

I’m not saying the product team is a vertical, full-stack team. But the point is that modern products are not built in a way that’s done by one team. If you’re kind of not thinking across the portfolio, then there’s a big challenge in terms of, we call it org chart on your product, right? So, you can clearly see there are org charts of the product because there are different focuses by different areas, and that it’s become not acceptable in today’s world where it’s product-centric and user experience-centric and all that.

So, I think that part, I wish we heard more about because that’s sort of phase three at PayPal. It is really to go from enabling product teams to taking that best practice to the others. And then once we get to the second level, we realize we start to have this org chart focus, right? So the checkout teams, the focusing on conversion, and then the risk team focus on fraud. But conversions depend on fraud, fraud is affecting conversion. So who’s going to look at them together and then say, “Okay, we create the frameworks and the rules,” to help us as a portfolio to say, “Okay, you cannot dial up your rules on the risk and decline too many transactions so that you don’t for high-level conversion you overall lose revenue.”

Or you don’t want to relax it so much so that you have a lot of conversions, but the fraud coming through that has both an impact on our own business and impact on actual customers. So, the product ops is now really in the third level. They are now asking themselves how do we see across the portfolio? And then to say what really matters? What is not only our core areas of focus, what’s our pair of factors? And I think it’s interesting because I’m not sure. So, Marty Cagan’s book is about having empowered teams, your own goals, and then one of them is about that. You don’t own just one goal. You own multiple metrics, they’re actually competing. And obviously, he came from eBay, which is similar to PayPal.

And really, I think one of the customers, I was advising a while back right before… Well actually was the time I started Dragonboat was that we were going through a strategic planning process. And they’re saying, we have 300 items to prioritize. How do we prioritize them? What kind of prioritization and method should you use?

Chris Butler: Just delete all of them.

Becky Flint: Yeah, there you go. Go backwards. So, ultimately I have them turn around to say, “Hey, you know what? You really shouldn’t think about what problems are the most important. What’s affecting you.” Throw all these things out of the way, right? So talk about the problems, like what’s the organization, what are the problem you care about? Because it end up everyone at the executive and VPs and director level, all care about slightly different problems. So then we have to align the problems they care about the most. So, they pick the top five problems, right? The areas, and then we figure out how much you really care in terms of putting your money where your strategy is we, which is resources, right?

So then we kind of get, people to have a conversation. It’s become not chaos, not a lot of fighting. One of the higher levels in product operations really is to say, “when my team gets confused, what should we do?” Because there’s some solution that always works, but not at all scenarios or times. And this is really like, not that we set strategy as products. We don’t, but we help people to see and discuss, and to communicate strategy in a way that’s understood, that’s aligned, and that truly empowers your team. You say, these are five problems, help us to solve them. If you don’t say these are the five problems, nobody can agree on anything. It’s chaos so we fail. We fail. Chaos is the entity of the product, also. And when I say chaos, it’s more around misalignment chaos.

Chris Butler: Alignment is costly, right? I mean, I think that’s the thing. Alignment is always a high cost to every organization. I do want to focus in on one thing that I think is interesting. I’ve seen this discussion of like, how do we update the team and get them aligned around a strategy versus this idea of the actual creation of strategy. And I think that there are a lot of leaders that are not willing to make hard decisions out there. And so what they end up doing is not creating the strategy.

I do see some problems with product ops people being the ones that are like, “Well, we have to create the strategy,” when the reality is like, it is actually the leader’s job to do the strategy.

Becky Flint: Exactly.

Chris Butler: And actually every PM, every PM should do strategy. And so I think that you’re absolutely right. That it’s like, how do we communicate it? How do we get alignment? What is a process by which we discuss the right types of like arguments about the strategy?

Becky Flint: How do we make sure our strategy actually happens?

Chris Butler: Exactly.

Becky Flint: At the different levels, there are different level strategies. But then one of the first things, as you said, is that it’s hard to create a strategy. It’s hard to agree on what problem we try to focus on. And if we just delegate that to teams that say, “Okay, you guys say empower,” that’s bad. Right? So the goal of product ops, is not only you have to empower your team, enable your team. One of the key things is to make sure the strategic discussion and the uncomfortable discussion happen. And that’s sort of basically the responsibility for leaders. So, what we’re on focusing on, and what are the resources and organization power behind it? You can’t say, “We’re going to do these five things and you guys figure out how to make it done.”

No, we still have to have the conversation to say, “What does it take to do these five things?” What does it take? It’s never comfortable. I mean, obviously, PayPal is one of them. I think, even at Amazon, right? So, you have this initiative process where you have to figure out, where are the goals? What are the top five, 10, whatever areas to focus on, and what do they need to achieve this? Sometimes it is to get resources and roadmaps from the other team. It’s not a comfortable conversation, but if it doesn’t happen, you can’t achieve the goal.

Your team is not going to feel empowered if they need someone else’s resources to support them. They feel powerless. nd that’s our observation, is that a lot of organizations say you have an empowered team. You have scrum teams and whatnot. These are your goals, and the team doesn’t feel empowered.

Every day, they can’t make progress. Because I depend on different teams and none of them are on their priority list. About 10 years ago I was talking to one PM at one of the events and she was almost crying. She was saying, “What do I do? I couldn’t ship anything. My stakeholders want this, and I see our customer failing, but my roadmap item’s not being prioritized by the 16 teams I’m relying on. What do I do? I don’t want to do product managers anymore. It’s just too stressful.” That’s not what we want to happen. So, product ops need to observe that and understand that, really enable your PM to truly be empowered. That means difficult conversations sometimes with leaders, right? It’s not just setting a strategy. What do they have to achieve?

Bhaji Illuminati: And I think that leads to a couple of questions from the audience. So one came in from Shannon Boone. So, there are a lot of things for the product ops group to tackle. Where do you start, and what categories of things fall into the product ops classification?

Hugo Froes: I’m going to use that old term. It depends. It’s that simple because what happens is each organization you join, you’ll find something completely different, right? So, some organizations are really good at strategy building. Others are really good at user research. Others are really good at connecting the dots and reducing silos. The thing is, you have to get context.

So, I would say the first step is getting context, getting to understand, starting to identify, and that’s one of the things that’s funny. I just joined a new job, right? And one of the things I was doing was as I was having these intro calls, I would just take notes on a Miro board and throw down things I was noticing. And I was like, “Oh, I have to dig into this one. I have to understand that one.”

And you start painting this picture. Then you start seeing these patterns arising from there. And from there, you then have to look and say, “Okay, where can we go from here?” And then you have to start looking at what you have to look at. I also think it’s important to spotlight, and I get this from the book, Switch. I don’t know if anybody’s read it, by Dan and Chip Heath. And it’s great because the whole focus there is around doing changes, but focusing on spotlighting the good, right? So, you find these really great points of things working really well. And you grab that and say, “How can I scale that out?” Because what happens is, it’s not our responsibility. You can almost pass that responsibility onto that person who’s doing it well. And sometimes it’s about doing that, right?

And connecting people to people who are doing it well in the beginning, while you’re still getting that context and everything. Then as we go, obviously you start identifying these things, and then you start making these changes. And I think it was like Chris was saying, you’d make these changes, and then you have to see, what is the impact in the rest of the funnel? Focus on the rest of it, before you can go on to the next thing because if you do it too soon it’s going to become a mess. And so you have to see, “Hold on, did it affect them positively, negatively?” And then so you go back and then you start building these out and it’s iterative. So, we’re basically working on an internal product if you want to call with that. It’s continuously iterative.

Becky Flint: Exactly. I totally agree with you. It’s a discovery, right? So, you start with the discovery. What are the things that are good? What are the things that are burning? And what are things that need to be fixed? And then you have your product ops spec walk in terms of understanding, you do user research with all functions. Like, every organization is different. I totally agree with you. Some organizations have a programing function that’s doing really well. We pass these things for them because they own them. You have data analytics teams and they can go get it, just have them more plugged in. So product ops need to find out what’s working, what is not working, and where we need to improve on. And then you continue to iterate on things, and finding different results, and measure it.

Chris Butler: I think user research is really important. What I’m trying to think about is like, how do we get user researchers more involved in actual internal research? Because there, I think there’s a lot of value in that. But I think the idea of contextualizing it with your own work is one where Jared Spool constantly talks about how people shouldn’t make product decisions unless they spend at least three hours every six weeks with a customer. And so, I would argue that a product ops person, it probably is even more than that, right? Like, you should be talking to product people. If you don’t talk to a product person every day, you’re probably not doing your job as a product ops person.

So, I think that is most important, and really understanding where there’s pain is the part that is good. I mean, I like what you’re saying as far as the idea of Switch, right. Where you’re trying to highlight the things that are working. I think there’s something interesting about, do we go after the parts of pain where we’re trying to fix that, but we also are now amping up the things that are really great? I think that’s an interesting dichotomy that I haven’t thought about as much.

Bhaji Illuminati: So, we’ve had a couple of questions around resourcing and kind of team structure. Bill asked you can state that product ops should be a consideration for any company, regardless of size. How have you seen a pattern to when companies start creating the product ops discipline? And then I’m also going to throw in there one from Arthur around, what are some ways to determine when capacity, headcount, for example, needs to increase. So, is there a trigger of when to start? And then at what point do you expand and grow?

Chris Butler: I mean, one thing I would just say here is, I think this is related to the concept of just when we talk about resourcing, right? Like, it’s usually where our bet’s going to be, that we think is most valuable for us to focus on. So, I think product ops is always going to be, I think, understaffed based on the duty that it has to perform in some way, but it also makes us, I think in some way, scrappier, or will help us focus on smaller interventions that are more likely to be longer-term gains.

And so I think as a product ops person, you’re going to be overloaded with way too many things. And so, being very strict about how you prioritize is very important. I’ve found it really hard to actually delegate things as a product ops person, because I think for me as well, especially when it comes to enablement or opinions about certain types of training, I think I need to do personally a better job of delegating some of that stuff personally.

So, I think maybe that’s more my own issue, right? When it comes to the way I want these types of things to work. But I think it is valuable that if you embrace this idea of an experimentation mindset, adding more people that are willing to experiment in more cases is probably very valuable. The problem is, when does churn from an experimentation standpoint become overburdensome for your product organization? And so, I think that’s the counterbalance that we need to pull into this, is that I think product ops should be incredibly experiment-driven. But I think if you do too many of these things, people will feel like their organization is constantly changing out from underneath them.

It’s a really tough one. I definitely would love to hear what everybody else thinks too, but that’s the part that I’ve been struggling with is like, it’s okay to be overloaded because we just need to prioritize, I think is the way that I think about it.

Becky Flint: Yeah. I think definitely there are. Part of the job is very people and high touch, and then part of the job can totally be automated. And sometimes I’ve seen product ops people just become very administrative. They are making numbers and putting spreadsheets and putting slide decks, and those are not great. I have a couple of examples of the resources that people put in it. In one of the companies I work, I was helping them build the first product organization. Before I joined, there were no product managers, just engineers and professional services, project managers. And when we started building product organization, we started to have when you have four, five, six product managers, then almost 80/20 rule. 20% of the time starting to do things that can really be centralized, to be something more efficient and automated, or sanitized, and so on.

So at about the five PM level, we start to introduce the first product operations person, so that person can help to run various cadences to interact with the different teams, so that we make sure the whole product organization runs as internally well and across functionally well. But the funny thing is that we didn’t proportionally linearly increase from 10 people to have two products, but the whole rule about ops is all about the efficiency, right? And then you can see when the product organization gets bigger, your product ops to product manager ratio is still smaller. It’s not like adding one for every five people because that means the role is not efficiently run.

For example, if you say, “Hey product manager, onboarding and training coaching, that should go to you,” by the time you have 20 product managers, you probably have an HR organization and a learning organization, or some other partners to really outsource most of the data, and for use understanding where we are in term training, where the PMs, the feelings about that, and then you can derive programs being led by someone else.

So, it’s very interesting to see. There’s a somewhat of an interesting ratio, even at PayPal. That’s a big organization. I want to use PayPal because a bigger organization has a lot more data points to say over the years, what we’re seeing is that the ratio of PMs to product ops just gets bigger, more PMs and less number of product ops. In the end, we have like 300, 400 PMs, and then we have like five product ops, right?

Because there is a lot of other function taking on the roles and it’s better suited for that function, and that’s force modifiers, product ops, right? So I think that’s something I would’ve said, is if your product manager’s spending more than 20% of their time to do things that are consistent from team to team, that’s time product ops have to come in to see if something can be strategized, can be systemized. It can be taken away. If product ops do the same thing, if more than 20% of the time, if multiple product ops doing the same, then you say, “Okay, so we should find a system or tooling or another party that better to standardize that part, and componentize that business service API to somewhere else.”

Chris Butler: Maybe one thing I would just add here too, is I do think that having the product community, or community of practice does some of the standardization is also very valuable. So, when we talk about this, we’ve been experimenting with this idea of like a playbook, which allows for topic mobbing with regards to PM. So, I need help with road mapping, who is interested in talking about road mapping. Like I think if the product ops people are always the ones that are just answering that question, that’s not a community, right? That’s a power structure. So I don’t know. I think that’s the part that I also struggle with is, it should actually be the community that’s also building things for the community, but where is that line, I guess is a tough thing that we haven’t figured out yet.

Hugo Froes: Yeah. In my case, when we were at Farfetch, we found that the problem was, and that’s when the org starts getting really big, is that you have some that are working at the level of leadership, right? Of the product leadership. And then you have others that need to be at a product manager level, and you can’t be across both because you’re constantly jumping between, “Oh, this is tactical and this is high level.” And it gets very confusing. So, that’s when we felt the team needed to grow, but for example, the OutSystems team is a great example. What they did was they wanted to create a training program for the PMs. And they wanted to create this whole program to build up the capabilities of the product management team, and what they did was hire a person whose focus is that.

And so that’s the thing. Sometimes it’s around identifying people for key moments, or key things that need to be structured in there. But again, and like you’re saying, Becky, I agree. Our ratio tends to start widening as we go. But I think it’s also normal because ideally, if we’re doing our product work properly we should have fewer interventions, right?

The underlying infrastructure should be there. The baseline should be there. We should actually make ourselves redundant.

Hugo Froes: Which I like to say, we’re working to make ourselves redundant to a point, but it’s not an easy option because it depends on the team. It depends on the company. For example, sometimes you’re going to a company and design ops aren’t needed because the design teams do their ops really, really well, but the product team is terrible at it. Then you know you need product ops and vice versa. It all depends, there are teams that are doing it really, really well and they can squeeze us, get into the middle work, and then you’ll find that other teams who are just losing control, and they need someone to help them take control of things a bit. So it does take, you have to choose. You just have to choose which is the best option, I guess.

Becky Flint: Right. One of the things I want to add to it is we should also look at analogies. The thing that I found to be most similar is sales ops. And if you look at sales ops and product ops, they have similar ratios, the focus, and both are really evolving depending on the competencies, the system tool in place, and the needs of the organization. So, it’s always good to find similarities in a different realm and apply them to our current practice.

Bhaji Illuminati: Unfortunately, we’re at time. We have a number of questions that we didn’t get a chance to answer. We have all your names and contact info from your signing up, so we’ll follow up and we’ll answer those one to one. There were a number of requests on different resources, books, Slack communities. So, we’ll send that in the follow-up email. I’d love to hear from the speakers, just one last kind of tidbit as the topic was going into 2022. Any advice you have for product operations, kind of parting words?

Hugo Froes: Enjoy it. It’s probably one of the most challenging and fun things in the world because it is constantly learning, constantly challenging and you’re constantly evolving. It’s the type of thing where, what you learn today, even in this last two months of just joining a new company, I’ve rethought a whole bunch of things that I thought, “Oh no, I’m pretty comfortable with these things.” So, it’s always challenging your thought process the way you approach things, and the way to solve them. So yeah, that’s for me.

Chris Butler: For me, I think just finding the right communities to get help as well, either internally. If you’re in a very large organization, there are probably other product ops people, but also I think externally, I think is really valuable, just because I think learning from other people, this is one of those things where product managers need to be really great about figuring out which frameworks to use, or processes or techniques. I think product ops people need to be even more knowledgeable about that because we need to be able to work with the team to figure out what are the right ways to do things. And so, I’ve found that to be very valuable through community discussions, through the reading of community content, things like that. So to me, I think that’s something everybody should be doing if they’re not already.

Becky Flint: As product ops, I always ask myself through my career, “How do I make myself fire myself?” How to get myself out of this thing, whatever that is. When I can get myself out of this thing, I can get onto the other thing, that’s more impactful and better. So I think when we approach our roles to think about it, how do we replace my current self? That for you and for your organization.

Bhaji Illuminati: Wonderful. We should have scheduled more time for this great conversation. Great discussion between all of you. Thank you everybody, for joining. Thanks for the great questions, and to the panelists, thank you all for bringing your perspectives and insights.