Beyond the Product: Building Systems That Scale

From Technical Foundations to Product Strategy and Organizational Thinking

By the second half of 2025, the House Games initiative at Momentum Group had reached an important turning point. During my first year, much of our effort had gone into stabilizing existing games, improving development processes, strengthening the team, and removing operational bottlenecks that made even relatively simple updates difficult to deliver. We had made meaningful progress, particularly in reducing recurring technical issues and gaining greater independence over our release process. However, as we began shifting our attention back toward developing new games and expanding the portfolio, it became increasingly clear that the improvements we had made were only part of the solution. We had learned how to operate more effectively within the existing technical environment, but supporting the next stage of the product's evolution would require us to reconsider some of the foundations on which it had originally been built.

This distinction changed the nature of the challenges I was working on. Improving a development process can help a team deliver more consistently, but it cannot eliminate every limitation imposed by the underlying architecture. Similarly, fixing recurring bugs can make existing products more reliable, but it doesn't automatically make those products easier to maintain, customize, or deploy across different environments. At Momentum, we were approaching a stage where the company was exploring opportunities to make House Games available across a broader product ecosystem while continuing to develop new games. Achieving that required more than adding features to the roadmap. We needed to reconsider how the games were structured, how their visual presentation could be configured, and how they interacted with the systems surrounding them. What had started as an effort to improve the reliability of individual products was gradually becoming a much broader initiative involving architecture, operational flexibility, and long-term product strategy.

Recognizing the Limits of the Existing Architecture

The need for a more substantial architectural evolution wasn't something we discovered overnight. Discussions about the future of the existing codebase had already started earlier in 2025, when I began exploring the situation with our Tech Lead. As the portfolio evolved, the architecture increasingly reflected the requirements for which it had originally been developed. Supporting new product configurations, improving maintainability, and preparing for broader distribution required us to reconsider some of those original design decisions. We had managed to stabilize many of the existing games through targeted improvements, but continuing to expand the portfolio without addressing its underlying structure would have made future development increasingly complex. The challenge wasn't simply to improve code quality. It was to ensure that the technical foundation could support the flexibility, reliability, and maintainability expected from a growing product portfolio.

From a Product Management perspective, this presented a familiar dilemma. A substantial architectural overhaul requires considerable development effort, and much of that effort produces relatively little immediate value that players can see. It is often easier to justify a new game or a visible feature than several months of work on the systems supporting them. However, I had become increasingly aware of the hidden cost of continuing to adapt a system beyond its original design assumptions. Every workaround could introduce additional complexity, every dependency could increase coordination requirements, and every improvement built without considering long-term maintainability could become more expensive to support. We needed to consider not only how quickly we could deliver the next feature, but also whether the technical decisions we were making would support the products we intended to develop over the following years.

The direction we began working toward involved a substantial frontend rewrite, accompanied by selected backend improvements. The objective was to create a more maintainable foundation for the existing portfolio while preparing the games for future expansion. This wasn't a simple matter of replacing one technology with another. It required understanding which parts of the existing implementation could be retained, which needed to be redesigned, and how changes would affect the relationship between House Games and the systems managed by other teams. It also required balancing architectural improvements with ongoing maintenance and product development, because the existing games still needed to operate reliably while the new foundations were being built.

From a Single Brand to a Multi-Brand Product Strategy

One of the main reasons for reconsidering the architecture was the opportunity to make House Games available across multiple brands. When I joined Momentum, the games were primarily developed for a single brand environment, and the existing development approach was closely connected to its requirements. Expanding into additional environments introduced new considerations that extended beyond simply making the same games accessible through different websites. Each brand could have its own visual identity, presentation requirements, and platform-specific considerations, which meant that the games needed to become more adaptable without requiring extensive changes to their underlying implementation.

The need for greater flexibility became particularly apparent as we considered how changes to a brand's visual identity affected the games associated with it. Updating the appearance of existing products could require development effort that might otherwise be directed toward improving functionality or building new games. From my perspective, this revealed a broader opportunity: if House Games were expected to operate across multiple brands, visual customization shouldn't require repeatedly modifying the underlying game code. We needed a system that separated the core game functionality from its visual presentation, allowing the same game to support different configurations without maintaining entirely separate implementations.

This led to the development of a multi-branding approach designed to support multiple visual skins for individual games, with configurations that could be adapted to different brand requirements. Rather than creating separate versions of a game for every visual variation, the objective was to build a shared foundation that could accommodate different presentation needs. We also considered how future configuration and management capabilities could make visual customization more accessible and reduce the amount of development effort required whenever a brand needed to update its games. It represented an important step toward treating House Games as a reusable product portfolio rather than a collection of individually customized applications.

However, developing a more flexible architecture also introduced challenges that weren't immediately visible from a functional perspective. One important consideration involved how additional visual configurations would affect the player experience, particularly during the initial loading process. Supporting multiple skins introduced new requirements around asset loading, resource management, and performance optimization. As we evaluated the evolving implementation, it became clear that architectural flexibility needed to be accompanied by equally careful attention to how efficiently games could become available to players. A system could be easier to configure and maintain while still requiring additional optimization to deliver the experience expected from a production-ready product.

Another important consideration involved asset caching and version management. As the number of supported visual configurations increased, it became increasingly important to balance efficient resource reuse with reliable delivery of updated game assets. Achieving that balance required careful coordination between caching strategies, version consistency, and the way resources were delivered to players. The experience reinforced how seemingly technical implementation details could have a significant impact on loading performance and the overall user experience, even when the broader architectural direction was aligned with the product's long-term objectives. It also highlighted the importance of evaluating technical decisions through their practical consequences rather than treating them as isolated implementation details.

For me, this was a particularly valuable example of why architectural flexibility and product scalability shouldn't be evaluated only by the number of configurations a system can support. A solution may successfully meet its functional requirements while still creating challenges for the end-user experience. Supporting multiple brands and skins was important, but so were loading performance, efficient asset delivery, and reliable version synchronization. These weren't secondary technical considerations; they were part of the product experience itself. The challenge was to ensure that the system could support broader business objectives without introducing unnecessary friction for players.

This experience reinforced a principle that had become increasingly important throughout my time at Momentum: a technical improvement isn't necessarily a product improvement unless its impact on the complete user experience is understood. Building reusable systems can reduce development effort and improve long-term maintainability, but those benefits need to be balanced against performance, operational complexity, and the practical conditions under which the product will be used. The goal isn't simply to create a system capable of doing more. It's to create one that can do more without making the experience worse for the people using it.

Maintaining Progress Through Team Changes

Planning a substantial architectural transition is difficult even when a team has stable resources and clearly defined responsibilities. In our case, we also had to navigate changes in technical leadership while continuing to maintain the existing portfolio. During this period, changes in the team's technical leadership required us to redistribute responsibilities and maintain continuity while the frontend rewrite was underway. Technical knowledge, architectural decisions, and development responsibilities needed to be shared across the team without losing the progress we had already made. The situation required particular attention because we were simultaneously improving the foundations of the portfolio and maintaining continuity for the games already available to players.

For a period of several months, I became more directly involved in coordinating the team's technical activities while we worked toward establishing a new leadership structure. My role wasn't to replace the expertise of a Tech Lead or make architectural decisions that required specialist knowledge. Instead, I focused on maintaining clarity around priorities, helping developers coordinate their work, ensuring that important decisions were discussed, and preventing the transition from creating unnecessary confusion. I also supported the development of technical leadership within the team, including identifying and recommending a developer who could take on greater responsibility. Having previously gone through a similar process of identifying and supporting technical leadership, I understood how important it was to find someone who could combine technical competence with the ability to guide others.

The experience reinforced an important lesson about organizational resilience. A team shouldn't depend entirely on one person to understand how its products work or why particular technical decisions have been made. Some specialization is unavoidable, and experienced developers naturally accumulate knowledge that others may not have, but the organization still needs ways to preserve that knowledge and maintain continuity when responsibilities change. Documentation, communication, shared understanding, and clear ownership all become especially important during periods of transition. I had already seen how much development capacity could be lost through inefficient processes, and this experience made me even more attentive to the risks created when critical knowledge or responsibilities were concentrated in too few places.

Building a Roadmap Around Real Dependencies

As the architectural work progressed, I became increasingly interested in the relationship between product roadmaps and the technical and organizational conditions required to deliver them. By this point, I had already developed a methodology for connecting roadmaps with development costs and staffing requirements, and I had spent considerable time improving how the House Games team planned and communicated its work. However, the challenges we were encountering made me realize that a roadmap could be financially realistic and still be operationally unreliable. Even when the required development effort was understood, delivery could depend on infrastructure improvements, platform changes, architectural decisions, or commitments from teams that operated under different priorities.

This was particularly relevant to our work on supporting a broader product ecosystem. Our team could make progress on game development, technical improvements, and product configurations, but successful delivery also depended on activities beyond our direct control. Some requirements involved systems maintained by other departments, while others required coordination across different technical and operational responsibilities. As a result, a feature being ready within our team didn't necessarily mean the complete product was ready to be released. The difference between team-level progress and end-to-end delivery became increasingly important, especially when communicating expectations to stakeholders who were primarily interested in the final result.

I started paying more attention to how dependencies were represented in planning discussions and how clearly responsibilities were defined. A roadmap could show that a particular feature was expected to be delivered in a certain month, but that date was only meaningful if the necessary dependencies had been identified and the teams responsible for them were able to commit to the required work. Without that alignment, the roadmap risked becoming a statement of intention rather than a reliable delivery plan. I began thinking about roadmaps less as fixed sequences of features and more as visible representations of a larger system of commitments, assumptions, and dependencies.

This perspective also influenced how I communicated progress and risks. I had introduced regular weekly reporting in January 2025, initially to provide greater visibility into the team's activities, priorities, and challenges. Over time, I became increasingly interested in making the underlying reasons for delays or uncertainty easier to understand. Reporting that a feature was delayed was useful, but explaining whether the delay resulted from development capacity, architectural complexity, unclear ownership, or an external dependency provided much more valuable information. It allowed discussions to move beyond whether the team was meeting a date and toward understanding what needed to change for delivery to become more predictable.

Connecting Product Strategy With Delivery Readiness

By late 2025, my responsibilities and interests were extending beyond the immediate House Games portfolio. I had opportunities to contribute to broader product assessments, focusing on delivery readiness, operational sustainability, and organizational dependencies. These exercises required distinguishing between progress on individual components and the conditions necessary for a complete product to operate reliably within a larger ecosystem. I found this particularly interesting because it brought together several areas of experience I had accumulated throughout my career: understanding product requirements, evaluating technical and organizational constraints, and considering the resources needed to support a product beyond its initial development.

I approached these assessments by examining the relationships between product development, technical ownership, infrastructure, external dependencies, and the resources required to maintain an initiative after delivery. Progress on individual components was important, but I also wanted to understand how those components would work together, how responsibilities would be distributed, and what conditions needed to be satisfied before a realistic delivery commitment could be made. Rather than treating an assessment as a simple approval or rejection, I focused on clarifying what was known, what remained uncertain, and which decisions would reduce the most important risks. The objective was to make the reasoning behind delivery expectations more transparent and help distinguish between promising development progress and genuine operational readiness.

This experience helped me appreciate another dimension of Product Management that I had only gradually begun to explore. Product strategy isn't simply about identifying promising opportunities or deciding which initiatives deserve investment. It also involves understanding whether an organization has the capabilities, ownership structures, and operational foundations required to turn those opportunities into sustainable products. A promising concept can still be a poor delivery commitment if the assumptions supporting it haven't been validated. Similarly, an initiative can demonstrate meaningful technical progress without being ready for broader deployment. Learning to distinguish between those situations became an increasingly important part of how I evaluated product decisions.

Making Development Work More Visible

During the first part of 2026, I also continued exploring ways to improve operational visibility within the development team. One initiative involved implementing an automated system in Jira to track developers' work in progress more consistently. The intention was to reduce the amount of manual effort required to understand what was actively being worked on and provide a clearer view of ongoing development activities. We began with the development workflow, with the possibility of extending the approach to other activities later. The broader objective was not to introduce more reporting for its own sake, but to make useful information easier to access and reduce the friction involved in coordinating work.

I had become increasingly conscious of how much time teams could lose when information was fragmented across meetings, messages, and manually maintained status updates. Even relatively small improvements in visibility could make it easier to identify blocked work, understand competing priorities, and recognize when tasks were spending too much time in particular stages of development. At the same time, I understood that automation wasn't a substitute for clear processes. Automating an inefficient workflow could simply make the inefficiency more consistent. The real value came from understanding what information mattered, how it should be represented, and how it could support better decisions without creating unnecessary administrative work.

Another initiative I explored involved developing a product evaluation framework that combined structured questionnaires with classification models to support more consistent assessments. I wanted to investigate how complex product information could be organized into a structured methodology, drawing on my experience in Game Economy Design and mathematical modeling. Although the framework remained an exploratory initiative rather than becoming an operational tool, developing it allowed me to apply my analytical background to a different area of Product Management.

Finding My Own Perspective on Product Management

By early 2026, I had started thinking more deliberately about the kind of product professional I wanted to become. My experience had gradually shifted my attention from individual features and delivery milestones toward the systems that make product development reliable. I still enjoyed working on games, understanding player behavior, and discussing product improvements, but I had become equally interested in the organizational conditions that determined whether good ideas could actually be delivered. Team capabilities, technical ownership, architectural dependencies, financial constraints, and operational processes were no longer separate concerns in my mind. They were interconnected parts of the same product development system.

After returning from a business trip to Malta in February 2026, I began reflecting more seriously on how I wanted to develop and communicate that perspective. Over the years, I had accumulated experience across several areas of game and product development, but I hadn't spent much time articulating the lessons connecting them. I began putting together a more structured approach to sharing my professional experience, using writing as an opportunity to organize my thoughts, examine assumptions, and develop a clearer understanding of the principles that had emerged from my work. On March 5, 2026, I published my first LinkedIn post as part of that effort.

What interested me about writing wasn't the idea of presenting myself as someone who had all the answers. If anything, my experience had taught me how often apparently straightforward problems could become complicated once their underlying dependencies were examined. I wanted to explore those complexities more openly and challenge myself to explain them in a way that could be useful to other professionals. Writing also forced me to distinguish between what I knew from experience, what I believed to be true, and what I still needed to understand. In that sense, it became another form of professional development, one that complemented the practical lessons I had learned through years of designing games, managing development activities, and working with teams.

This period also influenced how I thought about tools, including AI. I became increasingly interested in using AI to challenge assumptions, organize complex information, and explore alternative perspectives rather than simply generate answers. The value, in my view, wasn't in delegating judgment to a tool, but in using it to improve the clarity of my own thinking. The responsibility for evaluating information, understanding context, and making decisions still belonged to the person using it. This perspective aligned closely with the broader lessons I had been learning about Product Management: good decisions depend not only on having access to information, but also on understanding the assumptions, constraints, and relationships that give that information meaning.

What This Experience Taught Me

Looking back on my time at Momentum, I see a progression that went considerably beyond what I had originally expected when I entered the iGaming industry. I joined with a background in Game Design and Game Economy, along with growing experience in Product Management, and initially focused on understanding and improving a portfolio of House Games. Over time, my work expanded toward stabilizing development processes, strengthening team capabilities, reducing technical complexity, planning architectural improvements, and evaluating the dependencies affecting broader product initiatives. Each stage introduced new challenges, but they also reinforced a consistent lesson: the quality of a product is deeply connected to the quality of the systems responsible for building, maintaining, and operating it.

One of the most important things I learned was that improvements at one level don't automatically resolve problems at another. A capable team can still struggle with an architecture that needs to evolve. A well-designed product can still be difficult to operate if its supporting infrastructure doesn't meet its requirements. A carefully prepared roadmap can still fail when essential dependencies aren't understood or commitments aren't aligned. And even a technically promising initiative can encounter difficulties if ownership, maintenance, and operational responsibilities haven't been clearly established. Understanding those relationships requires looking beyond individual features and asking how the wider system functions. It also requires accepting that not every problem can be solved within the boundaries of a single team, regardless of how effectively that team operates.

I also became more aware of the importance of distinguishing between what a team can directly control and what it can only influence. As a Product Manager, I could help establish priorities, improve communication, identify risks, and work with developers to find solutions. I could support technical leadership, make dependencies visible, and help stakeholders understand the implications of different decisions. However, some outcomes depended on infrastructure, architectural ownership, or organizational priorities that extended beyond my direct responsibilities. Learning to recognize those boundaries didn't make me less interested in solving problems. It made me more interested in understanding how responsibility, authority, and accountability needed to align for meaningful progress to happen.

Perhaps the most significant change was in how I defined the role itself. Earlier in my career, I had thought primarily about the systems inside games: economies, progression mechanics, rewards, and player behavior. My transition into Product Management gradually expanded that perspective toward the systems surrounding the games: development teams, technical architecture, delivery processes, financial planning, and organizational dependencies. The underlying way of thinking remained surprisingly consistent. In both cases, I was trying to understand how different components interacted, where limitations emerged, and which changes could improve the behavior of the system as a whole.

For me, Product Management had become less about managing a collection of features and more about creating the conditions in which valuable products could be built reliably. That didn't mean moving away from the product itself. It meant recognizing that the product was inseparable from the people, processes, technologies, and decisions supporting it. My experience at Momentum helped me understand that distinction more clearly, and it continues to influence how I approach product development today.