Gamasutra posted a fantastic article on how to be a good producer. Producers get a bad rap because there are so many bad ones out there. Because you should never really notice a good producer (all the work is happening behind the scenes), it is just as easy for a producer to simply do nothing or be a slave to an MS Project file and claim ignorance. It’s also easy for artists and engineers to look at a producer as someone who doesn’t contribute to the content of the game except by fiat. That should never be the case.

I’d like to add a couple more good and bad qualities to the list Mr. Shin created, from my experience.


  • Listens. Many times when team members come to a producer, they need to vent about stressors that are piling up. It helps them to get their issues of their chest, but the producer is also the main guy/gal that can actually do something about it and connect disparate problems. There are too many producers who simply don’t want to hear problems so they can have plausible deniability or because the issues are someone else’s job. And there are too many well-meaning producers that are happy to be a sounding board without following up.
  • Lives in a cube. I bet you are gawking at this one, but probably two-thirds of producers I’ve worked with who have had offices instead of cubes have had poor communication with the team and inadvertently fostered an us-vs.-them attitude or were just generally out-of-the-loop.
  • Is a fighter. The producer should be the chief advocate for the team to any external group – licensors, publishers, senior staff in big studios, etc. The team should know that he/she will fight tooth and nail for the things the team needs and not just roll over because someone with power says to or because it is easy.
  • Should have programmed something before in their lives. It’s pretty obvious in meetings when a producer says “shouldn’t that just drop right in?” and engineers roll their eyes that the producer is either baiting or being naive.


  • Doesn’t believe there is much difference between a game project and any other software project.
  • Believes that being a video game fan makes them an authority on how to design and implement a game project.
  • Takes over design issues instead of being a mediator.
  • Values the trees (hitting all tasks on the schedule) over the forest (quality of game as a whole).

Leave a Reply

Your email address will not be published. Required fields are marked *

Human? * Time limit is exhausted. Please reload the CAPTCHA.