Entering the iGaming Industry

Finding My Next Direction in Product Management

When my journey at Mega Studio ended in February 2024, I found myself at an interesting point in my career. After more than a decade in the gaming industry, primarily working in Game Design and Game Economy, I had accumulated a considerable amount of experience in designing systems, understanding player behavior, balancing economies, and connecting gameplay mechanics with business objectives. However, my time at Mega Studio had also introduced me to a different side of product development, one that involved managing teams, coordinating development activities, planning roadmaps, and understanding the financial implications of product decisions. For the first time in years, I wasn't entirely certain which direction I wanted to pursue next. Part of me considered returning to Game Design or Game Economy, where I felt confident in my experience and technical knowledge, while another part wanted to continue exploring Product Management and the broader responsibilities that came with it.

This uncertainty wasn't necessarily about whether I enjoyed Product Management. I had discovered that I genuinely liked understanding how different parts of a business came together to build and maintain a product. What made me hesitant was the realization that, despite having taken on responsibilities associated with a Head of Product role at Mega Studio, I still had much to learn before I could confidently consider myself prepared for such a position in a larger organization. My experience had developed in a relatively specific environment, where responsibilities often expanded according to business needs rather than following a predefined organizational structure. I valued everything I had learned, but I also understood the difference between having performed certain responsibilities and having developed the broader experience required to perform them consistently across different companies and industries. I wasn't particularly interested in chasing a more impressive title. What I wanted was an opportunity to continue growing professionally while making good use of the experience I already had.

Exploring a Different Side of Gaming

During those months, I started looking more seriously at the iGaming industry. Having experienced some of the financial challenges affecting traditional game development, I was interested in exploring an industry that appeared to offer greater economic stability and a different business model. I didn't necessarily expect the work to be easier, and I knew that many of the principles I had learned in traditional gaming would need to be adapted, but I was curious about the opportunities it might offer.

My first attempts weren't particularly successful. I applied for several positions at AvatarUX, including opportunities related to Product Ownership and Game Mathematics, and quickly discovered that my background wasn't equally suited to all of them. While the Product Owner direction was relatively close to my recent experience, the mathematical side of casino game development required a more specialized set of skills than those I had developed through years of designing and balancing free-to-play game economies.

That distinction became increasingly clear as I explored the technical requirements of casino games. In traditional Game Economy Design, I had worked extensively with probability, progression systems, reward distribution, monetization mechanics, and the relationship between player behavior and long-term engagement. Casino game mathematics, however, introduced a different level of specialization, particularly when it came to understanding and reproducing the statistical behavior of individual games. Although there were similarities between the two disciplines, I realized that familiarity with economic systems didn't automatically translate into the ability to develop or validate the mathematical models used in slot games. I didn't progress very far with those applications, but the experience helped me identify areas where I could expand my knowledge. Rather than seeing that as a reason to abandon the industry, I became interested in understanding those differences more thoroughly.

Deconstructing Gold Blitz

Around that time, I took on a challenge involving a casino game called Gold Blitz. The exercise involved deconstructing the game to understand how its mechanics worked, but I decided to take it further by attempting to recreate its behavior through a simulator built in Excel.

Spreadsheets had been an important part of my work for many years, particularly when designing game economies, modeling progression systems, and evaluating the impact of different balancing decisions. I was comfortable using Excel to represent complex relationships between variables, and I wanted to explore whether I could apply that experience to a different category of games. My goal wasn't simply to document what happened on the screen, but to understand the underlying logic well enough to reproduce the game's behavior in a controlled simulation.

The exercise turned out to be more challenging than I initially expected. Understanding the visible mechanics was one thing, but reproducing their mathematical behavior with sufficient accuracy required knowledge and techniques that I hadn't previously needed in my work. As I progressed, I encountered limitations in both my understanding of certain mathematical concepts and the simulation approach I was trying to build.

I didn't manage to complete the simulator exactly as I had envisioned it, and the exercise ultimately didn't lead to a new position. Nevertheless, I found the experience valuable because it helped me understand where my existing skills could be transferred and where additional learning was necessary. It also reinforced an approach that had served me well throughout my career: whenever I wanted to understand a complex system, I often learned more by trying to reconstruct it than by simply studying its visible behavior.

Finding an Opportunity at Momentum

Eventually, I came across an opportunity at SpinBet, part of Momentum Group. Unlike some of the earlier positions I had explored, this opportunity aligned much more closely with the direction I was considering for my career. It allowed me to build on my existing experience in product development while entering an industry that was still relatively new to me.

The recruitment process moved quickly, taking approximately two and a half weeks from beginning to end, and included a practical assignment that gave me an opportunity to demonstrate how I approached product planning. What made the exercise particularly interesting was that I already had a methodology I could adapt to the task, one that I had developed during my time at Mega Studio to address a very practical business problem.

At Mega Studio, I had spent considerable time developing a planning and budgeting framework that connected product roadmaps with development effort, staffing requirements, and personnel costs. Instead of treating a roadmap as a collection of features accompanied by estimated delivery dates, I wanted to understand what each feature actually required from the team and how those requirements translated into financial commitments.

The methodology allowed me to break down development work into smaller components, estimate the involvement of different roles, and connect those estimates to the monthly cost of maintaining the team. It also made it easier to evaluate alternative development scenarios when priorities, budgets, or available resources changed. Originally, I had built this approach to support discussions about development costs and delivery expectations, but during the Momentum recruitment process, I found that the same principles could be applied to the practical assignment with relatively little conceptual adjustment.

I enjoyed working on that assignment because it brought together several areas of experience that I had accumulated throughout my career. My background in Game Design had taught me to break complex systems into smaller components, while my more recent Product Management experience had pushed me to connect those components with resources, budgets, and business objectives.

I had become increasingly convinced that a roadmap was only as useful as the assumptions supporting it. A delivery plan could look convincing on paper, but without understanding the effort required, the people involved, and the dependencies between activities, it could easily create expectations that the team would struggle to meet.

The recruitment exercise gave me an opportunity to demonstrate that perspective, and the process ended successfully. I accepted the offer, with my first day at Momentum scheduled for August 19, 2024, which happened to be my birthday. After several months of exploring different opportunities and questioning my next professional step, beginning a new chapter on that particular date felt like an appropriate coincidence. :))

My First Steps into iGaming

When I joined Momentum, the company was developing its own portfolio of casino-style House Games. The initiative involved building games internally and integrating them into the company's broader platform ecosystem, which introduced a different set of technical and operational considerations from those I had encountered in traditional game development.

I entered the company with an open mind and tried to understand as much as possible about the products, the people working on them, and the processes connecting the development team with the rest of the organization. Although I had substantial experience designing and developing games, I was conscious of the fact that iGaming operated under different requirements. Concepts such as gameplay, user experience, and product performance remained important, but they existed alongside considerations related to transaction handling, game outcomes, platform integrations, and operational reliability.

One of the differences I began to appreciate was how closely the games depended on the systems surrounding them. In traditional gaming, I had spent much of my career thinking about progression, retention, monetization, and the ways players interacted with complex systems over time. In iGaming, those considerations were still relevant, but the reliability of the technical environment had a particularly direct impact on the product's ability to operate.

A game could offer an enjoyable experience and still encounter serious difficulties if its supporting systems were unstable or if its integration with the platform introduced unexpected behavior. This meant that understanding the product required looking beyond the game itself and examining the broader environment in which it operated. I was entering a field where technical reliability, operational processes, and product development were closely interconnected, and I would soon discover how important those relationships could become.

Understanding the Challenges Before Making Changes

As I became more familiar with the House Games initiative, I started noticing several areas that needed improvement. The existing products had already reached players, but the development team was facing challenges related to stability, technical implementation, and the processes used to maintain and update the games.

Some of these difficulties were relatively straightforward, while others required a better understanding of the systems supporting the products and the way development activities were organized. My initial instinct wasn't to introduce sweeping changes immediately. I wanted to understand how the team worked, identify the problems affecting its day-to-day activities, and see what could be improved using the capabilities already available.

I began working with the developers to address specific issues, gradually building a clearer picture of the obstacles that were preventing the team from operating more effectively. Coming from a background in Game Design and Game Economy, I was accustomed to approaching problems by analyzing the relationships between different systems. However, this was a different kind of challenge. I wasn't trying to balance a game economy or improve a progression system. I was trying to understand how the development process itself could become more reliable and predictable.

As I continued working with the team, it became apparent that fixing individual problems wouldn't necessarily be enough to achieve the improvements we were looking for. Some challenges were connected to how development work was organized, others to the technical structure of the products, and others to the dependencies between the House Games team and the wider platform organization.

Addressing them would require improvements in several areas, including development practices, coordination between teams, and the way products were maintained and released. I also began to understand that the challenge wasn't simply to develop more games or deliver updates faster. Before we could consistently expand the portfolio, we needed to make sure that the foundations supporting the existing products were reliable enough to sustain that growth.

This was an important realization for me because it challenged some of the assumptions I had developed throughout my previous career. In traditional Game Design, I had often approached product improvement by thinking about new features, better mechanics, more engaging progression, or stronger monetization systems. Those considerations were still relevant, but I was beginning to appreciate that sometimes the most valuable improvements weren't immediately visible to players.

Improving development processes, reducing operational friction, and making the release process more predictable could be just as important as introducing new gameplay features. And unlike some of the product experiments I had worked on previously, these improvements required me to think more carefully about the relationships between people, technical systems, and organizational processes.

A Different Perspective on Product Management

Looking back, joining Momentum marked another important stage in my transition from Game Design to Product Management. At Mega Studio, I had learned to connect product development with financial planning, resource allocation, and business decisions. At Momentum, I was beginning to encounter challenges that required me to think more deeply about technical dependencies, development processes, team capabilities, and operational reliability.

These weren't necessarily the areas I had imagined focusing on when I first considered moving into Product Management, but they were becoming increasingly important to my understanding of the role. I was discovering that building a successful product wasn't only about identifying valuable features, understanding players, or maintaining a roadmap. Sometimes, the most important contribution was creating the conditions that allowed a team to develop and maintain products reliably in the first place.

I hadn't joined Momentum with a complete understanding of the iGaming industry, nor did I expect my previous experience to provide an immediate solution to every challenge I encountered. What I brought with me was a combination of game development knowledge, experience working with complex systems, and a growing interest in understanding how products and organizations functioned as a whole.

Over the following months, those perspectives would become increasingly connected as I worked with the team to improve the way House Games were developed, maintained, and released. What initially looked like a new opportunity to continue my career in Product Management would gradually become an experience that changed how I thought about product development itself.