Production 101 - #17 Pre-Production: What the Producer Does Before Production Starts
The phase where schedule, scope, and team structure get decided, with or without you
Game Production Alchemist › Production 101 › What Game Producers Do in Pre-Production
Pre-production is where most games are won or lost, and where producers are most likely to be absent or ineffective.
The producer’s job in pre-production is less about scheduling and more about tracking dependencies, asking hard questions, and recording decisions.
Prototype choices commit technology paths. Producers need to know which questions a prototype actually answers.
Entering full production with unresolved design ambiguity means resolving it in the middle of an iteration, which is the most expensive place to do it.
This is part of the Production 101 series.
Pre-production is where most games are won or lost. It’s also where producers are most likely to be absent, or present but ineffective, because the work is less legible than a task board. There’s no backlog to point at, no velocity to track, no milestone build to review. There’s just a set of questions the team needs to answer before real production starts, and a limited window in which to answer them properly.
The challenge is that pre-production looks, from the outside, like not much is happening. The team is small. There are no builds shipping. The design is still in flux. A producer who measures their own value by the number of things moving through a pipeline will find pre-production uncomfortable. That discomfort is worth examining, because pre-production is where the decisions that govern everything else get made.
What pre-production is for
Pre-production exists to reduce uncertainty before commitments become expensive. The cost of a decision during pre-production is a conversation. The cost of the same decision in full production is weeks of rework, a reschedule, and a stakeholder conversation nobody wanted to have.
The cost of a decision in pre-production is a conversation. The cost of the same decision in full production is weeks of rework and a stakeholder conversation nobody wanted to have.
The questions that should be answered before production begins: what are we building, for whom, on which platforms, with what technology, with what team? Production can start before all of these are answered. It shouldn’t. Every unresolved question that enters full production is a decision that will be made reactively, under pressure, by whoever happens to be in the room when the problem becomes unavoidable.
The argument is for knowing which questions are genuinely open, owning them explicitly, and making sure the people with the authority to answer them are in the conversation before the schedule is committed.
[INTERNAL LINK: Post #13 — How to Build a Milestone Schedule]
Discovery and the producer’s role
The producer doesn’t write the game design document. But they’re responsible for the process that produces it.
That means identifying the dependencies that creative work creates as it develops. A design decision about progression systems has implications for data infrastructure, for the analytics pipeline, for localisation. A decision about open-world exploration has implications for content volume, for streaming architecture, for team size at peak production. The producer’s job during discovery is to keep the design grounded in what the team can actually build, while the design is still cheap to change.
[INTERNAL LINK: Post #12 — Agile for Game Producers]
The GDD question is worth addressing directly. In a traditional waterfall model, the GDD gets written in pre-production and then production executes against it. In Agile development, the GDD is often a living document, updated as the team learns. Neither approach eliminates the need for pre-production. Both require that certain foundational decisions be made before full production starts: what the game is, what the core loop is, what platforms it targets, what the technology stack is. The format of the design document matters less than whether those decisions exist and are recorded somewhere the full team can find them.
The other thing the producer does in discovery is make sure the decisions being made get written down. Discovery is full of conversations. A lot of those conversations produce real decisions. Those decisions get made once, in a room with the right people, and then never formally recorded. Six months later, when someone asks why the game has a particular feature or why a technical choice was made, nobody remembers the reasoning. The producer who’s present in discovery and keeps a record of those decisions is protecting the whole project from itself.
The most valuable habit I’ve developed in pre-production is running two documents in parallel: a decision log and an open questions list. The decision log records what was decided, when, who made the call, and the reasoning. The open questions list tracks unresolved questions by date, with a note on which decisions are being made against an assumed answer because the real answer isn’t available yet. Pre-production is full of those assumed answers. Recording them means that when the question eventually gets resolved, you can trace back to every decision that was built on the assumption and check whether it still holds.
Prototype decisions and what they commit to
A prototype answers questions. It also creates path dependencies that are expensive to undo later.
Technology choices made during prototyping have a way of becoming permanent. The engine integration that worked well enough to get the prototype running becomes the engine integration that the full team builds on. The rendering approach that made the demo look good becomes the rendering approach that the engine team has to support for the next three years. The producer’s job is to know which questions a prototype is actually answering, and which questions it’s accidentally foreclosing.
A prototype that proves the core loop works is valuable. A prototype that proves the core loop works while accidentally locking in an architecture decision nobody reviewed is a different kind of thing.
The questions worth asking before a prototype starts: what are we trying to learn from this? What decisions will we make based on the result? Are there assumptions baked into the prototype approach that we’re treating as settled when they aren’t? A team that can answer those questions cleanly before prototyping is likely to build a prototype that gives them genuinely useful information. A team that goes straight to building will get useful information and a lot of path dependencies, and won’t always be able to tell which is which.
The producer doesn’t need to understand the technical details of every architecture decision. They need to understand which decisions are being made, when, and whether anyone with commercial or scheduling authority has been included in the conversation.
Technical pre-production
Engine licence, platform decisions, pipeline setup, middleware selection. These all land on the producer’s list before a single feature is built.
They’re unsexy and easy to defer. A team that’s excited to start making the game wants to start making the game. Nobody is excited about reading licence agreements or evaluating middleware vendors. But these are also the decisions that create the most expensive problems when they’re wrong. An engine licence that turns out to be incompatible with your target platform. A middleware solution that works fine until you need to ship on a console and then suddenly doesn’t. A build pipeline that nobody set up properly in pre-production, so the first two months of full production are spent fighting the tools instead of building the game.
A producer who isn’t involved in technical pre-production will be managing the consequences of decisions made by engineers in isolation from commercial and scheduling reality. Technical decisions made without someone in the room whose job is to connect them to the project’s constraints tend to be technically sound and commercially blind.
The most expensive technical pre-production mistake I’ve seen, more than once, is deferred platform certification research. A team builds a game assuming a platform will behave a certain way, because that’s how it behaved two years ago, or because that’s how a similar platform works. Then the cert submission happens and something fundamental is wrong. Platform requirements change. They’re not always published clearly. Finding this out during production is recoverable. Finding it out during cert is a different kind of problem entirely.
Team structure and capacity planning
When to hire, when to use contractors, what disciplines are needed in what phase. These decisions are made in pre-production and lived with for the rest of the project.
Getting the discipline mix wrong in pre-production creates one of two problems. Hire too early and you have a team spending project money before there’s anything for them to build. The design is still in flux, the technology is still being decided, and a team of forty has nowhere productive to direct its energy. That’s expensive in cash and in morale.
Hire too late and you have a bottleneck you can’t resource your way out of. The production phase starts, scope is committed, the schedule is locked, and you’re three months from your first external milestone with half a team. You can hire into that situation. You can’t get time back.
The producer’s job in pre-production is to translate the project plan into a staffing model: what disciplines are needed, at what capacity, and when. That model then gets presented to whoever controls hiring and budget, clearly enough that they can make an informed decision. The staffing model is connected to the schedule [INTERNAL LINK: Post #13 — How to Build a Milestone Schedule], so when the schedule changes, the staffing model changes. They shouldn’t be maintained as separate documents that drift apart.
The contractor question deserves specific attention. Contractors are useful for filling short-term capacity gaps, for specialist skills the team doesn’t need full-time, and for scaling up during crunch periods with defined endpoints. They’re less useful as a strategy for avoiding permanent headcount decisions you should be making. If a discipline is needed for the life of the project, that’s a permanent hire. Using contractors as a substitute for permanent hires when you need permanent hires adds overhead, creates knowledge transfer problems, and generally costs more than making the hire directly.
When pre-production is over
The signals that mean the team is ready to commit to full production are: the core design is validated, the technology is proven, the team is in place, and the first milestone is defined with clear acceptance criteria.
Those criteria sound simple. They aren’t. “The core design is validated” means someone has built something that demonstrates the core loop works, that target players have responded to it in the ways the design intended, and that the team agrees the thing they’ve built is what they’re going to keep building. The design has enough of a foundation that production can build on it without the foundation changing. That’s the bar. The design document can still be incomplete.
“The technology is proven” means the key technical risks have been resolved in favour of something the team knows how to build and ship. Not all risks. The key ones. The ones that, if they went wrong, would invalidate the production plan.
The mistake is calling pre-production over because the calendar says it should be. Pre-production phases get compressed under schedule pressure constantly. A publisher wants to see production momentum. A studio head is watching headcount sitting in pre-production mode and wants them building features. An investor wants to see a vertical slice. All of these are real pressures and all of them can produce the same outcome: a team that enters full production with unresolved design ambiguity, because the pre-production phase was declared finished before the work was actually done.
A team that enters full production with unresolved design ambiguity will resolve that ambiguity in the middle of an iteration. That’s the most expensive place to do it.
A producer who knows the project is not ready for full production has an obligation to say so, clearly, with specifics. The specific questions that are unresolved. The specific risks that are unmitigated. The specific criteria that haven’t been met. That conversation is uncomfortable. It is substantially less uncomfortable than explaining, six months later, why full production is running two months behind schedule because the team spent the first quarter resolving design questions that should have been answered in pre-production.
Pre-production done well produces four concrete things: a prototype that validates the core loop, a team capable of building the full game, a milestone structure agreed by both the team and the publisher, and a conscious decision to enter production. That last part matters more than it sounds. The alternative is sliding into full production without anyone explicitly confirming the conditions have been met, and that slide is common enough that most studios have at least one post-mortem that traces the root cause back to it.