Process People Continued

In my last article, I talked about how one worrisome trend I am seeing is so-called “process people” using the vehicle of product ops to penetrate an organization, and take an otherwise useful function in a less than useful direction.

The feedback I received was mainly people reporting that this is unfortunately very much what they have also witnessed, but there were also people that were confused by what I was trying to say.

Partly I think this was because I tried to cover too many different points in that one article, but partly it is because there are so many different definitions of “product ops” out there and people read the article from the perspective of their own definition.

I first started getting asked by companies about product ops roughly three years ago, and one of the things I quickly learned was that my definition was not the same as what many (in truth, most) of them were using.

So now when I’m asked about product ops, I start by asking them how they are defining the function at their company?

I have so far identified at least six distinctly different definitions of the product ops function.  And many companies have different combinations of these definitions. 

I don’t yet know if this taxonomy will prove to be useful or not.  I had hoped by now to see more consolidation of the definition.

I also only have anecdotal evidence, mainly from my, and my SVPG partners, discussions with more than a hundred companies, and from reading articles from a wide range of authors, so I only have a rough sense of most prevalent vs least prevalent.

One thing for sure is that the term is new enough and general enough that it is very easy for people to either inadvertently or intentionally define the role to suit their purposes.

My intention is to write more about these various definitions, and explain which ones I think can truly help an organization, and which ones are just old problems reappearing under a new name.

But in this article, I want to double-click on the specific overarching point I was trying to make in my earlier article.

Let’s put aside for a moment the issue of the many definitions out there, and instead look at just one of the more prevalent definitions, which is to have some number of people dedicated to improving the productivity and effectiveness of at least the product managers.

This would be around standardizing the tools, methods, practices, training, and onboarding of the product managers.

At smaller companies, this is normally squarely the responsibility of your manager(s) of product management.  It’s a good portion of what the managers are coaching their people on.  

But in larger companies, there is definitely an argument to be made that there are economies of scale to be had by consolidating this work.

Now, as you might imagine, this need is not a new revelation.  We have had large product organizations for more than 30 years.  And seeking more efficient and effective ways of solving problems is pretty much the core competency of good product people and product leaders.

Sometimes the managers of product managers would discuss this, and agree that one of them would take the lead on these responsibilities.  In fact, I was one of those people at two of the companies I worked for, which I doubt is a surprise to anyone.

But the most common way I have seen this addressed at strong companies is with a principal product manager (or other senior individual contributor product manager).

For those that haven’t heard of a principal product manager, it is generally the most senior individual contributor level for a product manager.  

These people usually have zero desire to become a people manager, but they deeply love the craft of product, and are motivated by taking on the toughest challenges on the most critically important product teams.

These people are also highly compensated, and while they may not manage people, they are usually well known in the company for their willingness and ability to help provide advice and coaching to less experienced product people.

So when the goal is to share the best practices of the best product people, these principal product managers would often be the obvious answer.  

You certainly wouldn’t ask your most junior product manager to do this, right?

Yet in so many companies that have been setting up this function, the people with this responsibility are not principal product managers, but rather Agile Coaches, or project or program managers.

Now it’s very important to emphasize that I know some absolutely excellent Agile Coaches, and especially those that are Discovery Coaches, and also excellent project/program managers, and your company would be very lucky to have these people no matter where they are in the organization.

But I’d encourage you to go ahead and look at the LinkedIn profiles of most people with the title “Agile Coach” and see how much actual first-hand relevant product experience you find.

This is the same reason I highlighted the problem of so many product managers being trained by Agile Coaches rather than experienced product leaders.

This is what I meant by “process people” trying to fill a product role.

So there are really two major dimensions to this discussion.  The first is how your company chooses to define product ops.  The second is who your company chooses to staff that function. 

This article is simply trying to ensure you have your best possible people setting the bar for the broader organization.