The following blog post, unless otherwise noted, was written by a member of Gamasutras community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

As more mobile game developers move into the F2P space or integrate IAP into their premium game, a common set of problems occur around process (or lack thereof) when it comes to designing for monetization. Many game teams I talk to or work with in my role as a monetization design consultant are working in F2P begrudgingly. They distrust the business model and this sentiment bleeds through to the game’s implementation, limiting their chance for success.

In my opinion, the ideal game development process on a game with IAP will consider monetization from day one. Not only will the design of the game as a business be considered from the outset, but each member of the team will embrace the business model in their work. This does not mean starting your first discussion of the game with the question “how do we milk our players for all they are worth?” Instead, it means that each member of the team recognizes that success depends on a game that forges a long term relationship with the player and is unafraid to ask the player for money when appropriate.

This idyllic vision is at odds with what I tend to see out in the real world. In practice, there tends to be one person on the team responsible for the money side of game design. This person (be it product manager, producer, CEO or other) leads a frustrating life where she is constantly suggesting ways to improve the game only to be shot down by her teammates, or fighting to get a small part of her overall ideas implemented. This results in a compromised game where monetization elements are hidden from the player or overall lacking, and can result in the failure of an otherwise good game.

Successful monetization design needs to be the responsibility of all members of the game team. A thoughtful game design process can be a strong tool for ensuring that monetization is integrated into the game’s design from day one.

Feature conception

I have written previously about how to kick off a feature’s design with a one to two page feature brief. In this document that pitches the feature at a high level, the writer should be required to write out two sections that may be unfamiliar or uncomfortable if new to monetization design. The first is a KPI section (key performance indicator). Here, the designer describes what one key metric this feature is designed to improve: game quality, monetization, player retention, virality, player engagement, etc. Each team must decide on the KPIs that are important to them. I always caution not to fall into the trap of promising that a feature will do everything; this is the sign of a design with no strong choices. Instead, be sure to call out the KPI the feature will be specifically focused on improving.

The second section is key metrics. The designer should be forced from the very beginning to describe how he will measure the success or failure of the feature, and how he will collect data that will allow him to improve it. A common pitfall I see is the desire to capture lots of data with no intention for how it will be used. Instead, list the specific questions you will answer with data, and then figure out the data that will allow you to answer those questions.

The product owner should not consider a feature brief complete until it contains satisfactory answers in these two sections.

Feature development

Once a feature is put onto the product backlog, there should be a column for KPI. When determining priorities and selecting features to implement, it is the product owner’s responsibility to ensure that the game’s composition is balanced between the KPIs and that the team is not only working on features to improve game quality (which tends to be the natural inclination for game teams).

As a feature brief is developed into a full feature treatment, the product owner must review and make sure that the fleshed out design stays true to the original intention and will, in fact, improve the target KPI. The feature’s designer should work with a product manager to determine specific metrics that will be collected for this feature. They should generate dummy data for this feature and produce a sample graph/analysis to prove that they will be able to create insight from data.

As the feature is implemented, it should be reviewed for both quality and KPI potential. If a feature is intended to improve conversion of non-payers to payer, but when implemented does not give a player a compelling reason to spend money, then it is not complete. Additionally, the metrics implementation needs to be tested and verified. Having buggy data that leads you to incorrect conclusions is the only thing worse than having no data at all. Only once a feature is functionally complete, fills its strategic goal and collects actionable data is it considered complete.

Launch and iteration

Once live, a common pitfall is to launch a feature and move on to the next without ever reviewing the data and determining if it was a success or failure and how it can be improved or if it should be cut from the game.

I think that the standard scientific method is an ideal template for reviewing a feature’s actual performance in player’s hands. Before a feature goes live, the team should have a hypothesis, a specific prediction based on the original KPI intention. If a feature was designed to improve conversion, then a hypothesis would be “Feature X will improve conversion to paying players by 10%.”

After the feature goes live, the designer and product manager should review the data and report out on its performance and next steps to the team. Without this level of follow through, the entire process is meaningless. The report should combine analysis of metrics data along with any specific fan feedback that can be collected from game reviews, forums, Facebook, Twitter, Reddit or whatever method your players use to communicate with the team.

If the feature is successful, how can it be optimized? If it makes no discernable impact or has a negative effect, can it be improved? Or does it need to be removed from the game? Only with several rounds of feedback, analysis and iteration can a feature reach its true potential.

In conclusion

The process presented here is high level and idealized. It will have to be adapted to fit the working style and talents on your team. The larger point, however, is that monetization and metrics must be a design consideration from day one and all members of the game team must embrace the business model for it to be a success. Only by overcoming our fear and mistrust of F2P game mechanics can we design a game that is right for the player while also creating a sustainable business that rewards game developers for their hard work.