So, You’ve Decided to Do Product Operations

Somewhere right now, a very confident person is explaining to a room full of other people that what their organization really needs is better processes. The room is nodding. Someone has even opened a Notion page, and a random consultant may be involved. Everyone in that room, including the confident person, is thinking about something entirely different when they hear the word “process,” which is how you end up six months later with 3k Google docs, three new project management tools, and the exact same problems you started with, now wearing small hats made of documentation.

This is the normal state of affairs. I want you to know that upfront.

Everything You Know About Operations Is a Polite Lie

The working definition of operations, in most organizations, goes something like this: operations is the function that makes things run smoothly, reduces friction, helps the team work more efficiently, and generally makes everyone’s lives a little easier.

This definition is wrong in a way that is almost beautiful in its wrongness, because it is so precisely wrong that it describes the opposite of what operations actually does when it’s working.

Operations is not place to make things easier, and this is a great way to sell it to people if you don’t want to do the messy work of being honest. Operations is in the business of making things reliable, which sounds like the same thing until you’ve actually tried to build reliability into an organization, at which point you discover very quickly that reliability and ease are not just different concepts but are frequently enemies who have been nursing a quiet grudge for years.

Making things reliable means adding steps. It means requiring approvals that slow things down. It means enforcing standards that feel, to the people being held to them, approximately as pleasant as a firm handshake from someone whose grip philosophy differs significantly from your own. It means that the person who used to handle something by feel, intuitively, drawing on years of experience and a kind of professional sixth sense, now has to follow a defined sequence of steps instead, which, yes, takes longer, and yes, makes them grumpy, and no, this does not mean you are doing operations wrong.

A process that makes a skilled person’s life easier while quietly tethering the organization’s success to that specific skilled person’s continued presence, good health, and willingness to show up is not a process. It’s a dependency with a Confluence page attached to it.

The goal, the actual goal, not the one that fits on a job description, is outcomes that do not depend on which specific human shows up that day. That’s it. That’s the whole thing. Everything else is commentary.

I’m glad we could admit that and we made it this far.

The Word “Process” and Why Nobody Knows What It Means

Here is a fun game you can play at work, assuming your definition of fun accommodates a certain ambient sadness. Ask five different people in your organization to define what a process is. Not to name a process. To define the concept.

What you will get, if your organization is like most organizations, is a tour of things that are adjacent to processes but are not processes, delivered with the confidence of people who have never been asked this question before and are experiencing something in the neighborhood of an existential wobble. The average professional will recite something half-remembered from a LinkedIn carousel or simply invent a position entirely and state it like they are ratifying a constitution, because both options are faster than thinking and produce roughly the same social outcome.

You will also get checklists. For clarification, a checklist is a memory aid: a tool you use so you don’t forget to do the thing you already know how to do. Surgeons use them. Pilots use them. They are valuable and good. They are not processes.

You will get workflow diagrams, which are representations of processes, usually aspirational ones, meaning they describe what the organization would like to believe happens rather than what actually happens, which is a different and more interesting story. An organization can have exquisite workflow diagrams and absolutely catastrophic actual workflows, and many do, and they have won awards for the diagrams.

You will get “how we do things around here,” which is culture, or habit, or accumulated institutional behavior, or some load-bearing combination of all three. It may look like a process from a distance. Up close it is mostly vibes.

A process, in the sense that matters for operations, is a defined sequence of steps with clear inputs, clear outputs, defined decision criteria, and assigned accountability constructed in such a way that a competent person following it faithfully would produce the same result as any other competent person following it faithfully, without needing to call the person who invented it to ask what they meant by step four.

That last part is the test. If the process works because Janet knows what “use good judgment here” means and Janet has been with the company for eleven years and has absorbed by osmosis a very particular understanding of what counts as good judgment in this organization, then you don’t have a process.

You have Janet.

And Janet will retire someday, or get poached, or simply have a period of her life that requires her attention to be elsewhere, and the process will retire with her.

You can document Janet’s judgment, and lots of organizations do this. They interview Janet, they watch Janet work, they write down everything Janet says about how she makes decisions, and at the end they have a very thorough document about Janet that is largely incomprehensible to anyone who is not also Janet. A real process replaces the need for judgment with criteria, at every step where that’s possible, and defines the judgment required at every step where it isn’t.

The Part Everyone Skips, Which Is Why Everything Goes Wrong

I want to tell you about something that gets left out of most operations conversations because it is uncomfortable and makes people defensive.

Processes require authority.

Not the authority to design a process - anyone with a whiteboard and two free hours can design a process, and many people do, which is part of the problem. The authority to enforce it. The authority to look at someone who has gone around the process, or ignored the process, or “adapted” the process in the moment because it seemed more efficient and they are a person who values their own efficiency quite highly and say, clearly and without apology: no. That is not how this works here.

This is where the “making everyone’s lives easier” philosophy of operations collapses entirely, because processes enforced with authority make some people’s lives harder on purpose, by design, as a feature and not a bug. They create friction for the person who wants to do things their own way. They create accountability for the person who would prefer not to be accountable. They require communication from the person who finds communication inefficient.

Operations without authority is just a series of suggestions and most organizations are absolutely buried in suggestions. There is no shortage of improvement ideas, the ideas are doing fine, the ideas do not need your help.

The authority problem takes a few common forms, and sometimes the ops function is positioned as a service organization, which means it exists to support the people doing the “real” work, which means it has no actual standing to hold those people to anything, which means the processes are whatever people feel like doing that day with some light documentation attached (if that). Sometimes the authority technically exists but nobody uses it, because the enforcement conversations are awkward and the ops leader has decided, consciously or not, that being liked matters more than being effective. Sometimes the authority exists and is applied, but inconsistently; meaning, the rules apply to the teams who don’t push back and not to the ones who do, which is arguably worse than no rules at all, because at least no rules is a coherent position.

Where operations sits in the organization, who it reports to, what it can actually do when a process is violated are the structural questions that matter more than almost anything about the content of the processes themselves. A perfect process with no authority behind it is a very nice document. A rough process enforced consistently is an organization that functions.

Individual Skill is Not Organizational Capability (and Confusing Them is Expensive)…

Organizations have a persistent tendency to mistake what their best people can do for what the organization can reliably produce, and this confusion is the source of a great deal of expensive pain.

Individual skill is what a person can do. Organizational capability is what the organization produces consistently, regardless of which people are involved on any given day. These two things are related, for example you can’t build organizational capability without skilled people, but they are not the same thing, and the distance between them is exactly where operations lives.

An organization full of talented, capable people with no coherent processes is actually quite fragile, in the specific way that things are fragile when their continued function depends on a set of conditions that cannot be guaranteed. It performs brilliantly when the right people are present, aligned, motivated, and not being recruited by a competitor. It fails in predictable ways: onboarding takes months because there’s nothing to onboard to, just a loose collection of things the current people know; quality varies because it tracks individual mood and circumstance rather than any defined standard; growth is painful because you can’t replicate skilled intuition the way you can replicate a defined sequence of steps.

The confusion runs in both directions, and both directions are bad. Organizations that mistake individual skill for organizational capability invest in hiring instead of systems and are perpetually confused about why more headcount doesn’t solve their problems. Organizations that mistake process compliance for organizational capability end up with mediocre people faithfully executing mediocre processes and calling it operational maturity, which is its own kind of tragedy.

The thing you want is skilled people operating within authoritative processes, where the process defines the floor and the people define the ceiling, and the floor is high enough that even a bad week doesn’t produce catastrophic outcomes. But the floor has to exist, and exist independently of any particular person, before any of the rest of this works.

And Now, the Part about AI, Which You were Waiting for…

Let me tell you something that is not popular at conferences or in LinkedIn posts, where the content is optimized for a kind of frictionless enthusiasm that has become the rhetorical equivalent of smooth jazz.

If your processes are not solid, AI will make your problems worse faster.

It will do this very efficiently. This is one of the things AI is genuinely good at.

Here is what AI is actually excellent at, in the operational context: taking individual skill and expanding its surface area. A skilled analyst with good AI tooling can do work in an hour that used to take a week. A competent writer with AI assistance produces more, faster. A capable operator with AI-powered tooling can monitor, synthesize, and act on information at a scale that was previously impossible for one person to manage.

Every one of those examples requires the skill to exist first. AI amplifies what’s already there and it makes skilled people more skilled, productive people more productive, capable people more capable. It does this very well, and the productivity gains are real, and none of this is the problem.

The problem is when organizations try to use AI as a substitute for the process definition work they haven’t done.

It goes like this: instead of doing the uncomfortable work of actually defining their processes (the inputs, the outputs, the decision criteria, the accountabilities, the conversation about what “good” actually means here) they build a sophisticated AI system that approximates what good judgment looks like in their domain. They train it on their best people’s work. They prompt it with their principles. They deploy it and tell themselves this is their process now.

What they actually have is an AI system that has inherited all the problems of the undefined processes it was built on top of, plus some new ones that are harder to see. When it produces bad output (and it will, because every system produces bad output sometimes) there is no authoritative baseline to compare it against, because the process doesn’t exist in any explicit form. You are debugging it against expert opinion and collective vibes, which means you are right back where you started, except now there’s also an AI involved.

Real process definition is a forcing function for organizational honesty. When you sit down and try to write out every decision point in a workflow (actually write them out, with criteria, not just labels and Claude skills) you discover that half of them don’t have defined criteria and have been running on someone’s accumulated expertise that has never been made explicit. That discovery is uncomfortable, but it is also the beginning of the actual work.

AI can help with that work. It can help surface patterns in historical decisions, generate draft documentation for expert review, flag inconsistencies across teams. These are legitimate and useful applications. But AI can’t make the organizational decision about what the standard should be. It can’t enforce the standard once that decision is made. It can’t hold anyone accountable for deviation.

Those remain human responsibilities, stubbornly, as they have always been, regardless of how impressive the tools become.

What You Get When You Actually Build It

When you have authoritative processes (genuinely defined, genuinely enforced) the relationship to AI transforms entirely.

You can automate the low-judgment steps with confidence, because you know exactly what those steps are and what good output looks like. You can use AI to monitor compliance, because you have something to monitor against. You can use AI to identify where things are breaking down, because you have a clear enough definition of “not broken” to recognize its absence. You can use AI at the decision points that require skilled judgment, because those decision points are defined, and the information relevant to them is known, and the people exercising the judgment understand the context.

Skilled people, operating within authoritative processes, with good AI tools, can do things that would have seemed implausible a few years ago. The process provides the floor, and the people provide the judgment. The AI expands the range of what both can accomplish.

That is the actual promise. Not a shortcut past the foundational work, but a force multiplier on top of it.

A Brief Note on Thanklessness

Operations, done properly, is among the most thankless functions that exists in organizational life, which is saying something because organizational life has produced a remarkable diversity of thankless functions.

When it works, nobody notices and things simply happen. Customers are served with consistency, new people come up to speed in a reasonable timeframe, quality doesn’t depend on who’s having a good week, and leadership can make plans with some reasonable confidence they’ll be executed. This all happens quietly, invisibly, the way good infrastructure always does, because the thing that good infrastructure produces is an absence of drama, and absence of drama is not the kind of thing that generates celebration or career advancement or the warm glow of recognition.

When it fails, everyone has opinions. The opinions are almost always about symptoms (we need better people, better tools, better communication, better leadership) without quite reaching the diagnosis, which is that the organization has been running on individual skill and accumulated habit and is discovering, in real time and at some cost, the difference between that and actual capability.

The work of operations is building something that functions when the circumstances aren’t favorable. For example, when the best people are having difficult periods, when growth has outrun the talent pipeline, when the tools change and the team turns over and the market does whatever it decides to do next.

You build the process first. You make it authoritative. You do the uncomfortable enforcement work. You have the conversation about what “good” actually means in your specific context, with your specific constraints, producing your specific outputs.

Then, and only then, you let AI make it extraordinary.

The first step is writing down what should happen, for one workflow, end to end, and seeing whether the people involved can agree on whether that description is accurate. Not what they aspire to do, but what they actually do.

That conversation is where it starts.