By Sara Estes, Pendo.io, Author of the Rise of Product Ops
As technology companies scale, silos emerge and processes can break down — creating the need for a dedicated function to drive alignment, communication, and efficiency across the company. We’ve already seen this play out with the emergence of plenty of other ops roles, and now, product has an operational force of its own.
In our latest e-book, we at Pendo looked into the rise of product ops, and tied its growth in popularity back to the evolution of the product experience. As companies become product led, their product becomes the vehicle for every stage of the customer experience — from trial and purchase all the way through onboarding, expansion, and referrals — and product ops is key to the optimization of that experience.
But once you’ve identified the need for product ops, how do you get the buy in to make it happen? Starting a new function is never easy, but what’s important to remember about product ops is that people throughout your company are probably already performing a lot of these responsibilities, which only helps validate your ask to formalize the role.
For a cross-functional role like product ops, it’s not only about convincing leadership for headcount and resources. It’s also crucial to express the value to stakeholders across the organization with whom product ops will partner closely. The following is a summary of some of the best advice I’ve heard in dozens of interviews with products ops leaders:
1. Explain the “why”
Think about why your organization needs product ops, and make sure you’re presenting that information as clearly as possible. Familiarize yourself with the core areas of the product ops role, and then align them to your company’s specific needs.
Create a deck that walks through why product ops is necessary, and, if it’s available, provide any data that helps support the ask. This could include time product managers waste on administrative tasks, products that didn’t launch on time, or even the number of times someone in the company asks for the same specific type of product information.
Also consider putting together a single definition of product ops, specifically as it relates to what the function will be responsible for at your company. Shelly La Rock, director of product operations at NAVEX Global, said it was extremely beneficial to define the purpose of product ops when she was first advocating for the function. Here is their definition:
At NAVEX, product ops is responsible for operationalizing product management processes, tools, and product strategy using metrics, infrastructure, business processes, best practices, and reporting that’s scalable, repeatable, and predictable.
2. Show (don’t just tell) the value
Start by writing the job description for the role you (or someone else in your company) will be taking on, to help paint the picture of what product ops will be doing on both a high and granular level. An effective way to create urgency around your request is to find a competitor (or multiple competitors) hiring for product ops, and include those job descriptions as well. You want to convey the idea that by not creating product ops, your company is falling behind.
In the end, it’s not just about explaining what you’ll bring to the table with product ops, but also how it relates to overall business objectives. If you can draw a connection between product ops’ future responsibilities and the company’s established goals, it will be hard to argue the value of creating this function.
3. Talk to your future customers
In addition to your company’s actual customers, product ops’ number one customer is the product management organization. And as much as you’ll be able to identify process gaps and observe workflow inefficiencies (especially if you’re a PM yourself), the best way to understand where product managers are feeling pain is by talking to them directly.
Shelly noted that as she started building out product ops at NAVEX, her first step was to survey product managers about their pain points. This is also helpful information to gather before product ops is launched, so you can better understand where the biggest needs are and build your plans of action from there.
4. Start small
With any request to create a new function, you don’t want to ask for too much, too soon. Think about this initial ask as a “minimum viable position” that will help you immediately start solving pain points and producing results.
Just because product ops may be a team of one at the beginning doesn’t mean you won’t be able to make an impact (this is when partnering with other teams becomes crucial). And once you get approval to launch product ops, it’s more of the same: start small by choosing a few key goals, measuring and reporting results to show the value, and building from there.
5. Establish clear goals
A lot of your work up until this point will be focused on looking backwards and examining the here and now to support the claim that product ops is necessary. But it’s also important to think ahead, and establish clear (and attainable) goals for this future product ops organization.
Not only does this help bolster the legitimacy of the role, but for a function as multifaceted as product ops, it’s beneficial to determine what success will look like, which will provide a guiding force as you get product ops off the ground.
Shelly emphasized the importance of a “wash, rinse, repeat” process: establish goals, track metrics, report findings, and iterate from there. This all starts with creating those initial goals — keeping in mind that they might shift as you go.
