Building a Reliable Product Development Team
Why Stabilizing Existing Products Sometimes Matters More Than Building New Ones
When I joined Momentum Group in August 2024, I was excited about the opportunity to continue developing my Product Management experience in the iGaming industry. The company was working on its own portfolio of House Games, and I expected to spend much of my time helping the team develop new products, improve existing ones, and gradually expand the portfolio. What I discovered during my first weeks, however, was that the most immediate challenge wasn't deciding which games we should build next. It was understanding why maintaining and updating the existing products required considerably more effort than expected. The games were already live, but the development processes supporting them presented several challenges, and the team was working within technical and operational constraints that made even relatively straightforward improvements more complicated than they needed to be.
My background in Game Design and Game Economy had taught me to approach complex systems by identifying how their individual components interacted, and I quickly realized that the same approach would be useful here. Rather than focusing immediately on new features or additional games, I started examining the development workflow, the team's capabilities, the release process, and the technical dependencies affecting our work. Some problems were visible through recurring bugs, while others became apparent only when we tried to deploy updates or coordinate changes with other departments. It became increasingly clear that the House Games initiative needed a stronger operational foundation before it could support the pace of development the company expected. For me, this marked an important shift in perspective: the most valuable product decision at that moment wasn't necessarily what to build next, but what needed to be improved before building more would make sense.
Rebuilding the Team's Foundations
My first priority was to understand the capabilities of the existing team and identify which problems could be addressed with the resources we already had. I spent time working with the developers, reviewing ongoing issues, and trying to understand where the development process was breaking down. Some difficulties could be resolved through clearer requirements, better coordination, or more structured approaches to debugging, while others required a deeper understanding of the technical foundations supporting the portfolio. I initially focused on solving specific problems together with the team, because I wanted to understand whether the existing structure could be improved before recommending more significant changes. Over time, however, I began to see opportunities to improve how responsibilities were distributed, how knowledge was shared, and how the team was organized to support the growing needs of the portfolio.
This eventually led to changes in the team's structure and composition as we worked toward building a development group better equipped to support the portfolio's technical and operational requirements. The objective wasn't simply to increase output or accelerate delivery, but to create a team that could understand the products it was responsible for, identify technical problems more effectively, and maintain the games with greater autonomy. At the same time, I began placing greater emphasis on communication, accountability, and the way development work was organized. Having capable developers was important, but it was equally important that they understood the priorities, shared knowledge, and worked toward common objectives. I was learning that building a reliable development team required more than assembling individuals with the right technical skills. It also required creating an environment in which those skills could be applied consistently.
Taking Control of the Release Process
One of the first major operational challenges I identified involved the way House Games were released. At the time, publishing updates required coordination across multiple systems and teams, which made even relatively straightforward improvements more time-consuming than necessary. Preparing and releasing a change often involved additional coordination and validation, creating dependencies that affected how quickly individual products could be updated. In an environment where reliability and predictability were essential to the player experience, I considered simplifying this process an important priority. I worked with the developers to improve how individual game updates were prepared, validated, and released. We introduced a more independent release structure, giving the team greater control over what was included in each update and reducing unnecessary dependencies between products.
However, improving the internal development workflow was only part of the solution. We also needed to improve coordination with the wider platform organization, because publishing updates still involved responsibilities shared between different teams. At that time, House Games were available through the Razed brand, and I worked with our platform colleagues to clarify responsibilities and give the House Games team greater autonomy over its releases. The impact was substantial: updates that previously could take several weeks to reach production could now be published within a matter of days, depending primarily on our own readiness. We hadn't necessarily made the development of individual features faster, but we had removed an important operational bottleneck. It was one of my first concrete experiences at Momentum demonstrating how improvements in process design and team autonomy could create immediate value without requiring the development of a new product feature.
Choosing Stability Over Expansion
Once the most immediate release problems had been addressed, we still faced a difficult question: should we continue expanding the portfolio, or should we dedicate more time to improving the games that were already live? Developing additional products was naturally an important business objective, but the existing games continued to require attention, and maintaining them consumed a considerable amount of the team's capacity. Introducing more games before improving the foundations supporting the portfolio risked increasing the maintenance burden and making future development less predictable. We therefore shifted much of our focus toward bug fixing, stability improvements, and reducing the operational problems affecting existing products. Development didn't stop entirely, but the priority became ensuring that the games already available to players could operate reliably and be maintained more efficiently.
This wasn't necessarily the most exciting direction from a traditional product development perspective. Building new games creates visible progress, while stabilizing existing products often involves addressing problems that players should ideally never notice. Nevertheless, I considered it an important investment in the long-term health of the portfolio. A game that requires frequent technical intervention isn't operating as efficiently as it should, and every recurring issue consumes capacity that could otherwise be dedicated to improving the product or developing something new. By reducing those recurring problems, we were also trying to create the conditions for more predictable development in the future. The challenge was that technical stability couldn't always be achieved through isolated fixes, particularly when the same underlying limitations affected multiple games.
Plinko: When Gameplay Meets Technical Reality
As development progressed, we encountered additional technical challenges that extended beyond the gameplay implementation itself. Although we had made significant progress in refining the game's behavior, further work was needed before we could confidently consider the product ready for release. This created a difficult product decision. We had already invested considerable effort in improving the game's implementation, but releasing it before resolving the outstanding technical considerations would have introduced unnecessary operational risks. Ultimately, we decided not to proceed with the release under those conditions. It was frustrating to invest so much effort into a product that couldn't be launched, but the experience reinforced an important distinction: a game can be technically functional without being operationally ready for production. It also demonstrated how closely gameplay implementation, technical requirements, and operational readiness were connected, and why product decisions sometimes had to account for limitations that extended beyond the development team's direct control.
Solving the Cause Instead of the Symptoms
One of the most impactful technical improvements during this period came from identifying a shared cause behind a large number of recurring issues. As we continued investigating problems across the House Games portfolio, we discovered that several apparently unrelated bugs originated from the same underlying problem. Because the symptoms varied from one game to another, these issues initially appeared to require separate fixes, even though they shared a common cause. This made the problem particularly interesting from a product perspective. The growing number of reported issues suggested a large collection of individual defects, but investigating their relationships revealed that the situation was more structural than it initially appeared.
Rather than continuing to address each issue individually, we worked toward simplifying and standardizing the affected systems. This eliminated a significant source of inconsistencies and reduced the complexity associated with maintaining the products. The impact was substantial: following the change, more than 90% of the issues recorded on our bug board were resolved. For me, this was one of the clearest examples of why understanding the underlying structure of a system matters more than simply increasing the speed at which individual bugs are fixed. We hadn't solved the problem by working through the backlog faster. We had identified a shared cause and changed the system so that an entire category of issues no longer occurred in the same way.
The improvement also had an important operational effect. Reducing the number of recurring issues meant that developers could spend less time revisiting the same problems and more time working on improvements that would benefit the portfolio over the longer term. It also made the products easier to maintain, because the team no longer had to account for as many variations in how related technical components behaved. Although this was a technical change, its value extended beyond the implementation itself. It improved stability, reduced maintenance complexity, and helped us recover development capacity that had previously been consumed by recurring problems. Experiences like this reinforced my belief that Product Management doesn't always require defining the technical solution, but it does require recognizing when a technical problem has become a product-level priority.
Recovering Capacity Through Better Processes
While we were improving the products, we also had to adapt to changes in the resources available to the team. During 2025, our development group experienced a significant reduction in available capacity, creating additional pressure on a department that was already balancing maintenance, technical improvements, and future development plans. Simply expecting the remaining developers to compensate by working harder wasn't a sustainable solution. We needed to reconsider how we organized work, how information moved between team members, and how much time was being lost through unnecessary coordination or inefficient processes. I wanted to understand how much of our remaining capacity was being consumed by activities that didn't directly contribute to improving the products, and whether changes to the way we worked could help us recover some of that lost efficiency.
I focused on improving communication, clarifying responsibilities, and reducing friction in the way development activities were planned and executed. We worked toward making priorities easier to understand, improving the coordination of ongoing tasks, and ensuring that the available capacity was directed toward the work that mattered most. These changes didn't replace the technical expertise or working hours of the people we had lost, but they helped the remaining team operate more efficiently. By the end of August 2025, I estimated that we had recovered approximately 60% of the development capacity lost during the reduction, primarily through improvements in processes and communication. It wasn't a perfect recovery, and the team still faced important limitations, but it demonstrated how much operational efficiency could influence delivery capacity even without additional hiring.
Another practice that supported this effort was the introduction of regular weekly reporting, which I had started in January 2025. These reports helped create a more consistent view of the team's progress, ongoing challenges, and development priorities. I wanted to make our work easier to understand beyond the immediate development group, particularly when technical constraints affected delivery expectations. Reporting alone couldn't eliminate dependencies or solve architectural problems, but it provided a more structured way to communicate what was happening and why certain activities required more time than initially expected. As the team became more organized, I also began paying closer attention to how responsibilities and technical knowledge were distributed, because a reliable development process needed to remain functional even when individual team members were unavailable.
Preparing for the Next Stage
By August 2025, the House Games initiative was in a different position from where it had been when I joined. We had reorganized the team, introduced more reliable release procedures, reduced our dependence on the platform team for publishing updates, and addressed a major source of recurring technical issues. The portfolio had become more manageable, and the team had recovered part of its lost development capacity through operational improvements. These changes allowed us to begin shifting attention back toward developing and expanding the games portfolio, including work on Blackjack. However, the progress we had made also highlighted opportunities to improve the underlying technical architecture and make future development more efficient.
In fact, discussions about a more substantial architectural evolution had already begun earlier that year. Around March 2025, I had started exploring the problem with our Tech Lead, whom I had previously recommended for promotion from within the team. We recognized that parts of the existing technical architecture would benefit from significant changes if we wanted to support more stable products and prepare the portfolio for future expansion. As the company explored opportunities to make House Games available across multiple brands, we began considering how the underlying architecture could better support flexibility, maintainability, and future growth. We had improved the way individual games were maintained and released, but we also recognized that supporting a broader product strategy would require a more adaptable technical foundation.
This distinction became increasingly important to me. Improving processes had allowed us to deliver updates faster, and simplifying parts of the technical implementation had helped us reduce recurring bugs. But neither improvement could fully substitute for an architecture capable of supporting the company's longer-term objectives. The next challenge would therefore be different from the one we had faced during my first months at Momentum. Instead of focusing primarily on stabilizing existing products and improving the team's day-to-day operations, we would need to rethink how the games were built, configured, and distributed in the first place. That meant considering not only the development of individual games, but also the systems and tools that would allow the portfolio to scale.
What This Experience Taught Me
Looking back on my first year at Momentum, I consider it one of the periods that most strongly influenced how I approach Product Management today. I had entered the company expecting to work primarily on developing and improving games, but much of my effort went into building the conditions that would allow the team to do that work reliably. The most meaningful improvements weren't necessarily new features or additional products. They were changes to the development process, the release structure, the team's capabilities, and the technical foundations that supported the existing portfolio. Some of those improvements were immediately visible, such as reducing release delays from weeks to days, while others became apparent through the gradual reduction of recurring problems and the recovery of development capacity.
The experience also reinforced the importance of distinguishing between symptoms and underlying causes. A large bug backlog doesn't always mean that a team needs to fix bugs faster, just as slow delivery doesn't always mean that developers need to write code more quickly. Sometimes, the real problem lies in the way a system has been designed, how responsibilities are distributed, or how different teams depend on one another. Addressing those problems requires looking beyond individual tasks and understanding the relationships between the people, processes, and technical components involved. My background in Game Design had taught me to think about systems from the perspective of player behavior and gameplay mechanics. At Momentum, I was increasingly applying that same way of thinking to the systems responsible for building and operating the products themselves.
Another important lesson was that technical ownership and product expertise are not interchangeable. A development team may be capable of implementing a feature, but someone still needs to understand what good looks like, how the product should behave, and whether the result meets the expectations of both players and the business. Whether development happens internally or through external partners, the responsibility for understanding and validating the product remains essential. Technical execution and product judgment need to complement each other, particularly when working with systems where seemingly small implementation details can significantly affect the overall experience.
This became particularly clear while working on Plinko. Improving the game's physics required more than identifying bugs or checking whether the implementation matched a set of requirements. It required understanding how the game was supposed to behave, recognizing inconsistencies in its behavior, and spending considerable time working alongside the developers to identify and implement improvements. My background in Game Design allowed me to contribute directly to those discussions, bridging the gap between the intended gameplay experience and the technical challenges involved in achieving it. That experience reinforced something I had gradually come to appreciate throughout my career: effective Product Management doesn't mean replacing technical specialists, but knowing enough about the product to ask the right questions, challenge assumptions, and help the team make better decisions.
By the end of that first year, I had become more convinced that effective Product Management wasn't simply about deciding what a team should build next. It was also about understanding what prevented the team from building reliably, identifying which improvements would have the greatest impact, and creating an environment where progress could become more predictable. We had made meaningful improvements, but we were also approaching a new stage that would require us to address problems at a deeper architectural level. The next chapter would involve evolving significant parts of the technology supporting House Games, preparing the portfolio for multi-brand deployment, and learning how difficult it could be to coordinate changes that extended beyond the boundaries of a single development team.
Comments
Post a Comment