Product in Free-to-Play Mobile Gaming – The role and impact of our Product Managers
When we talk about product in general, we are most often referring to something that is useful to have. In gaming, the view of product is slightly shifted. Playing games is not ‘useful’ per se, but a game as a product is something for users to play with and enjoy. It is entertainment.
When we develop new gaming products, we have to think about player behaviors, in particular the ways in which we can engage them and keep them in our games. Because we make free-to-play games, and want them to be accessible to everyone, this makes the challenge even more difficult.
How can we design and build a product that is free to play for everyone, where every aspect of the game works as the users want and expect it to? How can we then turn user behavior into actions which will in turn be profitable for the company? These are the types of questions driving decision-making of our Product teams.
To dive deeper into the world of Product in mobile gaming, we talked to one of our Product Managers (PM), the lovely and talented Ecem. Since she joined us in early 2024, Ecem has been a key part of building-up Lily’s Garden, and has more recently switched to supporting our new game productions.
Ecem’s role as Product Manager covers a wide span of responsibilities, including new feature development, working closely with level design, A/B testing of existing features, configurations and even analytics. She’s basically responsible for everything new that is being developed in the game, as well as releasing new features and ensuring that they perform well and keep improving once live in the game.
Let’s dive deeper into how Ecem and our Product teams do that.
New feature development
In free-to–play (F2P) mobile gaming, coming up with a new product (new game) is just the starting point. As mobile game players typically engage in shorter play sessions and show different play patterns compared to console or PC games, the developers need to find a way to maximize the time that the players spend in their game. This is why there is such a huge focus on live game operations in the industry right now – continuously releasing new in-game features and new ways of playing makes a game feel alive and keeps the player experience fresh and exciting.
A live game will make players spend more time in it and this extra investment of time will help them unlock more achievements in the game (both in the short and long term). This is where the psychological aspect of user experience comes into play: Our time is precious and so the more time we spend doing something, the more likely we are to invest into it even more.
Understanding the game
For Ecem, as the Product Manager, the first step on the path to achieving this is knowing her game really, really well. She does so by playing her game and its key competitors every day, following the data (it changes on a daily basis) and questioning everything she sees. ‘I always ask myself, what am I seeing and why? Why was this data point at a different place yesterday, how has it changed over time, and where would we like it to go? This is what’s driving all of my decision-making,’ says Ecem.
And this does not apply only to her game, but also to the industry that we operate in. Being familiar with our key competitors and what they are doing is important because it helps her to understand where others have found success and why. This is not in order to copy what others are doing – we shouldn’t include a concept into our game just because it works well for someone else – but we should understand their decision making behind doing so and how this could potentially be translated into our own game.
Understanding the goal
After understanding the product and the market we operate in, it’s important to understand the end-goal of any new product developments we’re making. Why do we want to add a specific feature or a new event to the game? Is it to fulfill a more short-term goal, something that is linked to our core gameplay (i.e. collect 100 specific board pieces in an hour, either as a single-player event or a tournament with a leaderboard). Or is it to achieve a long-term goal, such as engaging players in the narrative of the game?
Whatever the end goal might be, the new feature should tie closely into that. Some features are scheduled and present in the game for a limited amount of time, others are in the game all the time and players can engage in them whenever they wish to (like the indoor redecorating feature in Lily’s Garden). They are both equally important and have to be balanced in the right way, as they impact player experience. And as we’ve already learned, player experiences impact player behaviors, which in turn impact the engagement and monetisation aspects of the game.
Understanding the feature
Once we understand our end-goal and what we want to achieve with this new feature, it’s important to really focus on the market again and see what our competitors are doing. This doesn’t have to be only other games in the match-3 genre. As long as we share the same goal, any game is relevant. If we’re able to translate what they are doing into our own environment, we have created something unique.
From development to release
The development process of a new feature starts with building its wireframe. To do so, Ecem will have a long discussion with her product team to understand how feasible it is to build such a feature. What makes sense to build with the resources we have available, and what new resources might we need to make the feature come to life?
Minimum Viable Product
Once the wireframe has been agreed on, the team starts working on the MVP (minimum viable product), following the agile development approach. At this stage, we do not yet know whether this feature will work for us. To achieve this goal, we must first understand what we need to build as a minimum. We have a certain amount of resources to do so – a certain amount of time, a team including programming, art and UI, as well as a limited focus (for example, developing only the core of the feature for the first MVP).
The level of polish going into the MVP will very much depend on how ‘old’ the game is. Releasing a very unpolished, raw prototype of a feature in an older game that is already very polished is a no-go and might cause more damage than good. In a newer game, which is not so scaled yet, however, we can release less polished prototypes and test them out.
Testing
When the MVP is finished and released, the team moves into testing. Ecem, as the PM, now needs to develop a strategy for the testing process. ‘When choosing a test for the MVP, we need to make the choice carefully. Testing any new feature in the game can have an impact on our revenue, so we need to be very specific when we’re setting up the test. We need to make decisions around what country we want to launch the test in, which user segment we wish to target and so on,’ explains Ecem. This is where the close collaboration with the data team comes into play. The PM and the data analyst(s) need to be completely aligned before launching the A/B test to real players.
After that, the waiting starts. For this stage of the experiment, the PM must again know and understand their game and the goal of the new feature really well. At this point, Ecem and the team need to decide on how long they will run this test for. This is because the data test requires a significant number of users to participate in it, in order for the results to be valid. For example, if the team is testing retention, 1k users is enough, but for a monetisation test, they’d need a minimum of 5k users.
Understanding the results
Once the test results are in, Ecem and the team need to analyse what they are seeing.
If the test results are positive, but not significantly so (if we ask ourselves: Is this feature going to really push the needle in our game and the answer is no), Ecem and the team need to consider whether to continue with developing and testing the MVP. ‘I don’t want to push our product to a dangerous point,’ says Ecem, ‘so in situations like this, we really need to understand the test results well and decide whether we want to continue going with a larger number of users.’ What Ecem means by ‘dangerous point’ is exposing more users to an unpolished new feature prototype in an A/B test and risking upsetting potential buyers. Again, it is crucial here that Ecem as the PM understands how well established the product is. With an older game, she needs to take more calculated risks, but with a brand new product, she can potentially be bolder.
On the other hand, if the test results are incredibly positive and we have reached our goal (this feature is going to shift the needle in a big way), the team will increase the number of users in the A/B test and start polishing the MVP. Just as when things don’t go well, it’s important for the PM to understand why things worked really well with a particular feature. This is an opportunity to get to know our users better, especially if we were targeting a specific segment. The team can then use these findings and apply them to other features in the future.
Release
After the initial test, the MVP will go through several iterations. The team works in a lean agile way and keeps polishing and testing until the feature is ready for global release.
Post-release (Live Ops)
The duty of our Live Ops team is to take the newly released feature and make sure it fits well into our players’ day to day experience of the game, optimising and tailoring it to different types of players to create the best experience possible. This is not an easy task. They need to first think about what kind of player behavior will be required to make this feature a success. After that, they need to find the right way to run the feature, so that it gives the best possible experience for players, as well as the best KPI improvements for the game. Often there is not a one size fits all solution for features. The Live Ops team needs to think about all the different types of player and playing styles that the audience has.
Already in the development stages of any new feature, Live Ops and Product teams need to be closely aligned. As our Live Ops function is centralised, they can provide the Product teams with the knowledge and insights from all of our games.
Our road to achieving LiveOps excellence
For 2024, we have set an ambitious goal for our Product and Live Ops teams: We wanted to release 1 new in-game event every month in Lily’s Garden. On top of this, we also release multiple features or updates to older features each month. This might have been a BHAG (big hairy audacious goal) and, depending on the size of the event or feature, not always a realistic feat, but ultimately, we wanted to get our production capabilities as close to this goal as possible.
This was important to us because having a wider range of features, events and offers enables us to create more tailored and varied player experiences within our games. We now have a strong Live Ops calendar filled with a variety of events, which has given the team a lot to work with.
The key component for us achieving this goal has been our lean agile development process and how we work with scrum. Changing our team structure and creating smaller, more effective scrum teams, led by our Product Managers, have been a huge part in us being able to achieve this goal.
So, what have been our key takeaways from this journey so far?
Key learnings
🔑 Test fast
Verify that the feature works as early in its development cycle as possible, before building it out more fully. We can use this early data to help make the feature even better and connect with players even more.
🔑 Using the whole team’s expertise
Within any Product team, there are different disciplines with different key focuses (art, development, QA), but they’re all part of making features a success, beyond just their discipline. It is the Product Manager’s responsibility to align them all, in order to reach their common goal. The different skillsets and mindsets should be used to make the overall experience for players and the performance of the features even better.
🔑 The Product Mindset
Everyone on the team needs to understand why we’re doing things in a certain way and where these decisions come from. If everyone fully understands the reasons behind a goal, they can make better decisions during its development. They also need to understand the different aspects of a product that all tie into making it a success, as well as the different types of players we have and their experience of the game.
🔑 Decision making
A PM in gaming does not have a single focus area and so will always need to have an overview of all the disciplines of product development (art, UI, programming, data, QA, Live Ops), and help drive decisions in all of them. A PM should not have an ego and be subjective in this process, but they should make decisions based on the knowledge of the game, the market and the general development environment they operate in.
🔑 Trust
The PM needs to build trust-based relationships with everyone on their team, as well as with everyone else they collaborate closely with (Live Ops, Marketing etc.). This enables them to fully align on their common goals and commit to them as a team. It also enables them to challenge each other’s decision making which in turn allows them to create the most optimal product.
