What does a video game producer do?

The role of a producer in the games industry is still poorly defined, and different companies have their own definition of what a producer does. In most cases, a producer is akin to a project manager, and ultimately responsible for the planning and execution of a project.

In some companies, however, a producer is also product-orientated, responsible for tying together the various disciplines of game development – art, engineering, design, project management, and so on – into a single thread. They’ll ultimately make sure the right decisions are made, given the funds available and constraints in place. In other companies still, a producer is a team lead and people manager, with the responsibility of leading and coaching a happy and effective team.

There are varied definitions of the producer role (or development manager, as some companies title it), but there are three primary skill sets that are needed regardless of production flavour:

Project and budget management: The ability to scope, plan, and execute a project with control over schedules and budgets.

People management: The ability to manage people, including both team management and stakeholder management. A good producer needs to know how to build and foster good team dynamics, provide critical feedback, offer support when needed, sell a vision, and resolve all kinds of people-related challenges.

Product awareness: A knowledge of video games and the craft of making them well enough to support and challenge the creative process. Many producers in the industry would argue with me on this point, but I do believe that a passion for video games and an eye for quality will make you a better producer. I’ve worked with some exceptional project managers who don’t have a passion for games, and their solutions to scheduling problems tend to be somewhat black and white: cut scope, raise budget, move timelines.

By contrast, producers with a love of games, and an understanding of how they’re put together, tend to find better and more creative solutions to problems. Learning to understand games is the easiest thing to achieve, in my opinion: play a lot of games, have opinions on what you play, and learn how they’re built. You can do this through experience and curiosity on the job, and by talking to the creatives who specialise in different areas of development.

So with that out of the way, what does it take to be a good producer – and how do you become a good manager of people? Let’s take a look.

Being a good producer

Over the last few years, talk of Agile development has become all the rage in video game management circles, and it’s largely misunderstood. Similarly, there’s long been a divide between people who follow Agile methodologies versus those who favour more traditional, long-term planning approaches (or Waterfall methodologies, as they’re known).

I’m personally a fan of the Agile manifesto (agilemanifesto.org), and feel its principles are ideal for most situations. But I also think the ‘by the book’ approaches that have been built around the Agile manifesto don’t work under the realities of most games projects. Similarly, traditional Waterfall methodologies seldom work, either.

On one side, you almost always have a fixed budget, a fixed release date, a publisher who expects an understanding of long-term milestone deliverables, or a complex web of long-term interdependencies that many Agile frameworks just aren’t set up to control. On the other hand, any creative endeavour requires change, iteration, and experimentation, and traditional Waterfall methodologies aren’t equipped to allow for this.

In my experience, a good producer isn’t an evangelist for any one philosophy, and knows when to mix a little bit of both and to what degree. In nearly all game projects, you want to maintain a long-term view that keeps your stakeholders well informed and your dependencies well mapped out, while allowing for plenty of flexibility in the short term.

While each project is different, my philosophy for this has always been:

• Plan as far in advance as you can, with the information you have available, making assumptions where you need to. This is your baseline plan.
• Re-prioritise regularly based on current needs and adjust your long-term plan accordingly. This allows you to have good conversations with your team and stakeholders about how your short-term priorities are affecting your long-term plan, and why.

To manage this, I tend to advocate for the following three documents to be maintained throughout the life cycle of almost every project:

• A project backlog (or scope document): A list of all the features you have planned for your game, prioritised, with estimates from all teams. Where solid estimates can’t be given, best-guess estimates should be provided. It’s better to have best-guess information for planning than no information, and it’s important to get your team comfortable with this concept (and not make it uncomfortable when best-estimates are inevitably inaccurate).

This backlog should also contain a calculation of developer time per team, split across your project’s milestones. This should take holidays into account, accommodate some level of time for iteration or things going wrong, and carry an understanding that people don’t sit at their desks throwing out code for eight hours a day. It should also set time aside for bug fixing.

Read this

When it comes to managing people, it’s always worth gaining some experience with basic human psychology, particularly in terms of how it impacts a team dynamic. One book I’d recommend to any potential team leader is Patrick Lencioni’s The Five Dysfunctions of a Team. It’s one of the most useful books on team dynamics I’ve read, and demonstrates the critical importance of dealing with issues quickly. It provides a good lesson on why getting somewhat comfortable with providing difficult feedback is a critically important skill.

With both of these in place, you can draw a tide line through your features backlog, showing what is in-scope and what is out-of-scope based on priorities and developer time available. This should be re-evaluated at least once per milestone – once every four to six weeks depending on how you’ve structured your project timeline, with finished work closed down, estimates updated, new features added, etc, so you and your team can see how short-term realities have impacted your long-term schedule. This gives you the info you need to address any big issues, like critical features falling out of scope, as soon as possible.

• A project schedule (or long-term plan): A map of all milestones in your project, showing which features will be developed when, and dependencies between work where needed. This is critical to understand how milestone changes are impacting your long-term plan, and to properly prepare for any external work such as outsourcing. In line with your project backlog, this should be updated at least once per milestone.
• A risk log: A list of all risks you’re tracking that could impact your long-term project schedule, or delivery of your upcoming milestones. It’s important to discuss mitigation strategies for risks on a weekly basis, and put them into action to mitigate the chance of problems arising that have the potential to disrupt your plan.

As alluded to above, it’s common to structure your project into milestones and sprints – milestones providing a framework for a stakeholder review process and the closure of major features, and smaller sprints as a mechanism for teams to track and evaluate their own progress within milestones.

The framework outlined above is intended to maintain the best view on a long-term plan, even if it’s based on uncertain information, and continue to update it as new info appears. It’s there to provide flexibility in the creative process, but with a mechanism for raising potential issues so they can be sorted out.

The big takeaway from all this? In my experience, people who stick to one approach tend to be idealists, lack hands-on experience, or don’t understand the realities of making games. A good producer should understand a range of methodologies and when to bring the right methodology to bear for a particular team and problem. That said, the above framework is good practice for most projects where an unknown creative endeavour is being developed under fixed constraints or with stakeholders to manage (in other words: almost every project).

People Management

Managing people is another critical skill for a good producer. There are no set methodologies to recommend for this, other than the advice that it’s important to practice empathy, be open, honest, and vulnerable with people, and additionally to get comfortable giving difficult feedback.

I practice a philosophy of honesty, as do most good producers that I know. I’ll actively praise good work, I’ll tell someone (with empathy and caring) when I disagree with them or feel their work needs improving, and I’ll aim to be open about the decisions I make and why I make them. A producer is often seen as a leader, and a good leader is genuine, honest, and trustworthy.

One of the most important and most overlooked points here is the need to be honest with people when their work isn’t good enough or their behaviour is negatively affecting the overall team dynamic. Most people struggle to give difficult feedback, but the timely feedback of poor performance is one of the most critical aspects of running a happy and effective team. Unfortunately, it’s rarely done quickly enough or well enough. Getting yourself to a place where you can do this, with empathy, is absolutely critical if you’re going to run an effective team and save yourself and your team a lot of wasted time and pain in the long run.

To sum up, then: the production discipline in games can be a bit of a mess, and you’ll find producers, project managers, and development managers whose jobs range from the hands-off to the thoroughly creative (I’ve done a fair amount of narrative development and writing in my time as a producer, for example).

Still, having a good grasp of project management theory and application, developing solid people, leadership and interpersonal skills, and getting to know and love games, are all critical skills, no matter which company you’re at or the responsibilities that define your role.

My parting advice: take those who evangelise a single project management style with a pinch of salt (but learn them all and when to apply them!). Be aware of apathetic producers or leaders (giving difficult feedback requires empathy, but is still necessary), and take time out to fall in love with games. If you’re improving your skills in these three camps, you’re on the path to be a great producer, regardless of where you are in your career. Be passionate, care about what you do and the people you work with, and learn the art of long-term planning with short-term flexibility.