Category: Game Production

About the Game Producer role

Featured by xavierfigueras, posted in Game Production

It’s really interesting how the role of a game producer it’s confusing to so many people. It’s a role that has been in the game industry for years, however, every time I ask a new employee if he or she’d like an introduction to the role, they really appreciate having it.

What I’ll share here are just my personal views, which have been contrasted with many peers from the profession over the years. I’ll be happy to get any additional insights in the comments 🙂

What does a game producer, really?

Product Managers define the product that needs to be built, engineers craft the solution to meet the expectations, what does a game producer in this equation? what is the tangible outcome? In my eyes, the overall team.

Let’s go down to the basics, let’s say you are three people team and want to create a game, do you really need a producer? yes and no. What you really need is a way to fulfil the hands-on roles: product manager, game designer, game artist (here we can include concept artist, 2D artist, animation, etc.) and of course programmers and testers, all together will in the end be the ultimate responsibles for crafting the software, however, as the family grows, you might experience inefficiencies in the overall system, and here is where a role of a game producer can come really useful.

Is the primary job of a producer to build a highly effective team. As said before we already have team members focused on the WHAT, others focused on the HOW, is your responsibility as producer to make sure these two worlds merge effectively and the resulting combination turns out a high-performant system, able to deliver qualitative product increments in a fast pace of work. That’s why here I talk about a ‘how’ at an overall level that involves many other crafts.

The primary job of a producer is to build a highly effective team

If you stop to think, what is really the difference between a tech producer, feature producer and let’s say a cross-team game producer? in the end they all share the same goal, which is to keep the team unblocked and productive as close to 100% of the time as we can, working on the highest priority items they can work on with all the information and context they need in order to do so.

And yes, this also means that the role of a Scrum Master or an Agile Coach aren’t at all that different from a game producer. From my point of view they all have very different contexts, and, at the same time, they all share the ultimate same goal.

What is the difference between a good game producer and a great game producer?

A good game producer will remove impediments for the team, ensure we are working on the top priority items and support in case there are any conflicts within the team. A great game producer, on the other hand, will think out of the box and enable the team to flourish and reach its unique highest potential. This means that it will continuously challenge the ways of working, also him or herself, actively listening to ‘what is trying to happen’ and putting the team in the center of everything he/she does.

A great producer will remove dependencies by setting autonomous and mature development pipelines, by doing so, he or she will also be also making himself/herself non-essential in the process. Paradoxically, the team’s ability to operate and improve without a major involvement from the game producer is in fact one of the best KPIs that will distinguish a good producer from a great producer.

Does it mean we have to delegate all work to the teams? Not really, what I am saying is that’s the target state, a great producer will be able to determine its degree of involvement based on the team current status and will have ability to gradually transition towards a more autonomous structure as it makes sense to the team. This is the reason why the top priority of a producer when landing a new job is always to observe and ‘meet the team where it is’.

bUT WAIT A MINUTE, ISN’T THE PRODUCER ROLE TO HELP THE TEAM PRODUCE MORE? SHOULDN’T IT SOMEWHAT RESULT ORIENTED?

Indeed, it’s the producer’s job to continuously help the team deliver more, which is usually measured through team’s velocity. If the team velocity increases it’s an indicator that your team is increasing delivery over time, at the same time we need to be very careful on how we use that indicator, otherwise it might bias behaviours at many levels of the organization unintentionally. Judging a team by its velocity could be somewhat similar to judging a book by it’s cover, it’s an indicator, and as such, it’s needs to be used wisely, for instance as starting point for raising questions to the team so that new information can come out.

Judging a team by its velocity it’s like judging a book by it’s cover

Faster delivery doesn’t necessarily mean you have a great ‘machine’ to operate, but having a great ‘machine’ to operate will increase the chances to deliver faster. This is the reason why I set the focus on ‘having the machine right’ in the first place.

OKAY SO, WhAT’S THE DIFFERENCE BETWEEN AN AGILE COACH AND A GAME PRODUCER?

Historically the role of a game producer has been described as ‘ninja’, abstract as such is not a good sign. The video game sector has not stood out by it’s ability to create a sense of order and alignment, all the opposite, what we found most of the times was fuelled-in passionate teams with no clear direction or sense of alignment, abandoned to the fate of working countless hours in the so famous ‘crunches’ in video-games. The role of that ‘ninja’ was in most of the cases lost in the operational level, running an active part in managing backlogs and leading the team, rather than being strategic from the very beginning.

Over the years the role of the game producer has received the influence of the agile movement, systemic coaching and management 3.0 principles which somehow enriched the role and helped it find its place into the big picture. The role of a game producer has being organically transitioning from an ‘active role’ to a ‘lead by example’ role with greater levels of delegation.

As I was pointing out earlier the difference is pretty much based on the context. While an agile coach is someone usually hired to act as consultant with a very specific purpose, a game producer it’s usually part of the team, hence it’s ability to influence and detect opportunities to move the team forward will be critical. Furthermore, a game producer will normally possess a specific background on the games industry, has good knowledge of the places where the project can go side-ways and will also be able to go deep into the pipeline processes to make them better, which might take a long while for someone unfamiliar with the context of crafting games. Last but not least, a game producer requires an understanding on the creative disciplines and might also get involved in project budgeting, live operations, and many other product areas.

Isn’t the game producer some kind of project manager?

Isn’t cyan color blue at some point? being a project manager is just one or the multiple hats a producer must wear, which by the way can be worn in many ways, and won’t definitely define you. As we have seen previously there are many aspects related to processes, team and product management that are far beyond the concept of project manager.

The way to manage ‘project manager’ responsibilities within the team will differ from one producer to another, also depending on the levels of unpredictability a company is able or willing to handle.

THE RESPONSIBILITIES OF A GAME PRODUCER

Although ultimately a producer will be judged by the team’s ability to deliver, there are many other responsibilities on the way, from forming strategies and communicating them, through motivating teams and individuals, to managing stakeholders expectations. This means the producer will be heavily involved in coordination, game design support and milestone planning.

Depending on the case, a producer might also be in charge of budgeting and resource allocation. Ensuring an efficient team’s allocation within the financial constraints will be key to set a baseline for success.

Last but not least, the producer will be in charge of setting the right processes in place. Creating the structures to enable the desired levels of alignment, focus and collaboration it’s ultimately a producer’s responsibility.

WRAPPING UP

As you’ve seen this is indeed a complex topic as there are multiple dimensions to consider plus it has being varying subtly over time. Hopefully the descriptions above gave you a greater idea on what’s expected from this role. Please do not hesitate to drop any questions or comments. Thanks for your time!

(header image by http://www.freevector.com)

Product Roadmaps – Book Review

Featured by xavierfigueras, posted in Game Production

Here you can find attached my learnings from ‘Product Roadmaps Relaunched – How to set direction while embracing uncertainty’.

What is the book about

Written by:

A good product roadmap is one of the most important documents of the organization, as it helps align stakeholders around product goals, giving a visual representation of a strategy. ‘Product Roadmaps’ comes to provide a detailed summary considering all aspects to be considered when designing one.

This is a book mainly addressed to product managers, but also useful for other roles who need to take care of the roadmap in order to communicate and manage expectations.

wHAT i LIKED ABOUT THE BOOK

  • It consistently works on the mindset behind product roadmaps. Stating clearly that a roadmap is not a project plan. Plus it goes to the why, talking about the importance of aligning it with the company’s vision and mission. The book explains how the themes and subthemes of our roadmap need to relate to the objectives that will in the end push toward that product vision.
  • The holistic approach when defining the contents of the book makes it a very well-rounded book. Plus it makes it easy to collect ideas fast with minimal effort. You can perfectly skip some pages and still get a lot of value out of it. Its combination of tools with ‘light theory’ provides a healthy balance that makes this book compatible with experimented experts and also beginners in the product management world.
  • The format is extremely friendly. It clearly aims to cover many user cases so that you can get the answers that you are looking for, and it makes it with images, charts, tables, etc. It makes the book very clear and easy to read.

What I disliked about the book

  • Although I understand that the product roadmap is quite a broad topic by itself, the way the contents are distributed around the book feels quite random. It would be nice if the authors had found some way to make it a bit more sequential. For instance, chapter 3 ‘gathering inputs’ could have been followed by chapter 8 ‘achieving alignment and buy-in’, and later on chapter 7 ‘prioritizing with science’.
  • At some point, I believe this book is not pragmatic enough when not mentioning at all engineering or the actual development teams, who are the ones responsible for making a technical assessment and setting expectations in the first place. I would have appreciated greater clarity on how all parts contribute to the roadmap rather than focusing on the product side only.

Summary and rating

This book handled multiple aspects of the roadmap in a very detailed manner, covering delicate topics and considering the different stages from ideation to the actual roadmap plotting. Clearly written and to the point, it’s a book that almost anyone can benefit from, however, I would have appreciated a better index and a natural involvement from the development side when defining a roadmap. If roadmaps are an interesting topic for you and your everyday life, I totally recommend this book.

Rating 4/5

The Hackathon Experiment

by xavierfigueras, posted in Game Production

Last week we run a Hackathon experiment at my company. The overall experience was a blast, it was my first time in an event this kind and honestly, it’s hard for me to understand how these sort of events do not take place more often everywhere. Here you can find what I learned from it.

First of all, what is a Hackathon?

A Hackathon is a collaborative engineering event where domain experts join efforts to come up with experiments in a relative short amount of time, usually 24 to 48 hours.

Gigantic ROI

Companies in general seem to be afraid of running this sort of events as in the end we are talking about tons of working days that are not invested in “what we are expected to do” so, why doing it?

Team Building

It was amazing having most of the team together in one place for an extended period of time without daily operation interruptions. We all had the possibility to interact and develop with different team members than the ones we usually do. By bringing our best into the group, the bonding level within the team became even stronger.

Creativity

Running this hackathon was another demonstration that wisdom lies within the team. Everyone had amazing ideas to bring the product to the next level. The end results shown a great variety of results and lots of ideas can now be taken into consideration for the final product.

Passing the ‘I don’t see it’ threshold

Sometimes talking about it or sharing slides it’s not enough, you need to spend a minimum amount of time to shape and make that idea real so that everyone can understand it better and get the deserved buy-in.

Actual Progress

It’s amazing to see the progress a team can do within a short amount of time. In most of the cases we can consider the work done as actual progress that can definitely be incorporated in the long term plan.

Increased Product Engagement

One of the things I love from the game industry is the level of passion of everyone around. When running this sort of events this passion connects with the product at a deep level, everyone has a much better grasp about the product and its potential behind.

PRODUCTION LEARNINGS

As said before one of the learnings is that is very interesting to see the progress teams can do in such a short amount of time. It shows multiple things:

The power of focus

By removing distractions and creating momentum, we are providing the environment where great progress can emerge. It’s also a demonstration that pair programming works well for exploratory projects.

No requirements experiment

Interestingly one of the factor that changes in these productions is that the communication between ideation and implementation is immediate given that ideation is run by the same developers in many cases. This means that the time invested into defining requirements it’s really minimum, and what really matters is the discovery process, adopting a more agile approach overall.

The time invested into defining requirements it’s really minimum, and what really matters is the discovery process, adopting a more agile approach overall.

About the hybrid format

In our case some team members could not come into the office for the event. Although they could fully contribute at every level in the same way, I still feel it’s an organizational challenge to make them feel as if they were in the office.

Conditions FOR success

Finally I’d like to share my view on what I consider were the keys for success.

With freedom comes great responsibility

The whole event was running very freely. All we were asking was for ideas minimally related to our product. During the event I got the feedback that when they felt so much freedom, they also felt the responsibility to come up with something valuable.

Product strategy

I saw other hackathons where the organizing team was trying to influence the proposals by incentivizing somehow. For instance: we are looking for the best solution to increase engagement. By bringing a push into certain goals we might be missing the cost of opportunity, and many good ideas might never see the light.

My takeaway here is that is good to share about the product strategy so that everyone can consider it during the ideation process, at the same time keeping the freedom spirit to blossom ideas in any other direction.

The right time

It’s important to be strategic and intentional in terms of timing. You don’t want to break the focus in the middle of other developments.

Great team

Fortunately in our case we were counting on mature senior teams with great ability to self-organize, ideate and a strong determination to bring ideas to completion. These are really important ingredients to make the recipe work, the credit goes to them!

Processes: Between Chaos and Order

by xavierfigueras, posted in Game Production

What is a process?

A process is any kind of event that takes place with the purpose of giving structure, it could be a document, a meeting, or simply an action among a few individuals with a specific outcome.

When should I review my processes?

Constantly. Given the self-evolving nature of any organization and their needs, it’s natural to adapt processes continuously. Here I would invite anyone to apply the PDCA cycle based on: plan, do, check and act.

Introducing processes: a delicate balance

Processes come into place to establish order and remove uncertainty. At first sight one may think that of course we want as much order as possible and therefore as many processes as possible. However they come at a cost. Introducing processes by definition will bring constraints and boundaries in all operational aspects, reducing the margin for adaptability and flexibility in the organization. Therefore we need to target the right balance considering:

  • What is it that we are trying to solve?
  • What is the benefit hypothesis?
  • How is it being done right now?
  • What is the buy-in for a change?

For this reason I highly recommend working with more people to brainstorm ideas and come up with better solutions that are tailored to the organizational needs. There is no one for all.

So, how would the processes for introducing processes look like?

  • Problem framing: what is it that has changed? where is the problem? why? let’s make sure we have the full context.
  • Brainstorming: let’s gather ideas to solve the problem and come up with a proposal.
  • Selling: to get organizational buy-in before implementing.
  • Landing: phase where all processes fall into place, can be a sudden change or gradually.
  • Operating: here the process reach its full potential and it’s deeply understood by everyone.
  • Evaluating: here we are in a position to do an assessment and iterate.

In my experience

Between boredom and freedom

I have witnessed how extremely well structured organizations led at some point to boredom and messy organizations came with a feeling of freedom. More than that, it’s proven that teams are more efficient when the right balance between those two extremes is met.

The ‘too many meetings’ syndrome

It’s interesting how in many organizations the same problems or sayings repeat, in this case the ‘too many meetings’ one. Here I would kindly invite to dig deeper: what meetings? and do an exercise where we classify them with their ROI in team members eyes and understand exactly where is the leak in the process so that we can adjust accordingly. Is it in the contents? is it in the format? In the end, no one loves meetings or rules but we need them due to the value they provide.

Help understand the purpose

There are times that teams miss the final goals. It’s never enough of sharing the purpose of a process. A classic one is the daily standup, which only purpose is for the team to sync and not a reporting one. Does it feel natural sharing what you did yesterday? does it bring any new information to your colleagues? if not, skipping it’s fine.

Meet them where they are

Before helping others understand it’s important to understand them in the first place. How are they perceiving their current processes? What is the culture? for any implementation to be successful you need to connect at a deep level before applying any change.

It’s all about value

If we do the metaphor of an organization as a person, I like to think of processes as the brain organ. Certainly we don’t produce while having a meeting or creating a document, at the same time we need that to make sure we are having the correct approach or going into the right direction. And here I invite you to think: is your organization too focused on the thinking mode? or is it running just flat out?

To understand if we are ‘too much’ into one direction or the other, we need to come back to the purpose: how is it helping me deliver more value? We should always be able to answer that question when introducing or modifying a process.

Improving your processes will help you organization achieve increased levels of engagement and efficiency, reaching a higher sustainable development pace.

Agile Game Development – Book Review

by xavierfigueras, posted in Game Production, Leadership

The Game Production subject I teach ‘Game Production’ at TecnoCampus as College Lecturer it’s based on a book called ‘Agile Game Development’. Here you can find my thoughts on it.

What is the book about?

The scope of the book it’s quite broad: starts sharing a historical perspective on how the game development has changed over time, explaining the impact agile had in the game industry and constantly relating to the experience of the author: Clinton Keith.

For those who are getting started into agile, ‘Agile game development’ offers a deep introduction to elemental agile related aspects such as the methodology (scrum, kanban and lean) and the product backlog, all of it in a gaming context.

Clinton Keith did not only stick to the basics in this book. He went above and beyond explaining how self-organized teams look like, how to scale agile, and gave an introduction to agile best practices such as extreme programming.

What I liked about the book

  • Undoubtedly the top takeaway from this book is the multiple examples it offers putting agile into the game context. Not only from a artefact perspective (user stories and roles) but also exposing usual production mistakes and how agile helps preventing them.
  • Its all-in-one approach it’s very adequate if you are getting started as producer. If you are experiencing ‘first time’ challenges, this book will most likely solve your questions.

What I disliked about the book

  • The book chapters are not synthetic enough. By trying to cover all possible ‘use cases’, it fails to communicate clearly the final message. I believe other books like ‘The Agile Samurai’ and ‘Agile Coaching’ can help you understand the exact same concepts in a much more concise and better structured way.
  • Not all chapters are treated with the same depth. I could not find the level of detail observed in scrum and user stories when going through the self-organized teams and scaled agile parts. This is a book that could have been easily divided into many, giving a more balanced level of detail.
  • Mixing concepts with examples of what not to do. Although I understand the good intention behind sharing personal experiences, at some point it turns out confusing and do not add value when those experiences relate to bad practices. I would have appreciated a ‘this is the theory’ and ‘this is how it’s done’ simpler approach.

Summary and rating

In spite of its complexity and lack of conciseness, it’s all-in-one approach and its multiple game related examples, make of this book a unique partner for anyone who wants to get started in any of the aspects related to agile game development. If you are already an experienced producer, I would recommend you to get specific books specialized on your topic of interest.

Rating 3/5

ABCD Trust Model

by xavierfigueras, posted in Coaching, Game Production, Leadership

Designed by Ken Blanchard, the ABCD trust model sets out the four elements of trust that are critical to creating and sustaining trustful relationships. They are the following ones:

Able – Demonstrate competence. Leaders who are able earn trust by solving problems,
getting results, and using their skills to help others achieve established goals.

Believable – Act with integrity. Leaders who are believable earn trust by being honest and sincere, showing respect for others, keeping confidences, not talking behind people’s backs, and admitting their own mistakes.
Connected – Care about others. Leaders who are connected earn trust by showing
interest in others, asking for input, listening, showing empathy, praising others’ efforts, and sharing about themselves.
Dependable – Maintain reliability. Leaders who are dependable are organized, timely,
accountable, and responsive to requests; they do what they say they’ll do and consistently follow up.

Ken believed that by taking care of these 4 key aspects, we’ll be building a trustworthy relationship.

An Application

Personally I come back to the ABCD trust model every time a leader asks for feedback. In fact, we were even using it as part of an assessment tool during my stay at Roche. What we did was to break down each of the elements into 7 questions or statements. Some statements related to ‘connected’ would be:

  • Listen well
  • Praise others’ efforts
  • Show interest in others
  • Ask for input

In total we had 4 elements x 7 questions per element = 28 questions. If that’s too long for you, you can always cut a few and keep the most relevant statements for each element.

In any case we’ll get to cover the most important aspects for any leader in a relatively short time, therefore the return on investment (ROI) it’s high.

CONCLUSION

As you can see the ABCD Trust Model comes as a powerful and easy to remember tool that can be pulled at any time, responding to important questions that will bring the relationships to the next level.

Want to try it out? If so, if so, please let me know how it goes!

No Rules Rules – Book Review

Featured by xavierfigueras, posted in Game Production, Leadership

In this article I am sharing my learnings after reading ‘No Rules Rules: Netflix and the culture of reinvention’.

What is the book about?

In this book Reed, Neftlix CEO, introduces us how he set the ground for success to create an innovative culture. After seeing how companies such as Nokia, Blockbuster and Kodak failed to innovate, Reed tried a radical approach, and its success story it’s a source of inspiration to many other companies nowadays.

The book co-author, Erin Meyer, is well-known for her work in the previous book ‘The Culture Map’, which has also been remarkably successful, and brings this ‘No Rules Rules’ to the next level with her cultural knowledge background.

What I liked about the book

  • The book consistently highlights the pros and cons of each decision that was made and the context where it’s useful. So it’s clearly not a one-for-all approach, and it makes it easy for you to understand whether the strategy he adopted can fit into your organization needs. Still there are many points that can come useful to any culture, such as the initiatives and feedback framework, which the book exposes consistently through multiple examples.
  • I like the well-structured approach, separated by phases where each phase connects with the next one in a very logical way. Starting by creating the talent density, continuing with the team dynamics, and eliminating controls gradually.
  • I got plenty of learnings such as ‘seek to please the business goals, not your boss’. The live 360 feedback and the importance of honest communication from the company perspective, although it can come though at times. Last but not least, how to make of your organization a jazz band where anyone can shine and bring what’s best for the business at any moment.

What I disliked about the book

  • Although I liked it’s structured approach, reality can come a lot more simultaneous and chaotic, more if you are part of a big organization, at some point the book seems to dismiss that part.
  • At times the book can feel ‘excessively positive’ as the number of success stories overcomes the number of challenges broadly.

Summary and rating

After reading it I must say it’s the best book I’ve read during this year, so I totally recommend it to anyone who is looking to get a deeper understanding on how to foster a more innovative environment.

Rating 5/5

I consider the points to improve very minor.