The request almost always arrives in the same form: we need more product people. The backlog is long, the roadmap keeps slipping, engineering is asking questions nobody has answered, and the obvious read is that the product function is understaffed.
Sometimes it is. More often the team is not under-resourced — it is under-decided. The two look identical from the outside and have opposite remedies, which is why this is worth ten minutes before it becomes a headcount request.
What a capacity problem actually looks like
A real capacity problem has a specific shape. Work is well specified and waiting. Engineers finish something and there is a gap before the next well-defined thing is ready. Discovery has stopped entirely because every product person is fully consumed by delivery. Decisions get made quickly when they are raised — there just are not enough people raising them.
The tell is that when you add a person, throughput goes up almost immediately. The work was queued and ready; you added a server to the queue.
What a decision problem looks like
A decision problem produces a different set of symptoms, and they are easy to misread as busyness:
- Work gets started, paused, and restarted. Engineering builds something for three weeks and then the direction changes without new information arriving.
- The same debate reopens. A choice was made in a meeting, but nothing was written down and nobody had clear authority, so it comes back a month later.
- Small calls escalate. Whether to support a second currency, whether to sunset a legacy flow, whether an edge case is in scope — these route to the founder or the CEO because no one else is sure they are allowed to decide.
- The roadmap changes on input rather than evidence. A large customer asks, a competitor ships, a board member has a view, and the plan moves.
Add people to this and it gets worse, not better. More product managers means more parallel proposals contending for the same undecided ground, more coordination overhead, and more work-in-flight to reverse when the direction changes again.
A test you can run this week
Pull the last eight weeks of shipped work and sort every item into three buckets: shipped as intended, materially reworked after work started, or abandoned mid-flight. You do not need a tool for this — a whiteboard and the engineering leads will get you close enough.
Then count the decisions currently waiting on one person.
If most work shipped as intended and the queue of ready work is empty, you have a capacity problem. If a meaningful share was reworked or abandoned after engineering time had gone into it, and the waiting-on-one-person list has more than a couple of items on it, adding people is going to be expensive and slow.
The cost asymmetry matters here. Under-hiring costs you speed. Hiring into a decision problem costs you speed, budget, and usually the person you hired, who leaves inside a year because nothing they proposed ever got resolved.
What actually fixes a decision problem
None of this requires headcount, which is the point.
Name an owner per area. Not a committee, not a working group — a person whose call it is, with the boundaries of that authority written down. Most teams have never made this explicit and assume everyone knows.
Write decisions down where the team can find them. A running log with the date, the call, the reasoning, and what would cause a revisit. The reasoning is the part that stops the debate from reopening: without it, a new argument that was already considered looks like new information.
State the criteria before you compare the options. Teams that argue about options are usually really disagreeing about what they are optimizing for. Say out loud whether this quarter is about retention or expansion, and half the roadmap arguments resolve themselves.
Give one forum real authority. One standing meeting where decisions actually get made and recorded, rather than three where they get discussed.
When it is both
It often is. In that case, sequence matters: fix the decision problem first, then hire against what is left. You will usually find that the number you needed was smaller than the one in the plan, and the person you hire lands in an environment where their work survives contact with the next planning cycle.
Two related pieces if this sounds familiar: your roadmap probably is not the problem, and what actually fits into ten hours a week of senior product leadership.
If you want a structured read on which part of your product function is weakest, the two-minute diagnostic walks through seven dimensions and returns where the constraint actually sits.