What follows is an article I have rewritten for various teams over and over again for the last 4 years to help them understand Product Operations. I hope it helps you as it has them! The most recent iteration borrows heavily from the recent Product Operations book by Melissa Perri.
Product Ops is basically a product manager of the Product Team.
Product Operations is the art of removing obstacles from Product Team members so that they can make efficient, evidence-based decisions. It’s important to note that Product Operations is an enablement function, not a service function; maturing Product Teams to do and be better, not off-loading tasks from them. It should aid in the Product Team's efficiency, empowerment, momentum, health, and maturity. This function often focuses on the connective tissue between various teams, influencing strategy, processes, leadership, systems, and overall workflow.
As outlined in Melissa Perri's great book, I agree that a well-functioning Product Operations team has three key pillars. It usually focuses on one at a time.
| 1 Data and insights | 2 Customer and market insights | 3 Process and governance |
|---|
Product Operations is often a multifaceted subject, touching various teams and residing in their collaborative spaces. While operational efficiency might not be imperative for scaling a business, retrofitting it later proves challenging. Success in operational initiatives hinges on high alignment, especially at team intersections. Humility is key in driving operational improvements. However, it's essential to note that operational work is opinionated despite being framed with terms like communication and collaboration.
“... standardizing best practices sounds good in theory, but if not based on judgment and experience, it can lead to imposing one way of doing things on different teams where that way often does not make much sense.” – Marty Cagan
| What it is | What it is not |
|---|---|
| The approach is adaptable, with the name implying a preference for product-led organizations. Product Operations characteristics - Nurtures - Attentive - Growth-oriented - Teaching - Enabling - Empowering - Engaging - Collaborative - Communicative Seeks and provides clarity - Supportive - Humble - Honest - Matures - Aligns - Drives efficiency - Purpose-driven - Seeks outcomes - Objective - Empathetic | Product Operations should not be a pretext for imposing arbitrary tools, processes, or fleeting trends. Incorrect characteristics - Dictatorial - Seeks submission - Operates on gut feeling - Coercive - Controlling - Arbitrary - Immutable - Unadaptable - Seeks outputs over outcomes - Subjective - Siloed - Fearful - Defensive - Stonewalling - Merely talk - The 5 Dysfunctions of a Team (absence of trust, fear of conflict, lack of commitment, avoidance of accountability, inattention to results) - Apathetic |
The crux of Product Operations lies in organically fostering improved collaboration, communication, and clarity without stifling creativity or imposing excessive conformity. Newcomers challenging established processes should be championed, fostering a culture where questioning is encouraged. Careful, balanced nudges should drive change without overwhelming teams. Allowing teams time to adapt is crucial, and nudges should be offered only where readiness aligns.
Product Operations, as the name implies, is a function that centers on product-related operational efficiency. Sure, a good product overlaps and collaborates with many other functions. Recognizing this overlap is crucial. Collaboration among operational professionals, such as Dev Ops, Rev Ops, and Project Management Offices (PMO), is encouraged. Depending on the organization, Product Operations may include other functional areas, such as product analytics or design operations. The organization's structure and needs determine this.
In a couple of organizations that had lower operational maturity in key areas or across the board, operations professionals like myself banded together to create our own community of practice. Even if we were Product Ops, Dev Ops, and PMO, with very little overlap in mandate at the time, we found ways to support each other and drive maturity and efficiency in the organization as a whole. If you have trouble getting leadership buy-in or support, I strongly recommend this grassroots approach so you can all build momentum and buy-in together as you navigate the flow of communication, collaboration, and coordination in the business and its interplay with organizational hierarchy.
Success criteria for a Product Operations team or function should focus on measurable outcomes that demonstrate how the team is enabling efficiency, alignment, and impact across the product organization, but within your function's sphere of control. We can't force people to do things, but we can inspire them, coach, support, and enable them.
Like any product function, success will also depend on the current focus and goals. If your focus and goals are misaligned with the folks you're trying to help then you'll likely see resistance or failure. The more collaborative and aligned your focus and goals are with those you're trying to affect and help, the better.
Meant as examples only, not prescriptive.
Industry figures like Marty Cagan oppose dedicated process roles, emphasizing the need to experience and understand problems. Effective operational professionals are those who "live the pain." This means that despite their primary focus on operations, they engage in related work, like product management or design, at a reduced capacity. This firsthand experience accelerates issue identification, builds empathy, fosters trust, and enhances communication, collaboration, and clarity.
Does this mean dedicated roles for Product Operations shouldn't exist? Not necessarily. Folks like Marty Cagan are filling in the Product Operations roles when they consult about Product Teams, after all, so I think we must be careful with heavy opinions. I believe the answer to if you need a dedicated role versus shared responsibilities among existing team members entirely depends on the culture, existing operating model, and team capacity.
Dedicated roles can be beneficial, particularly in organizations grappling with operational inefficiencies. However, intentional exposure and balance are crucial. For teams considering an operations role, adding a senior professional, like a product manager or designer, and gradually introducing them to operations can be effective. As per Marty Cagan's insights, this approach also applies to strategist and process roles. I believe the difference is that dedicated Product Operations people should actively try to work themselves out of a job.
Team members reacting passively and stating, "That's not my job," would be immature. On the other end, proactive, enabled, and empowered team members consistently contribute to their pursued outcomes and actively enhance the team itself. Regarding Product Operations, they are considered mature. Ideally, operations become a collective responsibility in a mature team where members support each other. However, some individuals may lack understanding, capacity, or the autonomy to address operations. To address this, teams often start with specialists and gradually move the entire team along the maturity curve.
Having trouble jumping into operations work? One of the best methods I have found is to adopt the design thinking cycle. Here’s a quick recap from NNGroup.
Adopting design thinking and the product team as our subject, we can explore operational efficiency by empathizing, diagnosing, ideating, experimenting, and finally implementing solutions. Try not to overthink it.
Specifically Product-related
Overlapping with Product