Production 101 - #4 Role of an External Producer

What it means to be responsible for a game you don’t directly control

Mar 12, 2024

External producers work on the publisher side, overseeing games built by outside development studios, from initial pitch through to launch.
The role spans pitching, developer selection, contract negotiation, milestone oversight, budget management, platform submissions, and commercial alignment.
It requires financial and legal literacy that surprises most people coming from a development background.
The defining structural challenge is influence without authority: you are accountable for outcomes you cannot directly control.

In the previous post I covered the internal producer, the person running the team from inside the studio. This post is about the other side of that relationship: the external producer, sitting at the publisher, managing a game being built by someone else.

It’s a role that gets less airtime than internal production, partly because fewer people do it and partly because the publisher side of the industry is less visible than the studios themselves. But it’s a genuinely distinct set of skills, and for some producers, it’s a much better fit than working inside a development team.

The external producer works for the publisher. The studio making the game is not your employer. You’re the bridge between what the publisher has agreed to fund and what the studio is actually building. That gap is where the job lives.

What “publisher” means varies. It could be a traditional game publisher like EA, Ubisoft, or Paradox. It could be a platform holder commissioning an exclusive. It could be a mobile publisher licensing a brand and funding a developer to build around it. The shape of the relationship changes, but the external producer’s function stays roughly the same: represent the publisher’s interests while keeping the development partnership healthy enough to ship something good.

What an external producer actually does

The external producer works for the publisher. The game is being built by a development studio that is separate from the publisher, sometimes across the country, sometimes across the world. The external producer is the publisher’s primary point of contact with that studio, and the primary conduit back.

That sounds simple. In practice, the role touches almost everything.

You’re involved from the beginning, assessing potential projects for market appeal, audience fit, and how they sit within the publisher’s existing portfolio. You help evaluate which studios are right for which projects, looking at their skills, their creative approach, and their track record. Once a deal is struck, you own the relationship from that point through to submission and launch.

What you’re managing is a set of obligations and expectations that run in both directions. The developer needs to understand what the publisher requires: the quality bar, the commercial positioning, the branding constraints, the platform requirements. The publisher’s leadership needs to understand what the developer is building, how it’s progressing, and what’s at risk. You’re the person who carries information across that gap accurately and without distortion.

“You’re the person who carries information across that gap accurately and without distortion. Getting that wrong in either direction is how projects fall apart.”

The responsibilities in detail

The scope of the external producer role is wider than most people expect when they first encounter it.

On the commercial side, you’re thinking about branding, audience fit, and market positioning. If the game involves licensed intellectual property, you’re managing the licensor relationship too, which means additional approval cycles, compliance obligations, and a set of relationship dynamics that sit entirely outside the development team itself.

Project management looks familiar to any producer: maintaining production plans, schedules, and roadmaps. The difference is that you’re doing it across multiple projects simultaneously. At any point you might be managing a game in early production with one studio, overseeing a game in full production with a second, and coordinating the submission process with a third.

Milestone oversight is one of the more formal parts of the job. When a developer submits a milestone, you review it against the milestone schedule and the Statement of Work. You decide whether to approve it, which means sending the approval email and processing the invoice, or to document the shortfall, describe what’s missing, and begin the formal discussion about remediation before any rejection is issued. This is consequential work. Milestone approvals trigger payment. Formal rejections have legal weight. You need to be precise.

Budget management at this level involves predicting costs from early in the project, often before the final game is fully defined. External expenses, travel, licensing fees, QA costs, certification fees: you’re estimating and tracking all of these from a publisher perspective, which is a different set of numbers from the developer’s own budget.

Contract work is a constant thread. You’re involved in negotiating milestone achievements, payment schedules, and scope of work details. When scope changes, the contract has to change with it, and that means working with legal, negotiating with the developer, and documenting the agreement correctly. If you’ve come from a purely creative or development background, this part of the job may require more adjustment than anything else.

Platform submissions are the path from a finished game to a game that’s actually available. The external producer guides the developer through first-party requirements, certification, and the approval processes specific to each platform. The certification requirements for PlayStation, Xbox, Nintendo, and mobile storefronts are different in their detail and different in how they’re enforced. Knowing them, and knowing the people at the platform holders, matters.

Risk management runs through everything. The external producer is supposed to identify risks before they become problems, which means maintaining enough understanding of the project’s real status that early signals don’t get missed.

Working with other teams and partners

The external producer’s role extends well beyond the studio relationship. A significant part of the job involves coordinating with departments inside the publisher’s organisation and with third parties outside it.

Marketing. The external producer is typically the link between the studio and the marketing team. That means sharing game features and content at the right time, providing game assets (screenshots, trailers, builds for review), and overseeing the creation and approval of marketing materials in collaboration with the studio. Getting this right requires discipline on both sides: marketing needs assets on time to plan campaigns, and the studio needs enough notice to produce them without disrupting development.

First-party platform holders. If your game is shipping on console or mobile storefronts, you have a formal relationship with Sony, Microsoft, Nintendo, Apple, Google, or Amazon, depending on the platforms. Each has its own submission, certification, and approval processes. The external producer shepherds the project through these processes: managing the submission schedule, responding to certification failures, and maintaining the relationship with the platform representative. First-party processes have their own timelines that don’t bend for development slippage, so planning these carefully is non-negotiable.

“First-party certification timelines don’t bend for development slippage. Plan them carefully or they become a crisis.”

QA and localisation. The external producer liaises with the publisher’s QA and localisation managers to ensure proper resource allocation and task prioritisation throughout the project. In the final stages of production, this means managing bug prioritisation and waiver decisions: which bugs get fixed before ship, which get deferred, and which get waived as known issues. These are often high-stakes calls made under time pressure, and the external producer owns the process.

Legal and licensors. If the game involves licensed IP, whether a sports licence, a film tie-in, or a brand partnership, the external producer manages that relationship on the publisher side. This includes coordinating approvals, managing licensor feedback on builds, and ensuring the studio has what it needs to satisfy the licence terms. Legal sits alongside this: contract compliance, amendments, milestone approval language. It’s not glamorous, and a lot of it is slow-moving, but failures here can hold up a release.

User research, consumer insights, and analytics. On larger projects, the external producer will bring in consumer insight and user research teams to run playtests or surveys on studio builds. The findings then need to be communicated back to the studio in a way that’s useful, not demoralising. This is a genuine skill. A user research report that lands badly with a development team can create friction that lasts for months.

The skills this role actually requires

[PERSONAL EXPERIENCE] I’ve talked to a lot of producers who moved from internal to external production and said some version of the same thing: they didn’t expect how much financial and legal literacy the role required.

That’s not because the financial concepts are complicated. It’s because internal production rarely puts them in front of you directly. An internal producer might know the project’s budget in broad terms; the external producer is managing the publisher-side P&L, forecasting costs before the scope is settled, and communicating budget and scope implications to executive management. Those are different demands.

The legal side is similar. Understanding the difference between a fixed-price contract and a time-and-materials contract, knowing what a Statement of Work needs to contain, understanding what happens when a milestone is formally rejected: these things matter, and not knowing them creates real exposure.

The interpersonal side is substantial too. You’re managing relationships with developers, with vendors, with internal teams across the publisher, and with platform holders and licensors. Each of those relationships has different dynamics, different expectations, and different communication norms. The ability to read those differences and adapt accordingly is something you develop over time.

“An internal producer might know the project’s budget in broad terms. The external producer is managing the publisher-side P&L, forecasting costs before the scope is settled, and communicating budget implications upward. Those are different demands.”

Prior experience in internal or external game development is the practical foundation. You need to have shipped console, PC, or mobile titles. You need to understand how development teams actually work, because you can’t evaluate a studio’s progress or flag risks in their delivery if you don’t know what healthy development looks like from the inside. The external producer who has only ever been on the publisher side is at a real disadvantage.

The other thing worth naming is comfort with independence. On a publisher team, you’re often working without the day-to-day peer support structure that exists inside a development studio. You’re expected to make judgements, manage your own time across multiple projects, and escalate when escalation is appropriate, rather than doing it reflexively.

What does a day actually look like?

[PERSONAL EXPERIENCE] This is the question I get most often, and I think it’s the right one to ask. Job descriptions and responsibility lists are useful, but they don’t tell you what it feels like to do the job.

So here’s a specific day. Not a representative average. A real one.

The morning starts with email and project management tools. Bug reports have come in overnight from QA on Developer A’s game, and I scan them for anything urgent. I check in with the associate producer: what do they need from me today, and do they have any blockers?

The latest build from Developer A has landed on the FTP. I pull it down and verify it runs on the dev kit, then coordinate with QA to confirm they have the same build and are working through the test plans.

The QA lead wants to discuss a set of bugs the developer has asked to be waived. Some waiver requests are straightforward; others need a harder look, because waiving a bug that later becomes a certification failure is a problem that comes back to you. That conversation takes focus.

Then there’s a separate issue to investigate: dev kits that were supposed to be delivered to Developer B for a different project haven’t arrived. I need to find out where they are and what that means for the developer’s schedule this week.

Mid-morning shifts to milestone review. Developer C has submitted their latest milestone. I sit down with the milestone schedule and the Statement of Work and go through the submission methodically: what was promised, what was delivered, where the gaps are. Either the milestone passes and I send the approval and process the invoice, or I need to document the shortfall clearly before any formal conversation about rejection begins. This documentation isn’t bureaucracy; it’s what protects both parties.

Between that and a status report that needs to go out later, I’m also working on a concept approval deck for a new game in early consideration. Consumer insights and product teams have provided feedback, and I’m folding that in. The deck is trying to make the case for a game that doesn’t exist yet, to an audience who will fund it or not, based on what I can show them about the opportunity.

Lunch exists. I eat it, talk to people informally, and if I have the time, play a game. This is not optional. You cannot represent games you haven’t played.

The afternoon brings a marketing request: screenshots from Developer A’s game for upcoming promotional use. Some of the assets in the current build are placeholder, so I work with the associate producer on how to compose and frame shots that capture what the game actually does without featuring assets that aren’t final. It requires knowing the game well enough to make those calls.

I check in on the associate producer’s development. Their Individual Development Plan needs attention, and they should have a mentor meeting scheduled. I make sure that’s happening.

Then I demo the latest working build from Developer A to the head of sales and marketing. I hand them the controller. I let the game speak for itself. After the demo, I float the new game concept to gauge early interest from someone whose read of the market I trust.

Late afternoon is meetings and calls. First, a meeting with the licensor about improving approval cycle times: the current cycle is adding weeks to the schedule and nobody is happy about it. Then a call with legal about a development agreement amendment covering a scope change with Developer B. The scope change affects the payment schedule and the delivery timeline, and the amendment has to reflect both accurately.

After that, I negotiate the scope and schedule impact directly with Developer B. We’re trying to find an arrangement that works for the developer’s team without undermining the publisher’s release calendar. Neither side will get everything they want.

A call with the first-party developer rep to get a status update on a submission that’s been in certification longer than expected. I want to understand whether there’s any willingness to waive specific bugs that are holding things up, and how much of that is a negotiation versus a hard requirement.

I check in with the QA lead to hear how the day’s testing went and get an early view of the bug report before it’s finalised. Then I pick up Developer A’s game again and try to get further than I did yesterday.

“You cannot represent games you haven’t played. That’s not a peripheral observation. It’s part of the job.”

The structural challenge: influence without authority

[UNIQUE INSIGHT] Everything about this role flows from one central fact: you are responsible for a game that you do not control. You can ask the developer to do something. You cannot make them. You can document a shortfall and withhold a milestone payment. You cannot walk across the floor and fix it yourself.

That distinction is the structural reality of external production. Authority over the development team sits with the studio’s own leadership. Your authority runs through the contract, through the relationship, and through the quality of your judgement. If the developer respects your read of things, your calls carry weight. If they don’t, the legal tools are the last resort, not the first.

This creates a set of practical tensions. The developer is a partner, and you want that relationship to work. But the developer is also a contracted party with legal obligations. Balancing genuine rapport with the readiness to enforce those obligations, when necessary, is one of the skills that separates experienced external producers from people who are still learning what the role requires.

The same tension appears with internal stakeholders. Senior leadership at the publisher has priorities and preferences. Sometimes those priorities are well-calibrated to what the developer can actually deliver; sometimes they’re not. Part of your job is translating between what leadership wants and what the developer can do, managing expectations accurately in both directions, and protecting the developer from scope requests that would derail production, while also making sure leadership’s genuine requirements are heard and acted on.

Time zones complicate all of this. If you’re managing studios across multiple regions, every conversation requires scheduling discipline and asynchronous communication practices that hold up when you can’t talk in real time. Cultural differences across international teams add another layer: the norms around how disagreement is expressed, how bad news is delivered, and how commitments are made vary considerably, and misreading those norms creates friction that’s hard to trace back to its source.

“Your authority runs through the contract, through the relationship, and through the quality of your judgement. If the developer respects your read of things, your calls carry weight.”

The part of the job nobody talks about

The formal structure of the role is teachable: milestone reviews, marketing coordination, first-party management. The hard part isn’t.

The hard part is maintaining an honest relationship with a studio team you don’t manage, who may feel scrutinised or second-guessed by everything you do. You’re there on behalf of the publisher, which means you sometimes have to deliver bad news, push back on deliverables, or escalate risks that the studio would prefer to handle quietly. Done badly, this creates an adversarial dynamic that makes the project worse. Done well, the studio sees you as an extension of their own production capability: someone who has their back with the publisher and who surfaces problems early rather than waiting for them to become contractual disputes.

The external producers I’ve seen struggle most are the ones who default to process: they do the milestone reviews, write the reports, attend the meetings, and still somehow miss the fact that the project is in trouble. The role requires you to read the room, notice when a studio’s communication pattern changes, and ask the questions that aren’t comfortable. Process supports that work. It doesn’t replace it.

“The external producers who struggle most default to process. The role requires you to read the room.”

Building commercial value into the project is also part of the brief. External producers look proactively for opportunities to expand a project’s commercial footprint: consumer and trade marketing initiatives, demos, downloadable content (DLC), OEM deals, platform extensions, territory-specific localisation. These aren’t afterthoughts. An external producer who only manages what’s already agreed isn’t doing the full job.

How to get into external production

There’s no single route. Some external producers come up through internal production at studios, move to the publisher side, and bring that development-facing credibility with them. Others start in QA or production coordination at a publisher and build outward from there.

What the role selects for, regardless of background, is the ability to manage relationships across organisational boundaries and to stay calm when the information you’re getting doesn’t add up.

I’ve rarely seen anyone succeed in external production without having spent meaningful time first inside a development studio. The reason is practical. If you haven’t been inside a development team, you don’t have a reliable mental model of what healthy development looks like. You can learn the publisher-side processes without that model. What you can’t do reliably is evaluate a studio’s real status, identify when they’re struggling versus when they’re just in a difficult phase, or read the difference between a team that’s behind and one that’s in trouble. Those distinctions matter enormously in this role.

The most useful thing you can do early is understand both sides of the relationship. If you’ve only ever worked at a publisher, try to get close to a studio-facing project. If you’ve only worked at studios, understanding what a publisher’s internal approval chain looks like will help you enormously when you’re trying to get decisions made quickly.

The more common path is to work as an internal producer first, often at the associate or producer level, ship one or more titles, and then move to the publisher side. Some people make that move deliberately, because they’re drawn to the portfolio scope, the commercial and legal dimensions, or the variety of working with multiple studios. Others find themselves in it because an opportunity came up and they took it.

Live game experience is increasingly valued in these roles, partly because publishers are increasingly in the business of operating live titles rather than just shipping them. Understanding how live games work operationally, and what the post-launch support relationship between a developer and publisher looks like, gives you a more complete picture of what you’re managing.

The role tends not to have a formal career ladder. At larger publishers, there are often associate, producer, and senior producer levels with defined scope. At smaller publishers, a single external producer might own three or four projects simultaneously. That breadth can be a feature, not a limitation, if you’re the kind of person who needs variety to stay sharp.

How the role is changing

The publisher-developer model has shifted considerably in the past decade. More studios are self-publishing than before, which means fewer games have a traditional external producer relationship. For the ones that do, the role has grown in complexity: more platforms, more certification requirements, more marketing surface area, and greater pressure on milestone quality as publishers have become more risk-averse since the economic contractions of 2023-2024.

Remote work has changed the day-to-day. When I started working in this area, visits to the development studio were routine. You sat with the team, walked the floor, got a read on morale and momentum. That’s harder to do at a distance. Video calls compress the relationship. You need to be more deliberate about maintaining it.

The role also intersects increasingly with data and analytics. Publishers want to see player research baked into development earlier, and external producers are often the ones pushing for that: arranging playtests, commissioning surveys, getting early builds in front of players and feeding the results back usefully. Studios that resist this tend to struggle commercially, regardless of how well they execute technically.

Discussion about this post

Ready for more?