When companies scale Product Managers often find themselves spending more time on cross-functional execution and coordination rather than time managing a product strategy or working with engineers on building. When I was a PM, I found this part of the job distracting and difficult to scale. As the complexity of the product portfolio grows (and as the size of the Product organization grows and the number of PMs doing these things increased), lots on inefficiency is created in the organization as stakeholders find themselves being bombarded with requests from different PMs for information requests and tasks. When this happens, it is time to create a product operations team.

Product operations is a sub-function of Product Management. It consists of the aspects of the product management role that sit outside the Scrum Product Manager role and the Scrum Product Owner role. These might include the following activities:

• Data gathering and analysis
• Collecting and synthesizing customer feedback
• Coordinating product launches
• Onboarding and managing partners
• Facilitating stakeholder reviews and getting alignment
• Coordinating with other PMs

Here are some examples of Product Operations job descriptions from some well known tech companies (Uber, Google, FB, Snap, etc). Though none of the roles are identical, there are some very common patterns and themes around data, metrics, product launches, partnerships, and coordination with business teams.

• 

• 

• 

• 

• 

• 

The best way I can think of to articulate the purpose of the role is: “bringing products to market and bringing market to product.” The video from Google below I feel is a pretty good explanation:

Where does Product Operations Belong in an Organization?

For companies with a simple portfolio / a single product, each PM should be doing their own Product Operations work for their own products. It’s not standardized and we rely on the initiative and drive of each individual PM to ship their products which is typical of most startups as they manage their “pod,” or team.

The challenge with this type of structure is that it doesn’t scale. When a startup decides to invest in a new product and funds a new PMs, Engineers, and marketers – they usually aren’t going to also hire additional lawyers, accountants, or other key functions like sales. You end up with a structure where the second product manager has to work through influence but doesn’t have the resourcing or expertise to actually be successful. Great PMs can overcome this deficit (since Product Management is all about influence), however this puts an unfair burden on the Product Manager and it causes exhaustion and burnout.

Continuing to scale this way eventually leads to situations where there isn’t alignment between all of the different functions in an organization and whoever is left has to beg, borrow, and steal for resources with their own fellow product managers for visibility, mindshare, and resourcing especially with shared corporate services like Legal & Finance, or any other team whose resourcing isn’t fully aligned with product and who may have a harder time understanding the complexity of technical products.

At this point, it makes sense to create a dedicated product operations function as a shared service to the rest of the Product Operations team. This way, the Product Operations Manager (typically a PM) can help prioritize the work coming in from the rest of the PM org as well as streamline the workflow and communications between PMs and other organizations.

I have seen the Product Ops role sit sometimes within the Product Management organization (as a shared service to other PMs), in the Program Management office, or in Marketing.  That structure looks like this:

Generally speaking, the complexity of the Product Portfolio is the biggest driver for how the function should operate and where it should be located since the more products that are in the portfolio, the more work is required to maintain the product catalog and keep it healthy and coordinate one product into the strategy being used by the other products.

At Verizon, I had dedicated program management team who interacted with the rest of the organization through a product development process process called StageGate.  This was a heavy process with lots of cross functional involvement centered on a 6-step checklist with a RACI matrix for each step.  This was very structured and detailed, but getting concurrence and involvement from every group for a single product generated lots of communications overhead which required a dedicated project manager for each product feature or enhancement. Having a dedicated project manager is a great luxury for the product manager but is not efficient for the overall organization.

In the end, there is no one size fits all for product operations. Although the complexity of the product catalog is a significant factor, there are a number of other factors such as the number of customers, number of sales reps, and number of partners that can also dictate the operating model of the team.

Product Commercialization

One of the key roles for Product Operations is Product Commercialization. This fills the “Bringing product to market” part of the Product Operations mission and includes all of the little details involved with bringing products to market. This is a part of Product Management that occurs after the product has been defined, but is before the Go To Market phase of the product launch.

The Commercialization function typically includes:

• Product/Service Descriptions – a written document that defines what product/service customers are getting, how they’re getting it, and very importantly what they are not getting.
• Customer Agreements / T&Cs – this outlines what customers’ responsibilities are and terms of use of the service. Some products require users to opt-in/accept the T&Cs
• Tax/Regulatory/Compliance policies – Different categories of products (software vs. services, for example) are taxed at different rates. Government regulations and Compliance policies also follow similar patterns
• Pricing and SKUs – Detailed listings of part numbers the customer can order including price, units, discounts, part numbers, and even bundles. This is an entire topic on its own.
• Partner Agreements and Contracts –If you are offering a capability from a third party, then sometimes there are specific carve outs for liability and responsibilities that the third party needs to pass through to your customers. More on partnerships in a later post.

Practically speaking, many product managers that I’ve worked with do not know how to actually complete these work activities, especially new product managers, PMs who came from B2C backgrounds, or PMs who are subject matter experts with rich domain knowledge but have limited product management functional knowledge. Most of these activities further involve working with different stakeholders than a typical PM would work with, such as Legal, Finance, Tax, and Accounting team members who often need very specific and direct guidance to do their jobs correctly. In these situations, it is helpful to have a dedicated product operations team who can help other PMs understand what is required and guide them through the commercialization process.

To help every PM on the team understand what they need to do, it’s really important to simplify the process so that it is easy to understand. I recommend the following 4 step process (assuming a dedicated Product Operations team):

1. Product Definition – the Product Manager takes the lead here to really define what the product should do and how customers will get it. The outcome of this process is typically a PRD that describes the product in detail.
2. Product Review and Refinement – this is where Product Operations can take the lead to review and socialize the PRD with different stakeholders and consolidate feedback for the PM, iterate, and repeat. When the PRD gets to a point where stakeholders are all in alignment and is complete, then we can progress to the next stage. In larger organizations, a formal review step is sometimes needed after this step before proceeding to make sure the organization is truly aligned.
3. Documentation – this is where Product Operations can facilitate document creation (customer agreements, service descriptions, price books, SKUs, and T&Cs) with the Legal and CRM teams to ensure that all the back office systems are loaded with the appropriate documents which have been pre-vetted in the Refinement stage
4. GTM – This is where Product Marketing can take the lead to build a Go to market plan, including training, events, messaging, PR, Media, and other marketing calendar deliverables. Typically this is managed by product marketing but if that function doesn’t exist it will fall into the Product Management / Product Ops scope

What I’ve found useful to manage this process is a simple Kanban framework that can help team members easily visualize where different products are in the commercialization process. This can also be reused for many other initiatives such as partnerships and EOLs that I will discuss later. I’ve created a sample board here that shows the different stages of the commercialization process below:

These Kanban boards can be easily integrated with your ChatOps to help provide an additional level of transparency to PMs and other stakeholders when products advance through the process:

Product Decomissioning (End of Life / End of Sale)

Another aspect of product operations is decommissioning products via End of Life (EOL) and End of Sale (EOS) processes. Though technically we are taking products out of the market, these activities are still very much like a product launch in that we are delivering documentation, training, planning, and careful cross-functional execution.

When I ran product operations, I created a standardized process for EOL programs that included the following activities:

• identification of underperforming/underutilized products and features
• inventory and analysis of contracts, revenues, usage, and pull through revenues associated with the products in question
• design of alternate solutions for customers who were using an EOL/EOS targeted product
• development of messaging plans, migration plans, and account plans
• physical decommissioning / removal of EOL products
• price book / catalog updates with appropriate failsafes
• training for internal and external stakeholders

Each of these steps must be managed carefully, with proper messaging and care. Check out this example from AWS which explains what they are doing, when they are doing it, why they are doing it, and what customers should do.

Based on this process, it’s easy to see how complex EOLs are (and how little revenue upside there is) but keeping your product line lean and mean is critical to help the teams focus on what matters as you grow your product portfolio and more and more distractions/feature requests/bugs come inbound to your teams.

Data Collection and Reporting

Another role of the Product Operations team is to bring market data and feedback to the product development process as part of a healthy feedback loop. This fills the “bringing market to product” mission of the product operations function. In my opinion, the primary deliverable here is a meaningful dashboard that summarizes the most important metrics of the company.

Like a product launch, Data and reporting can often be completed by the product manager, but once a company gets to a certain scale of products/customers, it makes more sense to have a dedicated team/person fill this role. There are some areas where this is obvious, such as a customer advisory board – you wouldn’t set up one for each product in your company. Activities associated with this aspect of the role include:

• Internal KPI reporting and dashboards
• customer surveys and CSAT tracking
• Customer Advisory Boards
• Managing a feature request pipeline from sales

As a PM, I’ve always had to hunt for specific data I need by reviewing financials, querying internal back office databases, scanning CRM and ticketing system text fields, talking to customers on a one-off basis, and creating up with my own dashboards manually. But time spent collecting data and aggregating it takes away from the time I could be spending analyzing data and coming up with ideas on how to achieve business goals and results.

Consolidation of this data across multiple products and disciplines is a key enabler for product managers to actually drive business results with the products that they build.

My inspiration for this is actually Keith Rabois’s (former COO of Square) lecture from Stanford’s CS183B Class How to Start a Startup.  In this video, Keith highlights the importance of having a dashboard with the most important metrics of the company and driving everyone at the company to use it to drive their decision making.

[optional] Partner Onboarding and Partner Management

Partnerships is another rich topic that I will spend a full post getting into. But as I showed in the earlier job description from Google, Product Operations is also often responsible for (as I was) selecting, integrating, and onboarding new partners as well as managing their ongoing success.

Conclusion

In conclusion, Product Operations is an often overlooked but essential part of the Product Management function. Though often not a dedicated or full time role, it is a key part of the grease that keeps the product management function working smoothly.