I keep seeing job postings for product ops and product leadership roles brimming with the word “process” in all the wrong places. I would like to put an end to this trend.

Read to learn more about Process (with a capital P) and when not to use it.

Process

I have a love-hate relationship with beef.

• It’s so versatile and tastes great when done right.
• It’s possibly one of the most environmentally costly source of protein for regular consumption (and cows are really cute).

I feel the same way about Process. When done right, processes can be beautiful efficiency machines. Rarely is it this way, and it turns into costly red tape for everyone.

What is a Process?

To begin, let’s define “Process” in its true form in an organization:

• Given a specific context,
• These are the specific steps we follow,
• So that we can get to this specific desired, consistent outcome.

This sounds like a recipe, a prescription, or a standard operating procedure. Useful for things that need to be repeated over and over again for consistent end results. This is great for manufacturing, or at a scale that requires consistency for downstream systems to consume, like revenue numbers across many accounts, or standardized reports across all of the unique locations for a large chain. If you have an efficient and well-documented Process, you’ve just saved many, many employees from a huge headache.

The Nuance

“But May, we need Processes for human workflows within our small organization!”

Of course! Let’s take a new Product Manager (PM) onboarding into an organization. Everyone within the same organization/ geography gets the same corporate onboarding artifacts to make sure you cover all of the standard bases (contract, NDAs, laptop, key fobs, etc). You can scale this to 1, 10, or 1000 people and it likely won’t change much except on the people ops team side. Since this is contained within a single team, the people ops team can make changed to the process as needed, and it’s generally easy to do with minimal approvals required. Hallmarks of an ideal process.

Now that this PM is hired, let’s focus on product team onboarding. Let’s say your team is super organized and you have a training program.

1. Meet the people 
    - On the product team
    - In your working group (development, UX, etc)
    - Go-to-market counterparts
    - Other leaders
2. Corporate standardized training — messaging, company context, etc
3. Past recordings that are useful for context building 
    - previous townhalls, strategy discussions, etc
4. Get access to tools
5. Get trained on your product

Easy! We have a process.

But, it’s not a process. For every new person, you update 1, 3, 4 for relevance to that person’s role. You might drop bits of corporate training that aren’t applicable to their business line. #5 is developed individually by the manager and the PM. Who owns this process and how does it get updated, especially after that manager has made its own version of it?

Imagine if you say tell the larger team that this is now the Onboarding Process. Some managers will hand this as is to their new staff. Some will customize it until it’s unrecognizable. The outcomes are vastly different. A Process intends to take away creativity and force a standardized way of doing things. There are many times where you don’t want this level of standardization. This is one such case.

This is a framework, or better yet, a guideline given to managers to make things a little easier for them to remember things when they have to onboard a new person. You don’t enforce this structure. There’s no accountability attached to whether, when, or how this is used. It cannot be a Process.

Cost of Process

The word Process is heavy with intention.

A Process intends to take away creativity and force a standardized way of doing things.

The actual problem with Process is not implementing one, but in change control. It’s generally quite easy to establish and implement a process, especially compared to changing a deeply entrenched one. In order to change a process, you must:

• Obtain buy-in from all teams involved to make changes,
• Plan the actual change,
• Get buy in from the change proposal all over again,
• Retrain everyone,
• Enforce changes.

If you just instituted a new process and it is broken, change is going to be more costly because you just used up a lot of trust with the first implementation.

In an organization, you are surrounded by change: natural employee churn, organizational restructuring. Processes don’t have the capacity to change quickly. The more critical your process, the heavier the cost of change, but also the more expensive it is to stagnate. Stagnation also gets more expensive as time goes on. I've seen it get bad enough that you may have teams of people whose jobs are dedicated to working around all of the Process.

The Process Checklist

At a previous company, I was implementing my first framework and I was worried that this was going to be the first of many things that turn into the jumble red tape that I’ve experienced at previous mega corporations. I needed a way to make sure that what I’m doing made sense, so I took the time to think about the impact of processes and this checklist was the end result.

• People always come before processes.
• Smaller modular processes are better than big processes.
• Processes are meant to be living ideas.
• Processes facilitate recurring activities across multiple groups.
• We continually question the validity and effectiveness of processes.
• Obsolete processes can and must be removed.

Let’s stop the problem before it starts. Before you implement a Process, does it fit all of these criteria? How hard is it to change? Who needs to buy in? Be extremely explicit about the owners and change rules.

If Not Process, Then What?

It’s really important to ask yourself why people believe that the process needs to exist in the first place.

• We need a bit more structure → How about some guidelines or establishing ways of working? Can individual groups of people working together establish how they want to work together? At what level does this need to be explicitly defined?
• People aren’t talking to each other → Sounds like a much, much deeper systemic culture and ways of working issue.
• We need official check-ins for our current scale → A tiny process around specifically the check-in would be great, since it meets the above criteria.

In my professional experience, when you talk to people about blockers, they’ll tell you about problems, many of which lead back to underlying systemic issues. If you find these and address them, many of the issues tend to resolve themselves.

What can we do about it?

1. Stop using the word “Process” where any level of creativity is needed. Guidelines, suggestions, or ways of working are much better alternatives to empower your teams to take charge of the situation.
2. The desire for Process often stems from a deep underlying systemic issue. Find those issues before you try to solve for it. What is the actual problem you’re trying to solve?
3. Process is a tool. It’s okay to use it. Sometimes, Process is the only way through if you can’t get the organization to agree, but once again, we’ve hit the systemic issue of an unaligned organization. Do what you must, but be upfront about the risks and long term costs.

Processes are like beef: easy to work with and super flexible until cooked, addictive, fully entrenched in our society, quite costly in the grand scheme of things. The goal is to moo-ve the organization forward. Let’s make the Process work for us to get to a better functioning organization.

Drop some feedback in the comments or message me if you want to chat further!