Product Ops, the missing piece in your product organization

Like me, you're probably hearing more and more about Product Ops. Is this just a coincidence? No, it's a deeper issue, and one that's set to continue for some years to come. Indeed, Product Ops is the role that's been missing to accompany the rise of Product Management by bringing more framework to organizations at scale. Is it relevant to your context? I'll give you the keys to thinking about it in this article.

🤔 My definition of Product Ops

Before getting to the heart of the matter, I'd like to share with you my definition of the role of Product Ops, as there is no single definition.

Some say he's the Product Manager (PM) of the Product organization. The analogy is strong and powerful. Like a PM, he manages a backlog of improvements certainly, but I can't completely agree with this definition because an important element is missing: Product Ops goes further and makes the changes himself.

To find out more: download our framework les 4P du Product Ops

As a result, I prefer John Cutler's definition: "Product Ops solves problems for product teams that single teams and individuals cannot solve". It shows several key elements:

• Product Ops works on the organization and not on a team or an individual, as a coach does, for example.
• Product Ops not only recommends a change, but also implements it and monitors its progress over time.

💪 The 3 advantages of having Product Ops

As with any new role in the digital world, it's tempting to think that it's only for ultra-mature Silicon Valley contexts. However, it's a fact that more and more organizations have Product Ops. But why are we talking more about it today? I've identified three major factors that are driving Product Ops forward, summarized in the decision tree below.

#1: Product Ops brings alignment and consistency to large organisations

In my opinion, the size of the organization is the most important criterion for determining whether or not the need for Product Ops is relevant.

If the company is still of reasonable size (1 or even 2 levels of management), alignment needs can still be managed by the current organization.

On the other hand, when the number of people in the organization is significant, there is a need for standardization and governance, particularly in the following areas:

• Processes and tools to capitalize on each other's best practices and facilitate inter-team alignment and synchronization.
• Job descriptions and career paths.
• Dashboards to facilitate inter-team comparisons and strategy steering (especially OKRs, if already in place).
• Consistency of roadmaps in terms of content (alignment with strategy) and form to make them easier to read for all stakeholders.
• Management of user and market insights, which are becoming increasingly numerous.

#2 : Product Ops facilitates team growth

Between reasonably-sized and large organizations, there is a whole range of organizations for which the question of having a Product Ops may legitimately arise.

For these, one of the major factors to take into account is the organization's planned growth, mainly in the following areas:

• Defining job descriptions to ensure that the right profiles are recruited, a major challenge.
• Structuring onboarding paths, which will be more and more numerous.
• Convergence of processes and tools to avoid having to do this work with more people aligned and a significant history.

Preparing for the future and supporting growth is the reason for being of Product Ops in fast-growing organizations.

#3: Product Ops leads to greater product maturity

If we go back a few years, the two main priorities of many French product organizations were :

• Manage fast and efficient delivery at team level
• Handle cross-team development dependencies.

From then on, Agile coaches and the Head of Product (or any other management role on the Product side) were sufficient to address these issues.

The average maturity level has now evolved enormously. With a few rare exceptions, Agility is no longer an issue. PMs want contexts in which they can flourish, like those sold to us by Marty Cagan with "empowered teams" or Teresa Torres with her "Continuous Discovery".

The current challenges revolve around the ability to have a rapid impact on users and to measure this impact, drawing on sub-topics such as OKRs, discovery, the consistency of roadmaps in relation to a common strategy, the monitoring of KPIs and the centralisation of insights.

It's hardly surprising, then, to see Alexandre Serrurier, Lead Product Ops at ManoMano, declare recently in an interview for Productinbox that "Integrating this role [Product Ops] into the organization enables a Product team to reach a new level of maturity for two reasons: firstly, the role will respond mechanically to issues, and secondly, it's a strong message - 'we want to improve' - sent by leadership." I couldn't agree more.

These three issues explain why Product Ops are popular in scale-ups such as Alma, ManoMano or PayFit (now growing and reaching significant size), and also why we're seeing them emerge in large groups such as Decathlon or Carrefour (significant size and evolving maturity).

🤝 Without Product Ops, responsibility becomes everyone's business... or nobody's!

Many organizations have not (yet) made the shift to Product Ops.

There are many good reasons for this:

• Insufficient team size and growth (as in the case of startups).
• The desire to limit the number of people involved in the organization, and to give responsibility to those already working on these issues.
• The maturity of the organization does not justify the presence of product specialists.

Unfortunately, also many bad ones:

• Lack of knowledge of the role.
• The desire of some to maintain their perimeter.

Without Product Ops, the burden of dealing with systemic pain points is carried by others in the organization, to the detriment of their other responsibilities. But who are they?

The most obvious: The Head of Product

Why does the Head of Product - or any other management role you might find in a Product organization - seem the most obvious person to take on these responsibilities? Carrying a cross-team vision, it is the default choice, especially in start-ups and scale-ups. It has to be said that it has several arguments to its advantage:

• He is often the most experienced.
• He has hierarchical responsibility for developing the Product Managers.
• He has a strong interest in ensuring that the Product process runs smoothly and efficiently, to get the most out of his teams and make sure that the people he manages feel good.

The Head of Product can take on the majority of Product Ops subjects, but if priorities have to be set, he will more naturally take on those linked to management (job descriptions and career paths) and strategy (steering and roadmaps).

He can also be consulted on more operational subjects such as processes and tools, but as he is not the first to be impacted, it's more appropriate for other people to take charge.

Unfortunately, his time is limited, with a strong focus on Product strategy and alignment with other company departments. He can't carry all the responsibilities of Product Ops on his own. What's more, over time and depending on the number of people being managed, this situation is not viable for doing it properly.

Also, if there are several Heads of Product, make sure that there is alignment between the practices, tools and job descriptions of all the Product teams.

The more charitable: Product Managers themselves

Product Managers are the first to be affected by faulty processes, and when faced with this, they can feel like saviors. This situation also has the advantage of making PMs accountable for the efficiency of the Product Process. This argument is the reason why Backmarket and Blablacar, for example, have made the conscious choice not to have Product Ops. This is an honorable choice, but it requires mature teams willing to tackle these issues for the good of the whole organization.

Compared to the scope of a Product Ops, PMs will mainly focus on what impacts them the most, and therefore everything that touches on the operational side: processes, tooling and dependency management.

This type of organization can be seen as an opportunity for a PM to evolve towards the position of Head of Product, since he'll be touching on cross-team issues and potentially certain issues such as strategy or HR that are not within his current scope.

The intention is laudable, but there are two major risks: the first is the implementation of solutions biased by the sole consideration of a PM's needs; the other is to see no one take hold of a subject in a global way and find a workaround solution within their own perimeter.

The closest: Coaches

A coach has the same mission as an Ops: to improve the organization. The approaches, however, are different:

• The Coach works on individuals and teams, provoking change.
• Ops will work on the organization, with the main concern of scaling up, by driving change (after consultation, of course).

The difference is subtle, I grant you, and so it's only natural that many of today's Product Ops are former coaches. The posture changes. And so does the time frame: Product Ops is a long-term project, whereas coaches generally arrive to provide temporary help to get a project through to the next stage.

But when we talk about coaches in France, we mainly think of Agile coaches. Can an Agile coach be a good Product Ops coach? Regarding soft skills in coaching and change management, yes without hesitation. As for hard skills in product development, it's possible, but not an absolute truth. It mainly depends on their appetite to go beyond delivery.

The worst solution: Nobody!

Of course, not having a Product Ops person simplifies the organization by removing one person, but this situation can only be envisaged if two conditions are met:

• The first condition is that it is part of the job description and that time is allocated to it.
• The second is that people feel motivated and capable of addressing these cross-functional issues.

Without these two conditions, you run a high risk of having an organization that continues to live with its problems and without harmonized practices.

In short, all the responsibilities of a Product Ops can be covered by the organization's current roles, but in my opinion it's not worth the effort, and it's only a default solution. Yes, teams will be more aware of cross-functional processes. But the price is too high, with teams losing focus and people not necessarily trained in change management.

🔮 What future for Product Ops?

If, like me, you're now convinced that Product Ops has real added value, it's time to consider its future with one central question: "Will all Product organizations get on board?". Here are my 2023 predictions.

#1: Startups will continue to live as they are, without Product Ops. Inter-team alignments will still be manageable by PMs and the Head of Product, with potentially a Product coach as occasional backup.

#2: Scale-ups will continue to invest in these roles to support their growth. Those without Product Ops will become as rare as a four-leaf clover (but that won't bring good luck...).

#3: Large groups will be the new playground for Product Ops as Product Ops clusters emerge, integrating, in addition to Product Ops, on a partial basis, certain other profiles in specific areas (HR, Finance and Tech). This is what Decathlon is currently doing with its "Product Office". Little by little, Agile centres will be replaced by divisions to support product transformations.

#4: More and more senior PMs will be projecting themselves into Product Ops careers to support these growing needs.

#5: Thiga will be releasing a Product Ops framework to help understand what this role is, its scope and expected skills 😉

To learn more: download our book Product Oriented organizations