BUILDING PRODUCTS, NOT JUST GAMES

My experience as a Product Manager at Mega Studio, and what I learned about development budgets, business relationships, and the realities of building products in a changing business environment.

When I transitioned from Game Economy Design to Product Management at Mega Studio, I initially thought the biggest change would be taking responsibility for entire products rather than individual game systems. As it turned out, that was only part of the story. Over the following months, I became increasingly involved in development planning, budgeting, stakeholder relationships, and decisions that had consequences far beyond the games we were building. Some of these responsibilities developed naturally as I became more comfortable in my new role, while others emerged because the company was going through a period of significant change.

Looking back, it was probably one of the most educational experiences of my career. Not necessarily because everything went well, but because quite a few things didn't. I had the opportunity to work on interesting products, collaborate with different teams and external partners, and develop my own approach to planning and managing development. At the same time, I experienced how quickly priorities could change when business conditions became uncertain, development plans needed to be reconsidered, and expectations between different stakeholders evolved. It was a period that taught me that managing products and understanding the business conditions required to build those products were much more closely connected than I had previously appreciated.

Expanding Beyond Our Existing Products

At the time, Mega Studio was exploring opportunities beyond the rewarded games we had been developing. The company was interested in expanding its activities and working on different types of products, which gave me the opportunity to contribute to projects outside the area I had been focusing on.

One of those projects was Match Detective, a game developed by Murka. Although I had already transitioned into Product Management, I continued contributing to some projects through my previous experience in Game Economy Design. Match Detective was one of those cases. My involvement was primarily advisory: I analyzed the economy that was being developed, evaluated the proposed systems, and helped validate whether the overall direction made sense. I also suggested a few relatively small optimizations, but the core of my contribution was reviewing the existing approach rather than designing the entire economy myself.

I actually enjoyed having the opportunity to continue working on game economies. After spending so many years in Game Design, I wasn't particularly interested in abandoning that knowledge simply because my job title had changed. If anything, I considered it an advantage. Understanding how economies worked, how players interacted with progression systems, and how design decisions influenced monetization gave me a useful perspective when evaluating products from a broader business standpoint. I was beginning to understand that becoming a Product Manager didn't mean leaving my previous experience behind. It meant learning how to apply that experience to a wider range of problems.

Working on different projects also exposed me to the business side of game development in ways I hadn't previously experienced. Expanding into new products created opportunities, but it also required careful coordination of resources, development capacity, and financial commitments. During this period, I began to understand how challenging it could be to maintain that balance when business circumstances changed. For me, it was one of the first times I experienced so directly how commercial uncertainty could influence product development priorities, team planning, and the people responsible for delivering those products.

When Business Relationships Become Part of Product Management

As my responsibilities evolved, I gradually became the main point of contact for one of our key business partners. Our work involved developing rewarded games within an advertising-driven ecosystem, and the collaboration required regular discussions about development progress, product priorities, available resources, and expectations for future work. From my perspective, understanding those expectations became just as important as understanding the games themselves, because decisions about resources and priorities directly influenced what the development team could realistically deliver.

We had weekly meetings during which I reported on development progress, discussed our products, and addressed questions or concerns about ongoing work. Ruben, our CPO, or Mega Studio's founder would occasionally participate, but most of the time I handled those conversations myself. As the discussions became more complex, my responsibilities gradually expanded beyond regular product reporting. I frequently found myself acting as an intermediary between our business partner and Mega Studio's leadership, trying to communicate expectations, clarify concerns, and keep the collaboration moving forward. It wasn't always a particularly comfortable position to be in, especially when different stakeholders had different priorities or expectations about what could realistically be achieved.

This was quite different from the work I had been doing as a Game Designer. Previously, most of my discussions had revolved around gameplay, balancing, features, and development challenges. Now, I was increasingly involved in conversations about budgets, business expectations, development capacity, and the future direction of the products themselves. I wouldn't say I particularly enjoyed being caught between different business expectations, but it was an important learning experience. I started to understand how much of Product Management depended on communication, trust, and the ability to translate business requirements into something development teams could realistically deliver. And, perhaps more importantly, I was beginning to realize that good product decisions weren't always enough to solve problems that originated outside the product itself.

Trying a Different Approach with Plinko

As we continued developing new products, we also kept experimenting with ways to improve player engagement. One of the last rewarded games I worked on at Mega Studio was Plinko. The concept was deliberately simple, especially compared to some of our previous experiments with more elaborate arcade gameplay.

The basic mechanic was straightforward. Players dropped balls onto a board filled with pins, and the balls bounced through the obstacles until they reached their destinations. There wasn't much complexity involved in the interaction itself, which was actually part of the appeal. We wanted to preserve the accessibility of our earlier rewarded games while introducing something that had been largely missing from them: a stronger sense of progression.

Our initial products had relied heavily on simple, repetitive interactions. They were easy to understand, but they didn't necessarily give players many reasons to feel that they were advancing through a larger experience. With Plinko, we experimented with introducing multiple levels, each with its own presentation and configuration. As players progressed, the game could change its background, sound effects, and the arrangement of pins on the board. The underlying mechanic remained familiar, but the surrounding experience evolved. We hoped these changes would make progression feel more meaningful and give players an additional reason to continue playing.

In many ways, this was a continuation of the lessons we had learned from our earlier experiments with Golf Cash and Slicer. We still wanted to improve engagement, but we were now exploring whether we could accomplish that without introducing gameplay systems that were unnecessarily complicated or difficult to reconcile with the rewarded advertising business model. I was particularly interested in understanding whether progression could provide players with a stronger sense of purpose without significantly increasing the complexity of the core gameplay. It was a relatively simple hypothesis, but one that I felt was worth exploring.

Unfortunately, we never had the opportunity to evaluate that hypothesis as thoroughly as we had originally intended. This was frustrating because we had invested time and effort into exploring a different approach to progression, and I was genuinely curious to see how players would respond. We had identified something we wanted to improve, developed a product around that idea, and reached the point where we wanted to understand whether it actually worked. However, we weren't able to gather enough meaningful information to reach a reliable conclusion.

Sometimes, the circumstances surrounding a product change before you even get the chance to find out whether your ideas were right. That was one of the things I found particularly difficult to accept at the time. As a Game Designer, I had always been interested in testing systems, observing player behavior, and improving mechanics based on actual results. As a Product Manager, I was beginning to understand that developing a product and having the opportunity to validate its potential were not necessarily the same thing.

Building a More Predictable Development Process

As discussions about development priorities and available budgets became increasingly important, I found myself facing a different kind of challenge. We needed a clearer way to understand how different levels of investment would affect development capacity, delivery timelines, and the scope of work we could realistically support. The difficulty was that adjusting a budget wasn't simply a matter of changing a number. A smaller budget meant fewer available resources, less development capacity, or a reduced scope of work. I wanted to make those consequences easier to understand, both for the people making business decisions and for those responsible for delivering the products.

Instead of approaching development planning with a single roadmap and an overall budget, I decided to build a methodology that would allow us to estimate costs at the individual feature level and create alternative development scenarios based on different levels of investment. The idea was relatively straightforward: if we were considering several possible budgets, we should be able to explain what each of those budgets could realistically support. I wanted to move away from discussions where development costs were treated as abstract numbers and toward a more structured approach where we could connect investment directly to the work that needed to be done.

I started breaking down development work into smaller components, estimating the personnel required, the amount of time each discipline would need, and the corresponding costs. Rather than looking only at the total budget for a product, I wanted to understand the financial implications of individual features. This meant accounting for different development roles, including frontend and backend programmers, artists, designers, and QA. By combining the estimated effort with personnel costs, I could calculate how much a particular feature was expected to cost and how those costs contributed to the overall development budget. It required me to think about development from a perspective that was quite different from the one I had been accustomed to as a Game Designer. I wasn't simply asking how much work a feature would require or whether it would improve the player experience. I was also asking what resources we needed to build it, how much those resources would cost, and whether the investment made sense within the broader development plan.

What made this approach particularly useful was that it allowed us to create multiple scenarios. For example, a smaller budget might support maintaining an existing product and developing a limited number of improvements, while a larger budget could justify additional features, more development capacity, or a more ambitious roadmap. These scenarios weren't intended to make the development process unnecessarily complicated. Quite the opposite. I wanted to make the relationship between money, people, time, and deliverables as transparent as possible.

If the available budget changed, we could explain what would need to change in the development plan. If we wanted to demonstrate the value of maintaining a larger investment, we could show what additional development work that investment would make possible. Instead of treating budgets and roadmaps as separate subjects, I was trying to connect them in a way that made the consequences of different decisions easier to understand. It didn't eliminate difficult conversations, but it gave us a more practical way to approach them.

Connecting Roadmaps, Resources, and Costs

To make the methodology practical, I connected three aspects of development planning: the roadmap, the cost of individual features, and the cost of the personnel required to build them. The roadmap provided a visual overview of the work, showing when different activities were expected to take place and how development responsibilities were distributed across the team. The feature-level cost breakdown allowed me to estimate the effort and expense associated with individual pieces of functionality. Finally, the personnel cost model provided the financial assumptions used in those calculations. Together, these components made it possible to examine a development plan from several perspectives rather than treating the roadmap and budget as separate documents.

I built this methodology from scratch to address a practical problem we were facing at Mega Studio. It wasn't something I had been specifically trained to do, nor was it a standard process I had simply inherited from someone else. I was trying to solve a problem using the experience I had accumulated in development, game economies, and product management. I had spent years working with systems in which different variables influenced one another, and I suppose that way of thinking naturally carried over into development planning. Instead of balancing virtual currencies, progression, and monetization, I was now trying to understand the relationships between development effort, available resources, costs, and delivery expectations.

Of course, creating a better planning system didn't mean we could control every business decision affecting the development process. Even the most detailed estimates couldn't guarantee that stakeholders would agree on a particular level of investment, and there were always factors that couldn't be predicted with complete accuracy. However, the methodology gave us a clearer understanding of our own costs and a more structured way to discuss what we could realistically deliver. It also changed how I approached development planning. I was no longer thinking exclusively about which features should be built and when. I was considering the resources required to build them, the financial implications of different priorities, and the compromises involved in every development decision. That was a significant step in my understanding of Product Management.

Interestingly, the methodology eventually became useful beyond my time at Mega Studio. When I later interviewed for a Product Management position at Momentum Group, I reused the same approach for the practical assignment, adapting it to a different product and development context. The spreadsheet I created for that assignment included a development roadmap, feature-level cost estimates, and a personnel cost model. I found it interesting that something I had originally developed to address a specific challenge could be adapted to a completely different situation. It reinforced my belief that understanding the relationships between development work, resources, and costs was useful regardless of the type of product being developed.

For anyone interested in how I approached the problem, I've included an illustrative example below.

View my Product Development Roadmap and Feature Budgeting Example

This example illustrates the planning and budgeting methodology I originally developed during my time at Mega Studio, applied to a different product and development scenario. It is intended to demonstrate my approach rather than disclose internal financial or operational information.

Looking back, I find it interesting that one of the most useful tools I developed during that period originated from a rather uncomfortable business situation. We were trying to maintain a sustainable development plan while navigating changing expectations, and I needed a way to make our options easier to evaluate. What started as a tool for discussing development costs and priorities gradually became part of how I approached product planning. I hadn't set out to develop a methodology that I would continue using in the future. I was simply trying to solve a problem that needed solving.

When the Partnership Came to an End

y early 2024, the business environment surrounding our work had changed considerably. Development priorities had evolved, and the circumstances affecting our projects were becoming increasingly difficult to predict. Despite the effort invested in improving our planning processes, exploring new products, and maintaining productive relationships with different stakeholders, there were factors influencing the future of our work that couldn't be addressed through product development alone. I was beginning to understand that even when a team was doing its best to improve the way products were developed, the broader business environment could still determine which opportunities remained available.

I don't think it would be fair to attribute everything that happened to one decision or one person. There were several factors involved, and I wasn't necessarily in a position to influence all of them. What I could do was focus on my responsibilities, continue supporting the products and people I was working with, and try to make the development process as clear and predictable as possible. Nevertheless, the situation was evolving in a direction that would eventually bring my own time at the company to an end.

February 19, 2024, was my last day at Mega Studio.

It wasn't the ending I had expected when I first accepted the opportunity to become a Product Manager. Over the previous months, I had invested considerable effort into developing products, improving our planning processes, and maintaining relationships with important stakeholders. I had also continued learning a role that I hadn't originally been particularly interested in pursuing. But business circumstances don't always follow the same trajectory as individual professional development. Sometimes, you can be making progress in your own responsibilities while the organization around you is moving in a different direction.

Although the experience ended differently from what I had anticipated, I didn't consider the time I had spent there wasted. Quite the opposite. I had learned things about product development, business relationships, financial planning, and management that I probably wouldn't have encountered in the same way if everything had gone according to plan. Some of those lessons came from projects that worked, while others came from experiments that couldn't be properly validated or situations where the available options were more limited than I would have liked. Not all of them were pleasant experiences, but they contributed to the way I understood my responsibilities and approached problems afterward.

Looking Back

My time at Mega Studio gave me a much broader understanding of what it meant to be responsible for a product. I had started that period as someone whose professional identity was still strongly connected to Game Design and Game Economy. By the end of it, I had become involved in development planning, resource allocation, budgeting, external stakeholder management, and commercial discussions. I had also experienced some of the less comfortable aspects of working in management. I saw how business uncertainty could affect an entire team, how expectations between different stakeholders could evolve, and how decisions made outside the development process could influence whether a product ever had the opportunity to demonstrate its potential.

One of the most important lessons was that a Product Manager needs to understand much more than the product itself. A feature might be interesting, useful, and technically achievable, but that doesn't automatically make it a sensible investment. A roadmap might look perfectly reasonable, but it still needs to account for the people and money required to deliver it. And a development team might be doing excellent work while the circumstances supporting that work are becoming increasingly uncertain. I also learned that having a clear understanding of costs and development capacity could make difficult conversations considerably more productive. You can't always convince stakeholders to invest more money, but you can help them understand what their investment makes possible and what compromises come with spending less.

Perhaps the most valuable thing I took away from this experience was the realization that I no longer needed to think of myself primarily as a Game Designer who had moved into Product Management. I was becoming comfortable working at the intersection of product development, people, processes, and business decisions. I still enjoyed Game Design, and I still considered my experience in game economies an important part of my professional background. But I had also discovered that I enjoyed understanding how all the different parts of a business came together to support a product, even when those relationships were complicated or difficult to manage.

And although my time at Mega Studio ended under circumstances I hadn't anticipated, the experience gave me skills and tools that I would carry into the next stage of my career.

As it turned out, that next stage would take me into an industry I hadn't worked in before: iGaming.