Short answer: Product operations is a set of functions — standardized artifacts, a shared source of product truth, repeatable process, and knowledge that transfers — not a job title. A small team of 3 to 10 PMs gets those functions from a shared PM Operating System running on Claude, not from a dedicated product ops hire. The Head of Product encodes the standard into shared context and skills once, and the whole team inherits it.
You have five PMs and no product ops function, and it's starting to show. The PRDs come in three different shapes. Half your product context lives in one senior PM's head, and you feel it every time she's on PTO. Each new hire reinvents the discovery process from scratch because nobody wrote down the team's version of it. When someone leaves, their knowledge walks out with them.
These are product ops problems. At a 200-PM org, a product operations team would own them — standardizing the artifacts, maintaining the source of truth, documenting the process, building the onboarding. But you have five PMs. You cannot justify a dedicated product ops hire, and the enterprise tools that bolt onto one assume an org ten times your size. So the functions go unowned, and the cost shows up as inconsistency, repeated work, and a Head of Product who spends review cycles cleaning up format instead of pressure-testing bets.
The fix isn't to hire product ops early. It's to get the functions product ops provides without the headcount — by moving them into a shared system every PM works from. That's product operations for small teams done right: tooling carries the standard, so a five-person team runs the ops functions of a much larger one.
Product Ops Functions: Hire vs. No System vs. Shared PM OS
Product ops isn't one thing. It's a bundle of functions, and you can ask of each one: who owns it, and how. Here's how the same four functions play out three ways.
| Product ops function | Big org (dedicated hire) | Small team without a system | Small team with a shared PM OS |
|---|---|---|---|
| Standardized artifacts | Ops owns templates, enforces format | Each PM has their own format; PRDs don't match | Same skills produce the same structure for everyone by default |
| Shared product context | Ops maintains a central knowledge base | Lives in people's heads; lost when they leave | Canonical context files every PM and skill reads from |
| Repeatable process | Ops documents and trains the playbook | Reinvented per PM, per project | Workflows chain the steps; the process is the tooling |
| Knowledge transfer / onboarding | Ops runs structured onboarding | New hire shadows whoever's free | New PM runs the same skills against shared context day one |
The middle column is where most growing teams live: the functions exist, but nobody owns them, so they happen inconsistently or not at all. The right column doesn't replicate the hire — it replicates the output of the hire through a shared layer of context and skills. That's the move that lets a small team punch above its headcount.
Product ops is a set of functions, not a hire. A small team buys the functions with tooling and the runway to grow before it buys the headcount.
Which Product Ops Functions You Actually Need (And Which Can Wait)
Not every product ops function is worth standing up at five PMs. Stand up the four that compound: standardized artifacts, shared context, repeatable process, and knowledge transfer. These are the ones whose absence taxes you every single week — inconsistent specs that slow engineering, context trapped in one head, process re-explained per hire, knowledge that doesn't survive turnover. They're also the four a shared system can carry without anyone owning them full-time.
What you can skip until you're bigger: the heavier ops apparatus that only pays off at scale. Tool administration and license management across dozens of seats. A dedicated insights or research-ops function. Portfolio-level resource allocation and capacity modeling. Formal release-management coordination across many squads. These are real product ops responsibilities, but they solve problems a 3-to-10-PM team doesn't have yet. Adding them early is overhead, not leverage. Build the four compounding functions now; let the rest wait until headcount actually forces the question.
How small teams run product ops without a dedicated hire
Here's the sequence that stands up the four core functions through a shared PM OS. Each step compounds on the one before it, so do them in order rather than all at once.
1. Write the shared context files as your single source of truth
Start with the source of truth product ops would otherwise maintain: your positioning, personas, competitive landscape, and current strategic priorities, in a few canonical files the whole team reads. This isn't a research project — it's pulling what already lives in your head (and your senior PM's head) into shared files. Run /welcome to draft them from your website in minutes, then spend an hour adding the internal knowledge that isn't public. This is the foundation every skill reads from, so it comes first.
2. Standardize the core artifacts through skills
Give every PM the same skills — one for PRDs, one for competitive profiles, one for roadmaps, one for status updates. When the whole team runs the same /prd-generator, every artifact comes out in the same shape automatically — built in, not policed. This is the standardized-artifacts function a product ops hire would enforce, except the skill carries the format and the framework every time, so no one has to remember either. The artifact clears the bar on the first draft instead of after your review.
3. Make process repeatable, not tribal
A process that lives in one PM's habits isn't a process — it's tribal knowledge that breaks the moment that PM is out. Move the steps into the tooling. When discovery, strategy, and spec work each run through the same skills and workflows, the sequence is the same regardless of who's running it. The repeatable-process function product ops would document becomes the tooling itself, so there's no playbook to read, remember, and re-apply — running the workflow is following the process.
4. Build knowledge transfer into onboarding and handoffs
Knowledge transfer is the function that hurts most when it's missing — every departure is a knowledge loss, every new hire a re-teaching cost. A shared PM OS makes it structural. A new PM opens the project, reads the same context files, and runs the same skills the team already uses, so they're producing to the standard in week one instead of shadowing whoever's free. Handoffs work the same way: because the work and the context live in shared files, picking up someone else's project means reading files, not reconstructing what they were thinking.
5. Keep context fresh so it doesn't rot
The fastest way a "standardized" team drifts apart is stale context. When a competitor ships, a persona shifts, or strategy moves, update the shared files once with /enhance-context, and every PM's next output reflects the change automatically. Run /knowledge-audit periodically to catch claims that have gone stale, and /team-health-check to read where the team is feeling friction. This is the maintenance function product ops would own — except it's about 30 minutes a month, not a full-time role, which is exactly why a small team can carry it.
The thread running through all five steps: you're not hiring the ops function, you're encoding it. The system owns the consistency; your PMs keep the judgment.
Related — how to standardize PM quality across a team goes deep on setting a quality floor without flattening judgment, and what a Team PM OS is defines the shared system these functions run on.
Start the Self-Serve Way
You don't need a hire or a project to begin. Start your PM OS, free for 14 days ($39/mo, cancel anytime), at pricing. Run /welcome once to generate your context files from your website, install the skills, and your team is running the core product ops functions — standardized artifacts, shared context, repeatable process — within the first week.
The status quo has a cost product ops would normally absorb: inconsistent artifacts, context trapped in heads, process reinvented per hire, and knowledge that leaves when people do. You don't fix that by hiring early or asking people to try harder. You fix it by moving the functions into a system the whole team shares. Rolling out to your team? See the Team rollout.
FAQ
What does product operations do?
Product operations standardizes and supports how a product team works: it owns templates and artifact consistency, maintains a shared source of product truth, documents repeatable process, and runs onboarding so knowledge transfers between people. At scale it's a dedicated team; at small scale it's a set of functions a shared system can carry. The point is the functions, not the title.
Do small teams need product ops?
Small teams need the functions product ops provides — consistent artifacts, shared context, repeatable process, knowledge transfer — but rarely need a dedicated product ops hire. A team of 3 to 10 PMs feels the pain of inconsistency and lost knowledge well before it can justify the headcount. The answer is to get those functions from shared tooling, which buys a long runway before a hire makes sense.
Can you do product ops without hiring for it?
Yes. The functions a product ops manager owns — standardized templates, a central source of truth, documented process, structured onboarding — can be encoded into a shared PM Operating System instead of a person. Every PM runs the same skills against the same context files, so the standard is built into the output rather than enforced by a role. The Head of Product sets the bar once; the system maintains it.
When should a team hire its first product ops manager?
The trigger is usually scale, not the existence of the problem. When you're past roughly 15 to 20 PMs, or coordinating many squads with portfolio-level resource and release management, a dedicated product ops hire starts to pay for itself. Below that, a shared PM OS covers the core functions far more cheaply — so most growing teams should stand up the tooling first and revisit the hire when headcount genuinely forces it.
About the Author
Ron Yang is the founder of mySecond — he builds and manages PM Operating Systems for product teams. Prior to mySecond, he led product at Aha! and is a product advisor to 25+ companies.