How exactly would you launch product ops in your org? What about that first hire? What are the metrics that matter for prod ops teams? And what problems should you tackle first?

The role has emerged into a critical function, helping product management orgs to scale effectively. But when it comes to launching it successfully, you probably have some questions like the above and more, right?

Well, Gerisha Nadaraju, former Product Ops Lead and current Head of Biz Ops at Dojo, has got you covered!

Gerisha was the Product Ops Lead at Truelayer and ended up creating a whole new product operations function for the business. And you can delve into the details of her talk from the Product Ops Summit as part of our State of Prod Ops report. You can also watch the whole thing on demand by grabbing yourself a membership plan to unlock an unlimited library of PLG insights.

In the meantime though, our PLA community were hungry for more knowledge and fired over some Q’s to Gerisha after the talk. And here, we’ve got some of the best questions and answers.

You can also continue the conversation on our Slack community, and keep up with all the latest updates, events, articles and more. Now, let’s get to those Q’s...

Q: Why have you said that problem solving is a key skill for the first time hire?

A: If I think about any operations person, the first thing I think about is that they need to be problem solvers.

Your motivation needs to come from solving problems, because that is effectively what you will be doing in any operations type role. And so for me, that was really important for the first hire. Especially if you're in a fast growing startup, you know that there's literally more problems than you have time to solve. You have to pick your fires. And so getting someone who's hands on and enjoys solving problems was key.

Q: What is the key strategy you might implement for eliminating silos as product ops?

A: I think that eliminating silos is exactly what product operations is trying to do. One way you can try do this, which is what I focused on with my team, was to scale product knowledge. We wanted to take whatever was sitting in one team and scale that across the whole org, and figure out a way to make it really transparent.

And the other thing we tried to do is, even though product operations were embedded in each team, we came together as one function, to share knowledge, and think about how we could bring consistency to all the different product teams that we were individually in. And so I think that's another way of trying to encourage teams to think together, as opposed to just going off and doing things on their own.

Q: Can a product manager wear a duel hat as a product ops person?

A: I think the first hire that I had into the team, was a brilliantly minded product person and I think she was a perfect example of somebody who could actually do both.

She enjoyed doing the product management style work and was able to run with that, while also having a really great sense of operations and problem solving. Thinking about problems, not just short term, but long term, so she could flex into the process side of things.

There can be so much overlap in the role depending on how you structure it or which product team it fits in, so yes, you can definitely do both.

Q: What are the best success metrics for a product ops team?

A: It depends on what problem you're trying to tackle as a product ops team, but a simple thing you could look at when thinking about driving efficiency is reducing the time taken. So if you're trying to do a particular process, you need to get a sense of how long this usually takes the team. Then you could measure if you’ve reduced that as a process because of stuff that you've implemented.

A lot of what we're doing is related to strengthening feedback loops with internal stakeholders, improving the communication and satisfaction that they're getting. Maybe there were communication issues between product and a particular team before, so another metric measure could be doing an initial survey of that team to find out the level of satisfaction before you implement something, and then maybe a quarter or two quarters afterwards to see if there's been an improvement.

If you were trying to implement something that facilitates knowledge sharing, you could go back and look to see if the slack requests, for example, that are coming through to you for this type of stuff are decreasing. That's an easy way of sense checking if what you're doing is helping.

If you’re in an embedded structure and your product ops team is there to help make sure the overall product team is shipping products, fast and on time. Then an obvious one is to track if all the teams are shipping their products fast and on time because the work that you're doing feeds into that.

Q: Does the product ops team, or does the product ops manager need to be technical?

A: It depends what problems the product ops team is trying to solve. This is something I looked at initially when I was on a hybrid Product Ops team called Catalyst and we were considering whether to hire someone technical with an engineering background onto the team. The work required for the problem we were trying to solve was technical in nature. I think in that scenario, you will need technical skills.

And something I've also seen or heard about is that a centralized product ops team might be set up to have people who each have very specific skills. So maybe someone is more customer focused and another person is more technical, and another person is into content and they have specialist skills that they use to do product ops across the org.

So I'd say in that scenario, yes. And I think if you're working embedded in a product team, then obviously you've got to get a baseline level of technical understanding of how the product works as it relates to your product ops job, which might require some upskilling.

Q: What were some of the problems that you first chose to tackle when starting the product ops function to show some of those quick wins?

A: I'm not going to go into too much detail of exactly what the team was working on. What helped a lot though, is that when I was identifying the initial problems to solve, I started by asking the individual product teams what their pain points were. We had a very clear idea, at least on the global expansion team, what were three key areas that the product ops team needed to focus on to add value.

These were things that actually didn't quite fit neatly in place for a product manager or an engineer to be looking at. So for example, we knew we needed to do things around communication. We knew we had to do things around improving the testing process and we knew we had to do things around creating a centralized database of information. Also being embedded, we knew that we were specifically trying to help launch markets. So you knew that was your overall goal.

So at least for us, we had the priorities of what we needed to be doing. And so we could start executing on it. Then as you're going along and showing these quick wins, people will start asking you for stuff. So suddenly, it's a case of, can you do this? Can you do that? And actually, you'll start saying yes, and yes, and yes to so many things, because you know nobody else is doing it. It's a new function. And you do want to show that you can add value. That is actually a learning point where maybe, I would say, you probably need to start saying no to stuff. If you're realizing that you don't have capacity to do it.

Q: When you have a very lean product ops team, what do you recommend as the best way to increase the velocity or throughput of the team without hiring more product ops managers?

A: If you're working at the centralized product org level, potentially you don't need to add in tonnes of people to have a high impact. If you're reporting into the CPO, one of the quickest wins you can do to show impact and value and maybe velocity, is to work on the stuff that matters most to this person from a product org perspective. So pick the most high impact things that are hugely problematic for your business, and focus your attention on them.

Usually it has to do with enabling the business or the product team to scale, if you unlock that, you've immediately created velocity, because you've solved a problem that is going to help this team go ten times faster. Try to figure this out by speaking to leadership, e.g. a CEO, or a CTO or key internal stakeholder, to try and bring some focus to any high impact type of work.

Q: What would you do differently if you were to launch product drops again?

A: So a key learning for me is that I embedded myself as a product operations analyst in a product team for far too long.

We were pushing hard and there were deadlines, real deadlines that needed to get done. And so I embedded myself as a product operations person in one of those teams initially for the first month or so before we made the first hire. And that team was a really important team because it was pushing out to our first country. It's high pressure, and you've got to learn for the first time and do it, which was great, because I got to understand the pain points and frustrations that my team would feel before they came in.

I kind of knew what to hire for, but it wasn't good, because I didn't replace myself in that team until the third hire that we made. And so I ended up juggling the job of being a full time product ops analyst embedded in a product team as well as leading a team and hiring and scaling a new function for quite a few months. That kind of means that you’re just spread so thin, that you can't focus on the actual lead stuff that you want to be doing and the strategy to take this team further. So try not to do that as a Product Ops Lead - given that the function is new, it will require your full attention as a manager versus an individual contributor. That's what I would do differently.

Gerisha is also the host of the Product Ops Podcast, where you can listen to diverse voices across this emerging function, who bring unique perspectives and actionable insights. Tune into all the available episodes right here.