Project Steering for Games

The Games development is a highly competitive global industry; with hundreds of games launched or updated every week. To achieve anything more than mediocrity requires the entire value stream of game development to be working together effectively with each individual along that stream delivering a stellar performance. Maintaining a healthy company balance sheet, means each game project needs to have solid indicators of future success before significant time and effort is sunk into it. The Project Steering approach described in this article was something I helped to design and implement to keep multiple game projects on track while allowing those game projects the flexibility needed to find the next hit game. 

Context on company structure

The year was 2017. Game teams were the basic building block of the company. Generally, each game project was executed by one game team. Each game team was deeply cross functional including people who can cover the following as a minimum: design, development including engine development, QA, art, marketing, analytics. Each team was led by a Product Manager (effectively Product Owner and Team Lead). There was a strong emphasis on the PMs being servant leaders, who grow and develop a self-organising team. What I observed in games was that everyone was very passionate about the game they were developing and wanted to have a say in the direction it took. While this passion is intoxicating it could also lead to chaos; this why the Product Managers (PM) retain authority to make decisions. Retaining creative control ensures that the product follows a clear vision. 

Objectives of the Project/Product Steering approach

• Ensure each game team is focused on regularly assessing if their current project is the best use of their skills, time and effort.
• Balance the autonomy of new Product Managers (PM) with the control mechanisms that prevent significant mistakes from occurring. 
• Support the Product Managers and teams to maximise ROI for the company over the long term; through feedback and guidance from experience leaders within the company.
• Transparency of project Steering so that the whole company can choose to be aware of what is going on and learn from the success/failures of each game team.

Monthly Product Steering meeting

The key element of the Product Steering approach was a monthly public meeting held for each game project. During the meeting the Product Manager or a representative from the team presents from a standard template. The primary attendees are the Product Steering Committee*; however the meeting is public so anyone from the company may attend. The Product Steering Committee asks clarifying questions and provides non-binding feedback and guidance. Initially everyone apart from the Product Steering Committee was asked to observe only. Over time this gradually changed first with specific audience members being asked questions, then later open question time at the end of the meeting. 

These meetings were scheduled for 1 hour and some of the early ones took that long. However, in the matter of few months they were regularly completed in 30 minutes including question time.

Product Steering Committee

The Product Steering committee was composed of senior leaders who held a vast depth of experience in the games industry from around the world. I was also included; initially to help refine the template I had created for the meeting and after that stayed on as me asking the questions a 5-year-old would ask seemed to provide some value.

• CEO
• CFO
• CTO
• Head of Product Development
• Head of Business Intelligence
• Agile Coach

Preparing for the Product Steering meeting

While the Product Steering meeting was often insightful and helpful for all involved. The act of preparing for the meeting also provides a lot of value; especially for those Product Managers who were considering not holding a meeting. Often their desire to not hold the meeting is a subconscious move to avoid facing some uncomfortable facts about their project. 

Another positive aspect of the preparing of the meeting was that the Product Managers often reached out to members of the Product Steering Committee for assistance with preparing their presentation. These interactions were a chance to learn from each other and improve the direction of the project.

Regular feedback

Completing the Product Steering approach was regular 1 on 1s and feedback from the Head of Product Development to the Product Managers. This is massively important for less experience Product Managers and still very useful for the remaining Product Managers.

Common Presentation Template

The template was a two-page slide deck that provided answers to the key questions the Product Steering Committee wanted to see from every game project. Without answers to these key questions the committee members would struggle to provide effective feedback and guidance. Creating a consistent template helped both the Product Managers and the committee. For the PMs it cut down their preparation time, for the committee it meant they did not have to translate the information provided to them in different formats by different PMs. Additionally, it meant the committee had could compare game projects.

The PMs were free to add additional slides showing whatever detail they felt appropriate. Roughly three quarters of product steering meetings include extra information; such as partnering deals, highly feature maps, results of experiments etc.

Page One:

• Product goal in one sentence
• Declared intention (Persevere, Pivot game, Cancel game)
• Sub section seeking input from Product Committee on specific topics
• Product Health
• Is the team learning what their customers will respond to?
• Is the team delivering with suitable throughput?
• Team Health
• Overall morale
• Specific issues affecting them
• Financial summary, last three months
• Costs, revenue, ROI
• Projected financials, next month with certainty, next 6 months with low certainty
• Results of objectives
• Were last month’s objectives completed?
• Did those objectives change?
• Objectives for the coming month.
• High level deliverables, learning outcomes, etc.

Page Two:

• High level road map of deliverables, experiments, deals, etc. 
• Current quarter was more detailed and showed when items were completed.
• Next two quarters were highly level and subject to significant change