Becky Asch, Head of Product Operations at FullStory, gave this talk at the Chief Product Officer Summit.

Hi everyone. I'm Becky, and I lead product operations at FullStory. For those of you who don't know FullStory, we're a digital experience intelligence platform. We combine product analytics, session replay, and real-time insights to help you identify opportunities for your user experiences on the web and mobile.

Product operations is a very nascent discipline. There are very few tenured product operations teams that exist. This means that we all have the opportunity to mold and shape what this discipline looks like to make sure it's the biggest force multiplier for our product teams. 

Product operations as I see it is a product manager for the product lifecycle. There are a lot of folks who’ve weighed in on the right remit or the right scope for product operations. 

What I'm going to focus on today is:

When is the right time to start a product operations team?

In terms of scope and remit, product operations focuses on the hotspots across the product lifecycle at your company. 

For example, if your product team is struggling with getting closer to and compressing the distance between your product managers and your customers and getting real-time feedback from customers, that's something that product operations could help focus on and really unlock. 

There are also interlocks with the go-to-market team and making sure that everybody at the company is well-equipped to bring to market new product offerings that your team is building. 

I really believe there’s such a thing as too early, too late, and just the right time to start a product operations team. So, let's talk about what that looks like in pursuit of what I'm calling ‘the Goldilocks moment.’ 

On the too-early side of the spectrum, a former coworker of mine reached out to me a couple of weeks ago. He wanted to chat about building out his product team. He’d started a company a few months before, and he was looking to hire a product team beyond his co-founding engineer, one product manager, and a couple of contracted developers. 

We talked about the right structure for his team and what a good hiring profile should look like. Then he asked me, “When should I hire a product operations manager? Should I do it now? I want to lay the foundation as early as possible for a highly effective, productive product team. 

It's definitely forward-thinking, but I advised him against it. Why? Because in order to thrive and add value, product operations needs something to fix, to build off of, and optimize. There has to be a product culture and a DNA to adapt to, pain points to address, and systems and processes that are being outgrown. 

If you don't have a product team that has stormed and formed and armed and then experienced some growing pains as the team and company scale, then the time is too early to start a product operations team, in my opinion. 

On the too-early or too-late side of the spectrum, too late is definitely the more sinister one because it's much harder to bounce back from. 

I've spoken to a lot of folks in the product operations space who were hired to build a product operations team and they weren't set up for success. It was too late for them to truly be effective. 

It was striking to me how many of their stories were similar in terms of the kinds of patterns and pain points that companies faced, up to the point where they decided to start a product operations team, and I'd love to dig into what those patterns looked like. 

Prior to starting a product operations team, these companies scaled pretty significantly over a six to 12-month period. They nearly doubled the size of their customer-facing teams, sales, and CX. They added a handful of PMs and designers and probably more than a handful of engineers. 

Over that same period, you started to see a couple of patterns emerge. 

First and foremost, the touchpoints and the channels of collaboration between product and go-to-market teams or customer-facing teams started to break down. Product couldn’t run their bi-weekly meetings with sales and CX to get feedback, keep that interlock, and share roadmap updates. 

The meetings became unstructured and there were so many new people it was hard to know who should even be in the meeting. So those started to fall off. 

Sales and CX had trouble figuring out how to submit product feedback. They didn't know where to submit it and it went into a black box. 

On the flip side, product managers, folks in UX, and engineers didn't know how to handle the feedback coming out at them from 10 different channels. As a result, the trust and goodwill started to deteriorate between product teams and customer-facing teams. 

At the same time, internally, product team members who may have managed processes on behalf of the product team had just stepped up and started to manage processes on behalf of the team, and they started to get overwhelmed. They were saying, “There are so many new people. I need to focus on my day job.” They started to grow a little bit resentful. 

New PMs, designers, and engineers who started in this hiring process lacked guidance on the product development process. They started to feel lost, and product leaders started to notice a difference in performance between the old guard and the new. It wasn't due to lack of experience or skill, it was because there was ineffective onboarding and ramping of these folks. 

These issues became loud enough and troubling enough that product leaders decided they needed to hire a product operations team to address it. So they went to the market, they posted a role, and it took three months, give or take. 

In that time, they were telling sales and CX, “Don't worry, this product ops person is going to start and they'll solve everything. 

Product team members were saying, “We'll fix that later; this product ops person is going to join.” 

So, this product ops person joined, and the cultural issues at that point just ran so deep and the expectations were so high that they weren't set up to be super effective in their role. It was too little too late. 

But if we rewind a few months, we can find that Goldilocks moment. So let's talk about the signals that indicate that the time is just right to start a product operations team. 

Your company is preparing for scale when rates and retention are high, your pipeline is healthy, and your company is planning to significantly grow your sales and CX teams. You're also going to see some decent growth on the product team as well. 

You notice your product team starting to come up with these hacky, quick-fix solutions to things that probably won't scale and maybe don't address the root cause of the issue. 

You start to hear the team saying things like, “We need a process for that,” or, “This should really be documented somewhere.” 

Product folks that we talked about who’d been managing those processes on behalf of the product team started dropping the ball in favor of their day job work. They started feeling overwhelmed and maybe a little resentful about having to juggle all the things on behalf of the team. 

And by the way, those same folks are very important folks to retain. Often, they have a high sense of ownership and high agency. They're the ones you're going to lean on to help onboard and ramp new team members, so it’s important to make sure they're not feeling overwhelmed. 

The product team starts to have less visibility into what their fellow product team members are working on. Maybe some dependency management issues start to crop up, or opportunities for collaboration are missed.

There are a handful of releases that go-to-market teams feel a little caught off guard about. Not a big deal, but just things like, “Where did this release come from? Why didn't I know about it?” 

This is exactly the right time to start a product operations team. 

You're preparing for scale, and growing pains on the product team have just started to rear their head enough that folks will have a vision for what this ops person can come in and do. They have ideas for how they can add value. 

Cracks in the interlocks between product teams and go-to-market teams have just started to form, but it hasn't yet sown resentment, distrust, or dysfunction. So product ops can come in, roll up their sleeves, address the pain points that do exist, build credibility across the company, and then help you and the team prepare for the scale and change that you're about to go through. 

What is product operations?
With an ever-increasing amount of content and conversation around the emerging product ops function, we wanted to create the perfect space to take a deep dive into the position and explore the role and responsibilities of product ops, the key skills, the evolution of the function, and more.
Product-Led Alliance | Product-Led GrowthAdam Bennett

Building a stellar product ops team: Success signals and critical attributes

So, you've made the decision and you're going to build this product operations team. What are some of the critical attributes that you should be looking for in this team? What are some signals to indicate the team is successful? What's important to consider when making those first few hires? And what are some anti-patterns to keep an eye out for?

These are four attributes that I believe are critical attributes for an effective product operations team. This isn’t an exhaustive list. These are things that I think are underdog attributes. They're often overlooked, undervalued, and maybe even a little controversial. But I believe they're really important. 

So, let's dig into each of these. 

The first one is to focus on culture. By nature, product operations introduces change within and across teams, so we have to be laser-focused on elevating and preserving the best parts of a team's culture and also helping to ease the transition out of those that are toxic or ineffective, or that the company has outgrown. 

As you're building out the team, look for folks who have a deep interest in the product team specifically. Maybe they’re asking about company culture in the interview, but they're also asking about the product team culture and the product lifecycle. And when they're asking those questions, they're digging in, and they're picking up what you put down when you answer. 

They're really effective in change management, they're effective at influencing without authority, and they have very high EQ. These are really critical traits. 

Some important signals of success is a product operations team that examines and celebrates the most effective parts of a product team culture, rather than just over-indexing on what's broken. 

Maybe they elevate examples of really effective UX research, or examples of teams that deprioritize things and aren’t producing results, and therefore we shouldn't keep investing in them, or teams that are really stellar at communication with go-to-market teams ahead of a release. 

They build trust quickly, they have regular one-on-ones with folks to keep their finger on the pulse of the team, and they're able to anticipate patterns in what's not working. And then they navigate and address those things in a way that brings folks along for the journey, helps introduce that change, and doesn't assign blame. 

Someone in my team is in the room, so I'm going to embarrass him with a recent example of something he worked on because I think it really illustrates this point. 

We were introducing a new prioritization and planning process, and it was a really big departure from the status quo of how our product team prioritized and planned. We started to socialize it and we noticed eyes rolling into the back of heads. Who wants to sit through a 45-minute process overview? I don't personally. 

So, he caught on to the fact that eyes were glazing over, and he realized we needed a captive audience to make sure that folks were bought in on the ‘why’ and on the vision. Who cares about the details right now? 

Being the creative, light-hearted person that he is, he turned this process into a dinosaur comic. He wanted to paint a picture of the vision that we were aiming to achieve. 

He recorded an audiobook, he posted it as a teaser for this process overview, and the product team ate it up. They literally binge-watched it, as measured by the number of custom dino Slack emojis that were created that week. It was great. 

An anti-pattern to keep an eye on here is folks that don't keep in mind at all times the cultural impact of the change that they're introducing. In solving one problem, they unintentionally create another. 

They don't understand fundamentally what motivates PMs, designers, and engineers. They standardize above all else without regard for the nuances of teams and pillars and how fast or slow they need to move. 

They stick to their guns about a new tool or process, even when it's not producing the right results, which leads me to the next point to look out for - recognizing there’s more to operations than process. 

A great solution to the wrong problem is still a bad solution. In product operations, we often lean on process as a silver bullet or as our default response to everything. In many cases, the root of the issue isn't a process issue at all. Maybe it's communications or a skills gap. It could be role ambiguity, people dynamics, resource issues, you name it. 

Let's be clear about what we're solving before we jump to process as the solution. 

So, when you're interviewing for this role, get into some hypotheticals. Talk about a real pain point that you're facing, and observe if they’re really digging in to diagnose the problem. Do they crave context in the bigger picture? And are they considering alternatives besides process to solve the issue? 

An indicator of success here is your product operations team servicing issues that aren’t process-related at all. Maybe they noticed that there's greater role clarity needed for cross-functional teams ahead of product launches. So they bring those teams together and facilitate a workshop focused on role clarity for those teams. 

Or maybe there's a big strategic initiative and they realize there's been a communications gap with the team that's executing, and they raise that to you so that you can provide the context that the team needs to help execute. 

An anti-pattern is introducing process for something that one or two people have brought up, or introducing a bunch of processes piecemeal that they haven't thought through how they work together. 

I'm not anti-process, but I have worked for the government before, and I'm painfully aware of the consequences of process for process sake on culture and productivity. And I really believe that product operations as a discipline could benefit from a more critical eye toward process as a whole.

Prioritizing the hotspots may sound obvious, but rather than product operations having a specific remit or a specific scope in the product world, they should prioritize the unique hotspots that that company is facing, and the parts of the product lifecycle that are broken at that company. 

What does this mean in practice? It means that product ops team remits will look different and should look different at every company. I hope and expect that my team is focused on something very different a year from now than we are today. And that should change as strategy shifts, as org structures change, and as the company scales. 

I've seen folks spend a lot of calories focusing on problems that don't exist or the wrong problems, and that's often from preconceived notions about what was broken at a past company that they're bringing in. 

In terms of hiring, to me, this means indexing a lot more on the approach and the mindset of the candidate versus the hard skills and experience that someone might have. 

So instead of just hiring for somebody who started a voice of the customer program at a past company because you want a VoC program at your company, focus on thinking about how they’re going to evolve as problem spaces rear their head in our product lifecycle a year or two years from now. 

Product thinking vs. project thinking: The key to effective product ops

This leads me to my last point - product, not just project thinking.

If you don't follow Shreyas Doshi, you should because he’s a fantastic voice in product thought leadership. He’s described the difference between product and project thinking in this way. 

Project thinking is centered around understanding expectations, formulating plans, marshaling resources, and coordinating actions. They ask questions like, “What's the scope of this project? When does it need to be finished? How will we do it? When will we do it? Who will do it?” 

Where project thinking is focused on output, product thinking is focused on outcomes. Rather than centering on the logistics of getting a project done, product thinking is about understanding motivations, devising solutions, simulating the effects of those solutions, and then choosing the best course of action. 

This should be really familiar to everybody from a PM role standpoint. 

Product thinking involves questions like, what problem are we solving? Why is it important? What are our goals? And what else could happen? 

Both project and product thinking are really important attributes of a product ops team. But it's especially critical that your first few hires have a really healthy mix of both. 

The nature of our role means that product operations is often in the middle of healthy tension between the PM, UX, and engineering, or between product and go-to-market teams. So, if you hire a team of project thinkers, you're going to get a lot of output that doesn't necessarily get to the core of the problems you're trying to solve or the reason that you hired for this role.

“Sales asked for X, so I delivered X,” or, “Engineering asked for Y, so I delivered Y.” The focus on execution above all else, rooted in potentially competing requests, won't produce the outcomes that you're looking for. You really need that product thinking to have confidence that the team is zeroing in on the problem, keeping their eye on the prize, and that they can evolve as the company evolves. 

That’s the vision that I have for product operations. It's the potential I see for product operations to be a right-hand person to product leadership, to help shepherd through and weather significant change, to ensure the product team is constantly growing and improving, and that they remain resilient, productive, competitive, and fulfilled.