Stephen Brenish
You’re three weeks into your new associate producer role at a mid-sized game studio, and your Jira board looks immaculate. Epics nested. Tickets groomed. Velocity tracked. Your engineering lead walks by, glances at the screen, and says “that’s cute.” Not mean about it. Just… unimpressed. You’ve run software sprints for five years. You shipped a payments platform used by millions. And somehow, you feel like you’re starting from zero. That gap between tech PM confidence and game production reality is real, and it catches almost everyone off guard.
Here’s the thing: you’re not starting from zero. You’re starting from maybe 60%. The question is knowing which 60% actually transfers, which habits will actively hurt you, and what you need to build fast.
Your Process Instincts Are Mostly Right
Scrum. Kanban. Sprint planning. Retrospectives. Stakeholder communication. Risk registers. Dependency mapping. All of it moves with you. Games are still software projects. They still blow up when requirements aren’t defined. They still suffer when engineers are blocked and nobody escalates quickly enough.
But here’s what blindsides people: a lot of game studios are still running pretty chaotic production processes, especially mid-size and indie teams. If you’re coming from a disciplined tech environment, your instinct to write clear acceptance criteria or push for a proper milestone definition isn’t going to feel foreign to your team. It’s going to feel like a relief to half of them and an annoyance to the other half. That ratio shifts in your favor over time.
The tools you already know will serve you. Jira? You’ll adapt to Shotgrid, Hansoft, or Hacknplan quickly enough. Hacknplan is worth a look specifically if you move into a smaller team, since it’s built around game development milestones instead of generic software sprints. For cross-discipline tracking at larger studios, Shotgrid (formerly Shotgun) is the industry standard for asset pipelines. Don’t wait to learn it. Get the free trial, set up a fake project, break things.
The Creative Dependency Problem
This is where tech PM muscle memory will genuinely mislead you.
In software, dependencies are mostly technical. Service A needs to ship before Service B can consume it. Clean. Logical. Predictable within reason. In games, dependencies are creative AND technical, and the creative ones are the harder ones to manage. A level can’t be fully lit until the art direction is locked. Art direction won’t lock until the creative director sees it running in-engine. The creative director is also the studio head and has three publisher calls this week. That level is now a blocker for your audio team who needed to do a mix pass before the build goes to QA on Friday.
I’ve seen tech PMs handle this by doing what worked before: escalating up, demanding a decision, locking the dependency chain. Sometimes that’s exactly right. But in games, creative decisions that get forced often get revisited later anyway, which means you’ve just moved the rework further down the schedule where it costs more. Part of the adjustment is learning when to push for a decision and when to deliberately build schedule buffer around creative unknowns. That’s not weakness. That’s reading the project correctly.
Scope Creep Has a Different Shape
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
In enterprise software, scope creep usually comes from stakeholders adding features. In games, it comes from inside the house. A designer adds “just one more mechanic.” An artist iterates past done because the thing could be better. A programmer goes deep on a system that’s 80% there and needs to be 95% before it feels right.
This is called polish creep, and it kills indie and mid-size game projects faster than almost anything else. Your job is to make it visible without crushing the creative drive that makes games worth playing. That balance is genuinely hard, and it takes time to calibrate.
One practical shift: stop thinking in terms of “done” and start thinking in terms of “shippable, better, best.” When a task comes into review, the question isn’t “is this finished?” It’s “which quality tier does this need to hit for launch, and are we there?” This gives you a real conversation instead of a standoff.
Practical quality tier approach:
| Quality Tier | Definition | Use Case |
|---|---|---|
| Shippable | Functional, no bugs, meets design intent | Background elements, early systems |
| Better | Polished, feedback-responsive, feels intentional | Core gameplay loops, UI |
| Best | Exceptional, memorable, differentiating | Trailers, first 10 minutes, key set pieces |
Not everything needs to be Best. Ruthlessly deciding which things do is most of your job as a producer.
Building Trust With Disciplines You’ve Never Managed
Tech PMs manage engineers, maybe designers. Game production means owning relationships with environment artists, animators, character artists, audio designers, narrative leads, QA, and sometimes licensing and localization teams. Each discipline has its own pipeline, its own vocabulary, and its own opinion about whether production understands what they actually do.
The fastest way to earn trust across disciplines: show up to their standups for the first month and say almost nothing. Ask one good question per session. Learn what “done” looks like in their pipeline before you start setting any expectations about it. An animator’s workflow from concept to rigged, weighted, and in-engine is completely different from a software engineer’s ticket-to-merged flow. Try to manage both with the same metrics on day one, and you’ll create friction that takes months to undo.
“The Art of Game Design” by Jesse Schell isn’t a production book, but read it anyway. Understanding how game designers think will make you significantly more effective in every conversation you have. Jason Schreier’s “Blood, Sweat, and Pixels” is essential reading for understanding the actual human and organizational pressures that blow up game projects. These aren’t fluffy reads. They’ll change how you see your role.
For online learning, LinkedIn Learning’s Game Production Fundamentals courses and the International Game Developers Association (IGDA) resources are practical starting points. If you want to go deeper, MasterClass has a game design course from Will Wright that’s worth the time for building your design vocabulary.
Your Risk Management Instincts Need Recalibration
Risk registers work in games. Risk tolerance is different. In enterprise software, a two-week slip might mean a missed quarterly metric. In games, a two-week slip to your submission date might mean missing a major platform promotional window worth hundreds of thousands of dollars in visibility. Or it might mean nothing, because your launch date had three weeks of buffer and you knew it.
The contextual stakes in game production are wildly variable depending on whether you’re indie, AA, or AAA, whether you have a publisher, and whether you have a platform deal. Get clear on the actual cost of delay as early as possible. Don’t assume a schedule has the same meaning it did in your previous job.
Productivity tools that translate well from tech PM roles: Notion works great for game production wikis and design documentation. Linear is worth a look for smaller teams who find Jira heavy. Miro stays excellent for sprint planning, dependency mapping, and milestone structure work. Slack plus a good channel discipline is table stakes.
The skills that made you effective in tech are real assets. The gap isn’t in your competence. It’s in context, domain vocabulary, and a more nuanced relationship with creativity as a production variable. Close that gap deliberately, stay humble in the places where your experience doesn’t map cleanly, and you’ll get there faster than you think.
Photo: Alena Darmel via Pexels
