From Game Design to Product Management
When I first had the opportunity to become a Product Manager at Mega Studio, I wasn't particularly interested in making that transition. I was actually quite comfortable working as a Senior Game Economy Designer, a role I genuinely enjoyed and had spent years developing my skills for. I liked designing systems, balancing economies, analyzing player behavior, and figuring out how to make games both enjoyable and profitable. However, Ruben Gomez, the company's CPO at the time, had been telling me for a while that I was already doing considerably more than what would normally be expected from a Game Economy Designer. Looking back, he probably recognized that my responsibilities had gradually expanded beyond my original role long before I was ready to acknowledge it myself. :))
Eventually, I accepted the opportunity and stepped into Product Management. It wasn't an entirely unfamiliar world, considering how much of my previous experience had involved evaluating products, working with developers, and making decisions that influenced business performance. However, there was still quite a lot I needed to learn, particularly when it came to managing development teams, organizing projects, and dealing with the responsibilities that came with leading people rather than simply contributing to their work. Fortunately, I had support from Ruben, who helped me understand the management side of the role, and from Sabin, one of our Senior QA colleagues, who spent approximately two months teaching me how to properly organize and manage projects using Jira. I still remember how much I learned from him during that period, particularly about structuring development work, keeping track of tasks, and making sure that projects were managed in a way that made sense for everyone involved. Their support made the transition considerably easier, and it also reminded me that moving into a new role didn't mean I had to figure everything out on my own.
Experimenting with New Gameplay Concepts
At the time, Mega Studio was developing rewarded games, where the business model depended heavily on the relationship between user acquisition, advertising engagement, player rewards, and profitability. We had already worked extensively with relatively simple mechanics such as scratch cards, slot machines, and lucky wheels, but there was growing interest in exploring whether more engaging gameplay could improve our products. As I became more involved in Product Management, I started working on experiments that went beyond the mechanics we had traditionally used, including arcade-style games and competitive features that introduced entirely new challenges for our existing business model. It was an interesting period because I was no longer looking at these ideas exclusively from a Game Design perspective. I also had to consider the development effort involved, the resources required, and whether the concepts could realistically support the business model we were operating in.
One of those experiments was Golf Cash, a single-player arcade game built around a golfing mechanic. In many ways, the underlying business model remained similar to our existing rewarded games, but the gameplay introduced an additional layer of complexity. Instead of simply scratching a card or spinning a wheel, players had to interact with levels that required a certain degree of skill and planning. We were essentially trying to combine the accessibility of our traditional rewarded games with a more engaging experience that could give players additional reasons to return. Initially, Golf Cash showed some promising signs, and the idea of introducing more elaborate gameplay seemed worth exploring. However, despite that early potential, something still felt like it was missing. I was beginning to realize that making a game more engaging didn't automatically mean that it would perform better within the business model supporting it.
Conceptual recreation of Golf Cash gameplay (2022)
Around the same time, we started working on another arcade concept inspired by Fruit Ninja, which we called Slicer. The gameplay was straightforward and familiar, but this time we decided to explore a more ambitious direction by introducing competitive, paid, tiered tournaments. I initially had reservations about how well skill-based competition would fit the rewarded advertising business model we were operating in. Nevertheless, we decided to experiment with the concept, and I accepted the challenge of trying to make it work. After all, having doubts about an idea doesn't necessarily mean you shouldn't explore it, particularly when you have the opportunity to test your assumptions against actual player behavior. I also understood that being a Product Manager meant considering perspectives beyond my own and helping the team evaluate ideas based on evidence rather than personal preferences.
When Gameplay and Business Models Don't Agree
The tournament system was designed to be a central part of the experience rather than an optional feature hidden somewhere in the menus. We experimented with integrating the tournament leaderboard directly into the main menu, making competition a constant presence throughout the player experience. Players could see how they compared against others, follow their progress, and remain aware of their position even when they weren't among the top-ranked participants. The idea was to make competition an important motivation for returning to the game, encouraging players to improve their performance and continue participating. From a Game Design perspective, I could understand the appeal. Competitive systems can create meaningful goals, encourage repeated engagement, and give players reasons to invest more time in a product. However, the question was whether those incentives could coexist sustainably with the economics of rewarded gaming.
As we explored the tournament system, we encountered an important tension between competitive engagement and the economics of the product. The tournaments offered real-money prizes to a limited number of top-ranked players, with rewards decreasing according to their final position. At the same time, the competitive structure encouraged players to participate more frequently and invest additional time in improving their rankings. From a gameplay perspective, this was exactly the kind of behavior we wanted to encourage. From an economic perspective, however, increased participation didn't necessarily translate into proportional revenue growth. This created a difficult balancing problem. We wanted the competition to remain engaging and accessible, while ensuring that the rewards offered to players could be supported by the underlying business model.
What made the situation particularly challenging was that the problem couldn't be solved simply by adjusting a few values. We needed to consider how the competitive structure influenced player behavior, how rewards affected motivation, and whether the resulting experience could remain economically sustainable. We spent time exploring different approaches and trying to understand whether the concept could be balanced without undermining the experience we wanted to create. Eventually, after evaluating the results and considering possible adjustments, we concluded that the tournament approach wasn't sufficiently aligned with the business model. We also reconsidered our experiments with more elaborate arcade gameplay, redirecting our attention toward mechanics that were better suited to the products we were developing. Although these experiments required a meaningful investment of time and resources, they provided valuable insights into the relationship between gameplay complexity, player engagement, and economic sustainability.
What made this experience particularly memorable was that I had expressed concerns about the tournament concept from the beginning, but once we decided to move forward, I genuinely tried to make it work. I wasn't interested in proving that my initial doubts were correct. I wanted to see whether we could find a viable solution, and I was open to the possibility that the experiment might challenge my assumptions. Ultimately, the results showed that the concept wasn't sustainable under the conditions we were operating in, and we had to accept that conclusion. For me, this was an important lesson in Product Management. Having an opinion based on experience is valuable, but it doesn't replace experimentation, collaboration, or the willingness to evaluate an idea objectively. Sometimes an experiment confirms your concerns, sometimes it proves you wrong, and sometimes it reveals problems you hadn't anticipated. What matters is being able to learn from the outcome and make better decisions afterward.
Learning the Other Side of Management
While all of this was happening, I was also discovering that Product Management involved responsibilities that had very little to do with designing games or experimenting with new mechanics. Until then, I had spent most of my career working alongside developers, artists, and other designers, concentrating on solving problems and building products together. Moving into management meant that I was now responsible for more than the quality of my own work or the decisions I made about individual game systems. I had to think about how development work was organized, how people collaborated, how priorities affected the team, and how decisions could influence the working environment. Some of these responsibilities felt like a natural extension of what I had already been doing, while others were entirely new to me.
One of the more difficult aspects of this transition was becoming involved in personnel-related discussions and decisions. I had always approached development from the perspective of working with people to solve problems, so encountering situations that could directly affect someone's professional future was something very different. It made me realize that management decisions weren't simply about efficiency, priorities, or business outcomes. They could have very real consequences for the people involved, and those consequences required empathy, responsibility, and careful communication. I also began to understand that difficult decisions rarely affected only the people directly involved. They could influence the confidence, motivation, and overall dynamics of an entire team. These weren't particularly comfortable experiences, but they were an important part of learning what it meant to take responsibility for people rather than simply coordinate their work.
Around the same time, I also experienced how broader business challenges could influence the people working within an organization. It was a difficult period that introduced me to another side of management, one that extended beyond product decisions and development priorities. I began to understand more clearly how financial pressures, organizational decisions, and employee well-being were interconnected, and how important communication became when teams had to navigate uncertainty. I couldn't always influence the circumstances behind those situations, but I could learn from the way they affected people and from the responsibilities that came with being part of the management process. Looking back, I think these experiences contributed just as much to my professional development as the product experiments I was working on. They helped me understand that managing products and managing people were connected, but they weren't the same thing, and becoming better at one didn't automatically make you better at the other.
Looking Back
When I first accepted the Product Manager role, I expected the biggest adjustment to be moving away from designing individual game systems and toward making decisions about entire products. And while that was certainly part of it, I quickly discovered that the transition involved much more than that. I had to learn how to organize development work, coordinate people, evaluate opportunities, and deal with situations that weren't always particularly comfortable. Some experiments failed, some decisions required difficult compromises, and some experiences introduced me to aspects of management I had never encountered before. Fortunately, I had people around me who were willing to share their knowledge and help me develop the skills I was missing. I learned a great deal from Ruben, Sabin, and the colleagues I worked with during that period, and I gradually became more comfortable with responsibilities I hadn't originally been looking for.
I didn't stop thinking like a Game Economy Designer when I became a Product Manager, and I don't think I ever really needed to. The analytical approach I had developed over the years remained useful, but I was now applying it to a much broader set of problems. Instead of concentrating exclusively on how individual systems performed, I was learning to consider how products, teams, business models, and organizational decisions influenced one another. Perhaps the biggest change was realizing that being responsible for a product didn't mean having all the answers or making every decision yourself. It meant understanding different perspectives, asking the right questions, helping people work toward common objectives, and accepting responsibility for outcomes that weren't always entirely within your control. It wasn't necessarily the career change I had planned, but it turned out to be an important step in my professional development.
Comments
Post a Comment