पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 23 · Scale
Product ops and when to hire the second product manager
Past twenty people the product slows not because anyone works less but because every decision waits for the same person. Measure the wait, cut the overhead with product operations, then split ownership.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
At ten people a product company decides fast because everyone can hear every decision. At twenty-five the same company feels slower and nobody can say why: engineers are busy, the founder is busy, and features take twice as long. Usually the answer is that every product decision now waits in one queue, and the person at the front of it spends half the week on work that is not deciding.
This lesson treats decision speed as something to measure and design. It explains why it falls as teams grow, what the first product manager actually does, what product operations is and is not, how to see the queue in numbers, a worked example from Gurugram, how to split ownership when the second product manager arrives, and a monthly audit.
Why decision speed falls as the team grows
Two effects compound. The first is arithmetic: the number of pairs of people who might need to coordinate is n × (n − 1) ÷ 2, so ten people have 45 pairs and twenty-five have 300. Most of those pairs never speak, but every new person adds a little to everyone’s load. The second is a queue. Each engineer and designer needs a few product calls a week: which edge case matters, whether this customer’s request fits, what to cut to ship on Thursday. If one person answers them all, the wait for an answer stays short while that person has slack and then grows very fast as their week fills. That is how a team that was fine at eighteen becomes slow at twenty-two.
Amazon’s answer to the first effect is the two-pizza team: no team should be larger than two pizzas can feed, ideally fewer than ten people, and each has single-threaded ownership of a product, service or customer segment across its whole life. The answer to the second is to give each of those teams its own source of product decisions and to keep that source’s week free for deciding.
What the first product manager actually does
In most Indian startups the founder is the first product manager, and the first hired product manager inherits a job that has grown by accretion. List what fills the week and it usually falls into two piles. Deciding: talking to users, choosing what to build, writing the [short spec](/library/product-spec-engineers-want-to-read), answering the engineers’ questions, accepting or rejecting what shipped. Supporting the decision: pulling numbers from three tools, building the weekly report, chasing feedback from sales and support into one place, writing release notes, setting up the experimentation tool, running the planning meeting.
The second pile is real work and someone must do it. But it scales with the size of the company, not the number of decisions, and it is the first thing that crowds the deciding out. A product manager who spends 40 per cent of the week on it has 24 hours for the decisions of a whole team.
What product operations is, and what it is not
Melissa Perri, who later wrote a book on the function, describes product operations as the art of removing obstacles from evidence-based decision making. She cites a survey by Alpha in which 46.8 per cent of product decision makers named lack of quality data as their main challenge, and only 21.9 per cent always or almost always used data to back decisions. In practice the function that fixes it owns the data and reporting the product team relies on, gathers customer and market input into one place, and runs the processes and tools the team uses.
GitLab, which publishes its operating handbook, gives a concrete picture. Its product operations page ties the function’s work to the monthly release cycle, schedules release notes between the 23rd and the 30th of each month so they stay clear of release week, and tracks its work on a public issue board. That is the shape at small scale: one person who owns the rhythm, the numbers and the tools so the product managers do not.
What it is not: a layer of approval, a project manager who chases engineers for dates, or a substitute for product managers who will not look at data themselves. If the product managers stop reading the numbers once someone else produces them, the function has made decisions slower, not faster.
The arithmetic of a product manager’s week
The figure treats product decisions as a queue. Set the size of the team, how many product calls each person needs a week, how long a call takes to make well, and how much of the product manager’s week is lost to overhead. It returns the share of deciding time already spoken for and the typical wait for an answer.
At the defaults, 22 engineers and designers each needing one and a half calls a week of three quarters of an hour, one product manager with 40 per cent overhead: demand exceeds capacity and the wait grows without limit, which is what the team experiences as everything being slow. Cut overhead to 20 per cent, the job product operations exists to do, and the same product manager is about three-quarters loaded with a wait of under half a day. Add a second product manager instead and the wait falls further. Push the team to 35 and even the lower overhead runs out. The order of moves is the lesson: cut overhead first because it is cheaper and faster, then split ownership when the team is large enough that one person cannot hold the queue.
A product team slows down not when people work less but when every decision waits for the same person. Measure the wait before you feel it.
A worked example: logistics software in Gurugram
A Gurugram company sells route planning and proof-of-delivery software to regional transporters. It has 24 engineers and designers, a founder who still sets direction, and one product manager hired a year ago. Releases have slowed from weekly to fortnightly. A two-week log of questions shows engineers raising 38 product questions a week, with a median wait of a day and a half for an answer, and nine of them still open at the end of each week.
The product manager’s own log shows 17 hours a week on overhead: a Monday report built by hand from three tools, feedback from eleven salespeople arriving on WhatsApp and needing to be retyped, release notes in two languages, and admin on the analytics tool. The company hires a product operations analyst from its own support team, who automates the report, sets up one form for sales feedback and takes over release notes. Overhead falls to six hours. The median wait falls to half a day.
Six months later the team is 34 and the wait is climbing again. The second product manager is hired with a defined territory: the driver app and its metric, the share of deliveries with a completed proof of delivery. The first keeps route planning and its metric, kilometres saved per vehicle. Each has a team of about eight engineers and a designer. The founder holds the questions that cross both.
Splitting ownership when the second arrives
Split by outcome, not by task. Two product managers who share one backlog, one doing discovery and the other writing specs, double the meetings and halve the ownership. Two who each own an area of the product, one metric and a team that ships it end to end can decide most questions without each other. Draw the line where the dependencies are fewest, usually by user or by surface: the buyer’s dashboard and the field worker’s app, the merchant side and the customer side.
Write down three things when the split happens: which metric each owns, which decisions cross the line and who settles them, and what product operations does for both. The founder’s job changes from making product decisions to choosing between them when they conflict, which the [lesson on the founder as bottleneck](/library/founder-as-the-companys-bottleneck) treats in full.
The monthly decision audit
Once a month, two numbers and one question. For two weeks before the audit, log every product question an engineer or designer raises, with the time it was asked and the time it was answered; compute the median wait and the number open at week’s end. Ask each product manager to log their own week in two columns, deciding and supporting, and compute the overhead share. Then ask: which of the supporting tasks could be automated, moved to product operations or stopped?
Two thresholds trigger action. Overhead above a third of the week means product operations work comes first. A median wait above a day with overhead already cut means it is time for the next product manager, with a territory and a metric written before the job description. Keep the log for a quarter and the slowdown that used to arrive as a surprise will show up a month in advance.
The queue in the figure is a simplification and the Gurugram company is illustrative. The survey figures are as cited by Melissa Perri.
Sources
- Melissa Perri, Product Operations: The Fuel for Winning Product Strategies, July 2019 — Cites Alpha’s How Decisions Are Made: 46.8 per cent name lack of quality data as the main challenge; 21.9 per cent always or almost always use data.
- GitLab Handbook, Product Operations
- Daniel Slater, Amazon’s two-pizza teams, AWS Executive Insights