How to Structure a Game Product Team: Headcount, Levels, and Game Type
When I step into a new organization as a leader, the first thing I do isn't judge. It's absorb. Watch how the team actually moves, what's working, what's broken versus what just looks broken from the outside. Judgment comes second.
In practice, absorbing looks like asking a lot of questions. Why does this process exist. What's driving that decision. What does this team actually value, and why. Some people read that as curiosity. Others read it as scrutiny, and it scared them, even though I wasn't trying to catch anyone out. I was trying to understand what motivated people and why things operated the way they did before I decided what needed to change. That's not a flaw in the approach. It's just what real understanding costs, and it's worth naming so it doesn't feel personal to whoever's on the other side of it.
That evaluation runs on a rubric, but it's not a scorecard I fill out on day one and never revisit. It's closer to how you'd actually get to know someone you're serious about dating. You know what matters to you. You have real criteria. But you don't decide in the first five minutes whether someone fits your life. You give them room to show you. Building a team works the same way. You walk in with a clear sense of what the org needs, and you let people show you where they land against it.
The rubric itself doesn't change from company to company. What it points to, how many people you actually need and at what level, changes completely depending on the game. Two rosters make that obvious.
Same Pillars, Different Depth
PMs tend to assume team structure is a function of company size or budget. It mostly isn't. It's a function of the game. Get this wrong in one direction and you under-resource a live economy that needs constant tuning. Get it wrong in the other and you build a bureaucracy of seniority around a system simple enough for four people to run well.
Here's what stays constant no matter the game. Every PM I've ever built a team around needs three things: analytical rigor, design and player focus, and strategy. Strategy isn't a separate skill. It's what happens when the first two are actually working together. Those are the pillars. They don't change by genre, by studio, by game type. What changes is how much depth each pillar needs, and that's the real variable behind headcount and level mix. Not the other way around.
Jam City vs. Scopely
Jam City: an APM, a PM, a Senior PM, and one person running live ops. Four people total. Scopely: three Leads, four PMs, two Senior PMs, four to five live ops folks. Fourteen people total. Same job title on every one of those business cards. Wildly different org.
At Jam City, the game was match-3. Simpler systems, a shallower strategic surface area. One senior voice could hold the analytical judgment and the design instinct at the same time without diluting either one. A PM and an APM could execute underneath that without needing five layers of specialized ownership. One live ops person could run the operational cadence because the economy wasn't fighting itself in six directions at once. Four people wasn't a resourcing constraint. It was the right size for the systems that existed.
Scopely was midcore, PvP, live service. The complexity wasn't a matter of degree, it was a different category of problem. Multiple systems interacting in ways that needed dedicated ownership, the same kind of specialized ownership I've written about when it comes to how PMs partner with design. Three Leads instead of one senior generalist, each holding a distinct vertical. Two Senior PMs for the strategic judgment calls that a single lead layer couldn't fully absorb. Four to five live ops folks because a competitive live economy demands constant tuning and constant response at a cadence one or two people physically cannot sustain.
Neither team was overbuilt or underbuilt. Both were sized to the systems they were running.
Structuring by Bandwidth
This is where most leaders get the structuring decision wrong. They think headcount first, level mix second, as if adding people is the default lever. It isn't. The real question is bandwidth: how much can one person hold in their head, own end to end, and still do good work on, before quality quietly erodes because they're spread across too much surface area.
Bandwidth: the ceiling on how much a single person can own before ownership gets diluted and quality drops. Bandwidth isn't about hours worked. It's about how many distinct systems one mind can hold at a senior level of judgment simultaneously.
Expected Output by Level: a Senior PM or Lead owns a system end to end. Strategy, analytical calls, design judgment, accountability for the outcome, without someone checking their work at every step. A PM executes clearly scoped strategic decisions without needing to originate the strategy itself. An APM takes a well-defined piece of that PM's work and runs it competently.
That's the same arc I laid out in the game PM career ladder, and it's worth applying here as a design constraint, not just a growth path.
Mindshare: follows from where someone sits on that ladder. If you're asking one person to hold three systems that each require senior-level judgment, you don't have a resourcing gap. You have a seniority gap. Adding a junior underneath them doesn't fix that. It just adds someone for that senior to also manage.
The mistake I see most often: a team gets more complex, and the instinct is to add headcount. But if the real problem is that no one person can hold the judgment required, the fix isn't more hands, it's more seniority. The inverse mistake is just as costly. Put a senior generalist on a simple game and their judgment sits underused, stacked on top of a system that never needed that much strategic weight. One mismatch shows up as burnout and dropped balls. The other shows up as an expensive team that moves slower than the game requires.
Mapping the Game Before the Org Chart
Here's the process I actually use, in order.
- List every distinct strategic surface the game has. Economy, matchmaking, social, monetization, whatever applies. Don't group them yet.
- For each surface, rate the level of judgment it demands under ambiguity. Constant tradeoff calls with no clean answer means it needs a Lead or Senior PM. Well-defined and executable against clear specs means it can sit with a PM or APM.
- Check how much the surfaces interact with each other. High interaction usually means they can't be safely owned by the same person without one of them getting shortchanged.
- Only then count heads. Headcount is the output of that mapping, not the input.
This also means team structure isn't static. As a game's systems mature, or as live ops complexity grows, the mapping changes, and so should the team. The four-person structure that worked at Jam City would have collapsed under Scopely's live economy. The fourteen-person structure at Scopely would have been indefensible overhead on a simpler game. Neither number is right or wrong in the abstract. Each was right for what it was holding.
Closing Thoughts
Team structure isn't a headcount decision. It's a judgment call about how much depth each pillar, analytical, design, and strategy, needs to hold the game you're actually building.
So the next time you're staffing a team, don't start with the org chart. Start with the list above. That list is your headcount plan before it's anything else. Build from what the game actually needs, not from what you're used to running, and the size of the team stops being a guess.
