Building vs. Inheriting a Product Team: A Leader's Framework

I walked into Jam City to find the team had already quit. Not scaled back. Gone. An empty room and a blank calendar.

Years later I walked into Scopely to find the opposite problem. Two teams, fully staffed, functioning, showing up every day. It was the harder job.

That contrast taught me something most PMs don't learn until they're already in the seat: building a team and inheriting one are not the same skill. Building from nothing is a resourcing problem. You're short on people and time, and the fix is sequencing. Inheriting a team is a belief problem. The people are already there, already competent, already operating under a definition of success you didn't write and might not agree with. You're not filling a room. You're changing what the people already in it believe. Both are hard. They are just hard in different ways. One is hard because you have nothing. The other is hard because you have to unmake something people don't want unmade.

This is a director-and-up problem, not because junior folks can't understand it, but because the decision sits at that altitude. Managing a team someone else built is one job. Architecting the team an organization actually needs is another. Conflating the two is how leaders run out the clock on teams that were never going to get the business where it needed to go.

Here's the part that took me longer to understand than it should have. Building around who you have isn't about who's good today. It's about who can grow into the org you have real conviction about becoming. That requires two things most leaders skip. An honest read on someone's ceiling, not just their current output. And a vision specific enough to measure people against. Without that vision, you're not building anything. You're managing what's already in front of you and calling it strategy.

At Jam City, there was no team to inherit, so the entire question was resourcing. Senior talent is hard to attract at a smaller company. You're not competing on brand or comp the way a Zynga or a Scopely can. So the strategy wasn't waiting for people I couldn't get. It was hiring APMs and PMs and building them up deliberately, as a growth strategy rather than a fallback. That team wasn't strong because I found strong people. It was strong because I built strength into people who weren't there yet.

Scopely was the harder problem because the team wasn't broken in any way that showed up on a dashboard. I inherited two teams, roadmap and live ops, thirteen people total, both fully staffed and functioning by any normal measure. Functioning isn't the same as right.

The roadmap team was drowning in process. Big decks. Deep comp research. Elaborate specs for features that never shipped. They had mistaken the depth of the analysis for the quality of the decision. The live ops team ran on the opposite instinct. Pure gut check, no rigor underneath it. Two teams, same root gap. Neither one had real analytical rigor. One buried it under process. The other skipped it entirely.

I pushed both teams toward the same thing: more rigor, more strategic thinking, decisions grounded in data instead of decks or instinct. Some people made that shift. Most didn't. By the time the org came out the other side, I had kept four of the original thirteen.

The nine I let go weren't bad at their jobs. They were doing exactly what the org had trained them to do. But they didn't fit the org that had to exist going forward, and no amount of coaching was going to close that gap. Building a team sometimes means growing the people in front of you. Sometimes it means being honest that the org you need and the org you have are not the same org, and acting on that before another year gets spent pretending otherwise.

Buy-in complicated all of it. Most of the people who left weren't rejecting the direction on its merits. They saw it as a loss, not an opportunity, and they were scared. That's not a flaw in them. Change is hard for everyone.

I used to think my job was to wait until the room was with me. I don't think that anymore. There are things to build and a business to run, and neither one waits for buy-in to catch up. Resilience was the actual requirement, not agreement. Mine, to hold the line and keep moving while the room wasn't there yet. Theirs, if they were going to make it through the change at all.

That's a harder truth than it sounds, and I don't say it lightly. Leadership isn't only about pulling everyone forward together. Sometimes it's about accepting that some people won't come, and moving anyway, because the work doesn't stop for consensus.

There are two ways to read a moment like this, depending on where you're sitting.

If you're the leader, the work is building the conviction to do it at all. Start by defining the org you actually need before you evaluate a single person in it. "Can this person grow" is a meaningless question without a specific target to grow toward. The leaders who get this wrong usually aren't cruel. They're unclear. They keep people because letting go feels harder than the alternative, and they call that loyalty instead of what it is, which is avoidance.

I've written before about what it takes to hold a line through a broken system, Putting Stakes in the Ground, and the same discipline applies here. Conviction isn't a personality trait. It's a decision you keep making.

If you're inside a team going through this, the signals are readable if you know where to look. Are the conversations about where you're headed, or about closing gaps in how you already work. Are you getting new problems to solve, or closer supervision on the old ones. People being built toward get handed more ambiguity, not less. People being managed out get more oversight, not more scope. Both can look like attention from the outside. Learning to tell them apart early changes what you do next, whether that's leaning further in or starting to look elsewhere before the decision gets made for you.

Team architecture isn't an org chart. Anyone can draw boxes and lines. It's a decision about what the organization has to become, held with enough conviction that you can look at the people currently inside it and tell, honestly, who fits that future and who doesn't. At Jam City that meant building from nothing. At Scopely it meant looking at thirteen people I inherited and keeping four.

I didn't get either team right by finding good people. I got them right by knowing what the team needed to become before I ever tried to build it.

This is the first of a few pieces I want to write on team architecture. The next looks at how the skillsets you build a team around stay constant while the shape of the team, the headcount, the mix of PM, Lead, and Senior PM, shifts depending on the game itself. After that, the systems that actually hold a rebuilt team together: the playbooks and charters that turn a group of individuals back into a team.