In practice
Say you are three people with 40 customers. Someone has to keep feedback in one place, agree which numbers count, write down how a release goes out, and make sure a new hire can find things. That is product operations, whether or not anyone owns the name.
It isn't product management, which decides what to build and why. It isn't project management, which tracks delivery dates. And it isn't product marketing, which handles demand and positioning. Product ops builds the system those roles work inside.
Larger companies hire a dedicated product operations manager. Pragmatic Institute's rule of thumb runs the other way: if product managers are still doing the product management, product marketing and operations work themselves, you probably haven't grown to the point of needing a separate role.
How to do it with a small team
- List the chores that repeat every week: collecting feedback, updating the roadmap, writing release notes, pulling the same numbers.
- Put customer feedback in one place, with who said it and their exact words.
- Agree on the few numbers the team uses, and where each one comes from.
- Write the release routine down, so it doesn't live in one head.
- Every quarter, drop the process nobody used.
Common mistakes
- Hiring the role before the chores are written down. Nobody can tell what the hire is meant to take on.
- Building process for its own sake. If a step doesn't help someone decide or ship, it's overhead.
- Letting product ops quietly start deciding priorities. It supports the decision; the person responsible makes it.
Why it matters for product builders
The work exists whether or not anyone owns it. Left unowned, it shows up as feedback scattered across tools, numbers that nobody trusts and decisions nobody wrote down. Everything gets slower, and you find out weeks later.
Three questions are a fair test: are decision-makers spending more time on admin than on deciding, do experiments feel out of control, and do you doubt the data behind your decisions? Two yeses mean the system needs attention, with or without a hire.
What changes in AI-first products
Agents take over a real share of the mechanical work: summarizing calls, tagging feedback, drafting release notes, keeping docs current. Little changed about who must own the system around them. Someone still decides which sources count, which numbers to trust and what gets written down.
What did change is the number of readers. With Claude Code, Cursor, Codex or Grok each building from what they are told, the same facts need to reach every one of them, not just the person who read the thread. Founders running two or more agents are already doing product ops, usually by hand.
See how Annsa does it: Feedback →