Beyond the Game: Building Systems That Create Lasting Value

Why successful gaming products depend on more than individual games, features, and content.

Introduction: The Product Beyond the Game

My perspective on gaming products started with the games themselves. As a Level Designer and later a Game Designer, I wanted to understand the decisions players made, the mechanics that made those decisions interesting and the systems that gave individual sessions a sense of direction. As my work expanded into economies, monetization, live development and eventually Product Management, the questions became broader without replacing the original ones. I still care about why a mechanic feels satisfying or why a player chooses to return. I also want to understand what that mechanic requires from the rest of the product, how its incentives affect other systems and whether the team can keep improving the experience after launch. Working on individual games and later coordinating development across a portfolio gave me two perspectives that belong together: one starts with the player's experience, while the other asks what needs to exist around that experience for it to keep creating value.

That distinction matters in iGaming, where expanding a catalog is a familiar and reasonable way to grow. More titles provide variety, reach different player preferences and create new opportunities for discovery. But adding games doesn't necessarily make the platform itself stronger. If each title remains an isolated experience, much of the player's progress and accumulated context stays inside it. The next game may offer something different, yet the journey effectively starts again. This is the idea I've returned to throughout my writing: proprietary games can be more than content. When an operator owns and can develop the underlying capabilities, games can also become part of the infrastructure connecting a player's journey across the platform. The question shifts from how many titles we can offer to what those titles can contribute together.

Working on house games within a wider product portfolio made that question tangible. Each title has its own mechanics, math, pacing and delivery requirements, yet some of the systems needed to build and operate it may also be useful elsewhere. Portfolio planning meant thinking about the immediate game and the capabilities that might support the next release: common tools, clearer interfaces with the platform and systems designed to evolve rather than be rebuilt. Cross-game progression, persistent identity and shared rewards are possible extensions of that thinking, not automatic outcomes of owning proprietary content. They only become useful when they serve the experiences involved and when the organisation can manage their consequences.

This article looks at that wider product, starting with the relationship between games and player journeys, then moving through engagement, economies, monetization, LiveOps and the organisation responsible for keeping everything working. I'm not arguing that every game should become part of an elaborate ecosystem. Some experiences are better left independent, and connections can introduce as many problems as they solve. What interests me is how we decide which systems are worth connecting, which should remain specific to a game and what those decisions make possible for players and for the teams building the product.

1. From Game Catalogs to Player Ecosystems

The distinction between a game catalog and a player ecosystem becomes clearer when we look at what happens between sessions and between games. A catalog provides access to content; an ecosystem creates useful relationships between experiences that would otherwise remain separate. Consider a player who spends time learning a game, progressing through its objectives and earning rewards that matter within that particular experience. When they try another title, most of that accumulated context may no longer apply. The new game has its own mechanics, economy and progression, and the player's previous investment has little influence on what comes next. There is nothing inherently wrong with that model. Some games are better as self-contained experiences. But from a platform perspective, it raises a question worth exploring: what would change if some of the player's history could continue to matter, even when the game changes?

Shared progression offers one answer, although it is not the only one. A platform-level system could recognise activity across several games without asking those games to share identical mechanics or economies. Achievements might contribute to a persistent profile, broader objectives could encourage discovery and carefully designed rewards could give players another reason to explore the catalog. Identity matters because it allows a history to accumulate around the player rather than disappear every time an experience ends. The challenge is deciding what should carry forward. A shared objective can create continuity, but it can also push players towards a game they do not enjoy simply because its rewards are more efficient. The connection is only useful if it adds value to the journey instead of turning the journey into another task list.

This also changes how individual titles might contribute to the platform. In a traditional catalog, a game's own engagement and commercial performance tend to dominate the discussion. Those measures still matter, but a connected platform can create additional roles for different experiences. One title might be particularly effective at introducing players to the product, another might sustain longer sessions, while another could make exploration or platform-level progression more attractive. These contributions need to be demonstrated rather than assumed; calling something 'ecosystem value' is not a substitute for evidence. But if a game influences discovery, participation or spending elsewhere, evaluating it only within its own boundaries would also miss part of its contribution.

There are other ways for a platform to connect experiences without moving a currency or a level between them. Discovery is one of them. If the product understands what a player has enjoyed before, it has a better starting point for introducing another game than a catalog organised only by provider or release date. Personalisation, relevant recommendations and re-engagement systems can help new content reach people for whom it actually makes sense. That is still infrastructure, even if players experience it simply as finding something worth trying. And it creates another question for the operator: whether each release must earn attention almost entirely on its own, or whether the surrounding product can make discovery more useful for both the player and the game.

My work on house games gave me a practical reason to think about this beyond the player-facing concept. When several titles sit inside the same development portfolio, not every problem supporting them is unique. Some capabilities may be worth building once, while others need to remain flexible because the games have different requirements. This is why I find proprietary games as infrastructure a useful way to frame the investment. The question is no longer only 'What does this title need to launch?' It is also 'Which parts of this work could make another title easier to build, operate or improve?' That perspective changes conversations about architecture, tooling and ownership even before a platform considers connecting player progression across games.

Not every capability worth carrying forward is technical. Experience with a particular genre, knowledge gained from operating an economy, an established relationship with an audience or familiarity with a game's identity can also make the next product easier to design and introduce. This is another useful way to understand games as infrastructure: reuse is not limited to shared services and code. It also includes what an organisation learns and what players come to recognise. A strong individual release can create immediate value; a useful capability, whether technical or strategic, can continue influencing decisions long after that release.

There are costs to this approach. A system built for one title may be difficult to extend when another game brings different pacing, mathematics or reward requirements. Standardising too much can restrict Game Design; allowing every team to build its own version of the same functionality can create duplication and maintenance overhead. Shared rewards introduce another kind of dependency because incentives in one experience may influence behaviour in another. If currencies or rewards can move between games, the platform also needs rules for what remains local, what is transferable and how resources enter and leave the wider economy. A player might choose a game for the resources it provides elsewhere rather than for its gameplay, and an adjustment made by one team could change the balance of several experiences. These problems cannot be solved simply by creating more shared systems. They require clear boundaries, ownership and a willingness to leave some parts of the product independent.

For that reason, I don't see the move from catalog to ecosystem as a universal stage of maturity. The right choice depends on the audience, the type of games, the business model and the organisation's ability to manage interconnected systems. A platform can already have player profiles, rewards, progression and LiveOps tools without those components adding up to a coherent journey. The value comes from the relationships between them, and the relationship has to be strong enough to justify the complexity of maintaining it.

There is also a practical problem with any ecosystem strategy that depends too heavily on the value it might create once everything is connected. Players need a good reason to use the product before that future exists, and teams need evidence that each new connection is worth maintaining. This is particularly clear in platforms that depend on several groups participating at once, but the principle applies more broadly: a shared system should create enough value at its current stage to justify the next investment. Building infrastructure that may become useful years later is not necessarily a strategy if the games and players supporting it receive too little benefit along the way. The journey towards an ecosystem matters just as much as the eventual architecture.

The strategic opportunity is that successful infrastructure can continue supporting what comes next. Individual game hits are difficult to predict and difficult to reproduce consistently, whereas a useful shared capability can benefit several releases over time. A new title might arrive in an environment where players already have a persistent identity, where discovery is informed by previous behaviour or where teams have the tools to operate and improve the game without starting from scratch. None of this reduces the importance of the game itself. It gives a good game a stronger environment in which to succeed. The goal is not simply to build a larger catalog, but to develop the systems that allow its individual experiences to become more valuable together.

2. The Systems Behind Player Engagement

What interests me about engagement is how much of it comes from the relationships between systems rather than from individual mechanics. Progression gives players direction, rewards recognise their actions, economies determine how resources are earned and used, and gameplay provides the decisions that make those activities interesting. We can design and measure each component separately, but players experience them together. A reward matters because of what it enables. Progression feels worthwhile when the activities required to advance remain engaging. An economy can be perfectly consistent on paper while offering resources that no longer create interesting choices. Improving one component therefore does not guarantee a better experience, especially when the change alters what players find worth doing elsewhere in the game.

An important distinction is the difference between activity and engagement that players actually value. Games are good at giving players objectives, and players become good at finding efficient ways to complete them. If a repetitive activity provides better rewards than more engaging alternatives, many players will repeat it. If daily objectives become the fastest route to progression, sessions may gradually organise themselves around those objectives. The metrics can look encouraging: frequent returns, high completion rates and steady progress. Yet the motivation matters. There is a difference between returning because the game remains enjoyable and returning mainly because missing a session feels costly. Both behaviours produce activity, but they do not necessarily indicate the same relationship with the experience.

Progression is particularly influential because it makes individual sessions part of a longer journey. Players build a history through achievements, unlocked options and decisions that shape what they can do next. If advancement is too slow, their effort may stop feeling worthwhile. If it is too fast, meaningful goals can be exhausted before the product offers new ones. The economy matters here because the same milestone can feel very different depending on how rewards are distributed and what resources allow players to achieve. Rather than treating progression speed as the problem or the solution, I prefer to ask what players are learning to value along the way and whether the path towards their objectives still makes good use of the game's mechanics.

Rewards illustrate the same point from another angle. A rare resource may create excitement when it unlocks something desirable, then become almost irrelevant once players can accumulate more than they can use. A common reward can remain motivating if it supports a goal that matters. Designers therefore have to consider not only how much a particular activity pays out, but how those rewards change the attractiveness of other activities and future decisions. If the simplest task consistently offers the best progression, players are not necessarily playing the game incorrectly when they prioritise it. They are responding to the economy we designed. Fixing that relationship might involve changing rewards, objectives or the activity itself, and each option brings different trade-offs.

Engagement can also become less individual when players begin influencing one another's experience. An achievement that matters privately may acquire a different kind of value when it is visible to others; a collection can become more motivating when it creates recognition, competition or a shared objective. These mechanisms introduce social incentives alongside progression and the economy, but they need the same attention to behaviour. A leaderboard can create an appealing reason to improve, or it can teach a large part of the audience that competing is pointless. Social systems are not automatically right for every game, especially when the core experience is deliberately self-contained. Where they do fit, however, they can make engagement partly a relationship between players rather than only between the player and the product.

Throne of Legends taught me a related lesson about making systems fit the product the team could actually build. I joined when the project needed a new direction after the original designer left, and proposed moving away from its initial Hearthstone-like approach towards one inspired by Spellstone. Together with the team, we brought the revised game to launch in less than six months. The point I took from that experience wasn't a particular balancing formula. It was the importance of choosing a coherent direction within real production constraints. A mechanic may sound interesting in isolation, but it becomes harder to justify if supporting it requires systems, content or development effort that weaken the rest of the product. More mechanics do not necessarily mean more meaningful choices, and adding a progression layer is not automatically an improvement if the experience around it cannot support that layer.

This is why retention, session frequency, progression speed and reward consumption should be read together rather than treated as separate verdicts. A rise in session frequency could reflect enthusiasm or pressure to complete time-sensitive tasks; faster progression might make the product more accessible or exhaust its content sooner. Numbers tell us where behaviour changed, not always why. That distinction matters even more when rewards or progression extend across games, because incentives at platform level can influence which titles players choose and whether they enjoy the activities that lead to a shared objective. Understanding the behaviour behind a metric requires design knowledge, economic context and careful observation of the people using the product.

A strong engagement system should make the game itself more worth playing, not teach players to endure it for the next reward. Progression can connect sessions into a journey, and an economy can give effort and decisions lasting value. But if the most efficient way to advance is also the least interesting way to play, the system is sending a message that the design probably didn't intend. The question is not simply whether an incentive produced activity, but whether the behaviour it encouraged strengthened the experience we were trying to build.

3. Monetization as a Product Outcome

Monetization becomes more useful to discuss when we stop treating it as a set of revenue mechanics operating outside the game. Pricing, offers, advertising and other commercial models influence what players consider valuable, how they use their time and the choices available throughout the experience. The same purchase can feel worthwhile when it supports an objective the player already cares about and frustrating when it appears to remove an obstacle that the product created simply to encourage spending. That relationship is why I see monetization as part of product design. The commercial model has to work, but it also changes the experience that makes the model possible.

This is particularly visible in games built around progression and long-term investment. As players develop capabilities, unlock content and work towards larger objectives, they form expectations about the value of effort. Monetization can offer additional choices within that journey, or it can change the meaning of the journey itself. An offer that makes progression more convenient may be welcome; one that makes spending feel increasingly necessary to maintain a satisfying pace can weaken the player's sense of agency. These outcomes depend on the type of game and its audience. The point is not that selling progression is inherently wrong, but that a commercial decision cannot be evaluated without considering how it affects the experience players have already invested in.

Making an offer more attractive is a legitimate objective, yet the route we take matters. Clearer presentation or a product that better matches player needs can improve conversion without changing the underlying bargain. Reducing the value of ordinary rewards or introducing artificial friction may increase purchases for different reasons. Revenue can rise even while some players become less satisfied, particularly when they have substantial previous investment in the game. That doesn't mean a negative effect should be assumed whenever conversion improves; it means we should understand which behaviour changed and what made it change before deciding whether the improvement is healthy.

Merge Nymphs is one of the projects that shaped this perspective. I worked on a substantial redesign of its economy and contributed to new features, including a major dating-sim component, when the game's revenue had been declining. After that work, revenue improved substantially and the product achieved a more stable commercial trajectory. It would be misleading to reduce the outcome to one changed number or one feature: several parts of the experience evolved together, and the available account does not isolate the contribution of each change. What matters to the argument is the design problem. Resource values only become meaningful in relation to what players want to do with them; new content and systems only matter commercially when they give players worthwhile goals or choices. Improving an economy can therefore involve changing both what the player earns and what makes those earnings valuable in the first place.

Working on rewarded games later gave me another perspective on the same problem. In products built around advertising, offers and player rewards, the commercial relationship isn't always a direct purchase. The product has to create an experience people choose to engage with while balancing the value generated by that activity against what it costs to reward and acquire users. Even simple mechanics such as scratch cards, wheels or other short-session games sit inside an economy with real constraints. A larger reward can make an interaction more attractive, but its sustainability depends on the revenue and behaviour supporting it. That experience reinforced something I had already learned from more traditional game economies: monetization is not a layer to optimise separately once the game is designed. It influences the incentives that give the experience its shape.

That relationship also changes how I think about acquisition efficiency and ROI. Marketing determines how a product reaches people, but the economics of acquiring those people are influenced by what happens after they arrive. If progression is poorly paced, rewards are expensive relative to the value generated or the experience gives players few reasons to return, changing the campaign cannot solve the entire problem. In rewarded products especially, the balance between acquisition costs, advertising or offer revenue and the rewards paid back to users places real limits on which engagement strategies are viable. The commercial question is therefore not only whether we can acquire a user at an attractive cost, but whether the product can sustain a worthwhile relationship after that acquisition.

Commercial metrics still matter, but they need context. Revenue per user, conversion and average spend can reveal whether an offer or funnel is working; retention, participation, progression and segment behaviour help explain what that performance means for the product. Revenue growth concentrated in a small segment tells a different story from improvement accompanied by stable participation across the audience. Stronger conversion may reflect a better offer or greater pressure to spend. Neither interpretation follows automatically from the metric. The more useful question is whether the commercial improvement is compatible with the way we want the product to develop, and which consequences deserve further observation.

At platform level, the picture can become harder to interpret. Different games serve different motivations and commercial models; a title that earns relatively little directly may still help players discover or engage with others. Shared rewards could make that contribution visible, but they could also redistribute activity without creating much additional value. If we believe a game is improving engagement elsewhere, the relationship needs to be tested rather than used as a convenient explanation for weak performance. In a connected product, measurement should help distinguish new value from activity that simply moved from one place to another.

I don't see player experience and monetization as opposing concerns that need to be managed from opposite sides of the organisation. Both depend on understanding what players value and which behaviours the product encourages. A commercially viable game needs revenue to support continued development, but an effective revenue model cannot indefinitely compensate for an experience players no longer want. Different audiences and business models will find different balances, and not every decision will improve every metric. The aim is to develop a commercial model that remains viable because it works with the experience, rather than gradually weakening the reasons players came to it.

4. LiveOps and Continuous Product Evolution

A live game is where design assumptions encounter behaviour we cannot fully predict. Before release, teams work from experience, research, prototypes and an understanding of the audience they hope to reach. Players then discover strategies, develop routines and respond to incentives in ways that may confirm or challenge those expectations. The product that exists after launch is shaped by this interaction between the intended design and what people actually do with it. For me, that is one of the main differences between delivering a game and managing it as a live product: launch is not the end of design judgement. It is the point at which much of that judgement can finally be tested against a wider range of behaviour.

LiveOps is often reduced to an events calendar, promotions or periodic content releases. Those activities matter, but each also acts on the underlying systems. An event changes which activities appear worthwhile; a reward adjustment can alter how resources move through the economy; a new progression feature might offer experienced players meaningful goals while making the product harder for newcomers to understand. These effects can continue after the initiative ends. Treating LiveOps as an isolated function responsible for generating activity misses the way it influences the game design, the economy and the player's expectations. It is better understood as one of the ways a team changes the product, observes the consequences and decides what to do next.

Consider an event designed to help players discover content they have been overlooking. Suppose participation rises, sessions become longer and rewards are collected as expected, but most activity comes from repeating the one objective that pays out most efficiently. The event performed well against some indicators without necessarily achieving the behaviour the team wanted. Raising the rewards might create more activity, while removing the efficient route could frustrate players whose routines now depend on it. The better starting point is to ask what the incentive taught players to do. That means looking at the objectives, reward structure and experience together rather than assuming the event was successful because the numbers increased.

The period after an initiative can be as informative as the period during it. An event may generate a temporary rise in daily active users or revenue because it offers unusual rewards, while another may change how players engage with a system after the event has ended. We need to know which players participated, what they did differently and whether the change lasted long enough to matter for the original objective. Not every event has to produce a permanent behavioural shift; short-term activity can be valuable when that is the intention. But evaluating an initiative without first deciding what success looks like makes it easy to confuse a busy product with an improving one.

Experimentation helps, provided it begins with a real question. If progression looks too fast, simply reducing rewards may not address the cause; perhaps one activity dominates because the alternatives offer too little value, or perhaps the game has too few meaningful objectives once a player reaches a particular stage. A useful test identifies the behaviour we expect to change and the evidence that would challenge the hypothesis. Controlled experiments are valuable where traffic and technical capabilities allow them, but not every product can support a clean A/B test. Sometimes teams have to learn through smaller releases, careful segmentation and observation, while being explicit about what the evidence does and does not prove.

I saw the limits of evidence on a rewarded Plinko project I worked on. We explored whether level progression and variations in presentation and the pin layout could make a relatively simple interaction more engaging. The game was released, but it did not receive enough traffic for us to validate the hypothesis meaningfully. That distinction matters. A launched feature is not the same as a validated idea, and a promising design is not proof of a successful product. Some results also take longer to understand: changes to progression, resource availability or perceived fairness may affect experienced and new players differently, and their consequences may emerge only after routines have had time to change. Good live development requires both a willingness to test and enough discipline not to claim certainty when the evidence is insufficient.

The feedback loop becomes more useful when information is able to influence the next product decision, rather than simply describe the last release. Player data can help teams reconsider event design, progression pacing, reward distribution or which content deserves attention, but a faster loop is not always a better one. It can become very efficient at improving a narrow metric while gradually making the wider experience worse. If every iteration rewards the easiest behaviour to measure, the product may end up reinforcing activity that players do not particularly enjoy. What makes the loop valuable is the judgement between observation and intervention: understanding which signals matter, how they relate to other systems and whether acting on them improves more than the number that first caught our attention.

My earlier work evaluating and supporting games in a publishing environment gave me a different reason to think about LiveOps. Reviewing a project wasn't just a matter of asking whether the core concept sounded engaging or whether its economy appeared balanced. It also meant considering how much content the product would need, which systems could support repeatable activity and whether the development team could maintain the experience after release. LiveOps becomes expensive when every new objective depends on producing another substantial batch of content. Reusable mechanics, adjustable configurations and operational tools can create more options for refreshing the experience, although they should not replace content when that content is central to the game's appeal. These are design decisions with operational consequences. What players experience during an event depends partly on the invisible capabilities the organisation has built to make that event possible.

Live development works best as a feedback loop between decisions and behaviour. Teams introduce systems based on assumptions, players respond according to their own motivations, and the organisation decides what the results justify changing. Some observations deserve immediate action; others need more time, and some do not justify the cost of an intervention at all. The objective isn't to keep players constantly occupied or to change the product as frequently as possible. It is to develop an experience the team understands increasingly well and can continue improving without losing what made it worth playing.

5. When Product Growth Becomes a Systems Challenge

Product growth introduces complexity that is difficult to see from the outside. A small game can often be developed by a compact group that understands its mechanics, economy and technical requirements well enough to make decisions directly. As new features, integrations and operational needs accumulate, the same decision may depend on several teams and shared systems. The product can look more capable to players while becoming harder for the organisation to change. That is where growth stops being only a question of what else we should build and becomes a question of whether the product can continue evolving at a reasonable cost.

Every addition has a life beyond its release. Systems need maintenance, new requirements need to remain compatible with old ones and capabilities that were initially designed for a single use may become dependencies for several products. A progression framework or backend service can be reused effectively, but reuse changes the cost of modifying it. What once involved one team may now require compatibility checks, coordination and changes to several live experiences. This isn't necessarily evidence of poor design. Requirements evolve. The risk is allowing the complexity of the product to grow faster than our ability to understand who depends on what and why.

There is a more immediate side to technical scalability as well. A backend can appear reliable when the audience is small, then behave differently when more players arrive, events increase concurrent activity or several games begin using the same service. A feature does not need to be complicated to expose a capacity limit; sometimes it simply adds enough requests at the wrong moment. This changes the product conversation before launch. A promising revenue projection or an agreed release date cannot tell us whether the system is ready for the level of usage the plan assumes. Product and Engineering need to connect those expectations early, without confusing product ownership with making architecture decisions on behalf of the engineers. Getting a game into production demonstrates that it can be released under certain conditions; it does not by itself demonstrate that the wider platform is ready for success. Some of the most consequential product constraints remain invisible until the assumptions supporting them are tested.

I encountered these questions while coordinating development across a portfolio of house games at Momentum Group. Product planning involved aligning work with Engineering, QA, Art, DevOps and platform stakeholders, often when a game team depended on systems or decisions outside its immediate control. Estimating a feature wasn't simply a matter of understanding the work inside that team. We also had to identify the required capabilities, who owned them, what needed to happen first and which other priorities competed for the same capacity. An initiative could make sense for an individual title and still need a different delivery sequence once those dependencies were considered. A roadmap that looks realistic game by game can become unworkable when the whole portfolio is considered together.

There are two related forms of complexity here. Technical complexity comes from architecture, integrations and the constraints of existing implementations. Organisational complexity comes from ownership, priorities and the process by which several groups make decisions. The two do not always develop together. A company can invest in sophisticated shared infrastructure while relying on coordination practices suited to a much smaller team. It can also build elaborate approval processes without solving the technical bottlenecks slowing delivery. More structure does not automatically create more capability. The organisation needs ways of working that match the actual dependencies of its product.

That experience made ownership much more practical to me. Being accountable for a release doesn't mean that every technical capability or decision required to deliver it sits inside your team. In a cross-functional organisation, the useful question is whether responsibilities, escalation paths and priorities are clear enough for contributors to act. Part of my work at Momentum involved making dependencies and decision ownership more visible across teams, including teams I did not formally manage. The point was not to centralise every decision. It was to reduce ambiguity so that people could make progress within their own responsibilities without losing sight of a shared outcome.

Dependencies also change how development capacity is used. Teams spend time maintaining existing systems, resolving integration issues, testing changes and supporting live operations. Those activities may be necessary, but they compete with new development. A growing backlog can look like a shortage of people when the underlying constraint is actually a repeated handoff, an unclear decision or a service that has become difficult to change. Sometimes hiring is the right answer; sometimes it adds coordination overhead without removing the bottleneck. This is why organisational scalability matters alongside technical scalability. The ability to handle more traffic says little about how easily the product can be modified.

Shared capabilities need similar judgement. A system designed for every imaginable use case can become rigid through its complexity, while one designed too narrowly may be expensive to extend. An achievement framework, for example, could offer common infrastructure while leaving each game free to define the actions and objectives that make sense for its mechanics. Standardising all those objectives might undermine the games; reimplementing the whole framework for every title could waste effort. The right boundary is usually somewhere between those extremes, and finding it requires looking at both the common problem and the differences that matter.

The cost of a feature is also more than its initial development estimate. It may need analytics, configuration, QA coverage, operational support and maintenance each time another system changes. Those costs accumulate across a portfolio. Conversely, improving an internal tool or consolidating duplicated functionality can create value without producing a highly visible player-facing release. These investments are harder to compare because their benefit often appears through future work made easier or problems avoided. But ignoring them leaves a roadmap that values what can be demonstrated immediately more than what the product needs in order to keep developing.

A platform isn't scalable only because it supports more users, launches more games or employs more developers. It also has to remain understandable and changeable as its systems and teams become more interconnected. This doesn't mean eliminating complexity: some of it is the price of capabilities that are genuinely useful. The better goal is to accept complexity deliberately, with an organisation capable of managing the dependencies it creates and enough flexibility to keep building what comes next.

6. From Product Management to Product Leadership

Moving from hands-on Game Design into Product Management didn't make the details of games less interesting to me. It made their consequences harder to ignore. In Level Design, the immediate questions involved the environment and what players could do within it. In Game Design and economy work, they expanded to mechanics, progression, rewards and the choices those systems encouraged. Coordinating development across several games added a different dimension: a good decision also had to account for delivery capacity, technical dependencies, commercial priorities and what the organisation would need to maintain afterwards. I associate that shift with product leadership. It isn't a departure from design thinking; it is applying the same attention to decisions at a wider scale.

Strategy matters because it gives the organisation a way to choose between opportunities, not simply a list of things to deliver. A roadmap can communicate direction and make trade-offs visible, but it cannot anticipate every technical constraint or every insight that emerges after release. Sometimes new evidence challenges an assumption; sometimes an initiative turns out to need capabilities that do not yet exist. Continuing because the work was already planned is not necessarily the best decision. The important distinction is between remaining committed to an objective and becoming attached to one particular solution. Good execution leaves room to change the approach without losing the reason the work mattered in the first place.

Making those decisions requires connecting expertise rather than trying to replace it. A designer may understand why a mechanic could improve the experience, an engineer may see the architectural costs, an analyst may identify patterns in player behaviour and a commercial stakeholder may recognise opportunities or constraints that the others have not considered. Each is looking at part of the same product. I don't believe a Product Manager needs the depth of every specialist, but they do need enough understanding to ask useful questions and recognise when a locally attractive idea creates a wider problem. The aim is to give the team a coherent reason for the choice being made, including the trade-offs behind it.

That is why I treat communication and alignment as part of product quality rather than administrative work. When people understand what a feature is supposed to achieve, they can challenge assumptions, flag risks and suggest better ways of reaching the objective. When they receive only a specification, they may deliver exactly what was requested while overlooking the reason it was requested. Important decisions continue to emerge during implementation, because engineers discover constraints, designers refine interactions and operational teams identify consequences that were not obvious at planning time. The goal is enough shared context for those decisions to improve the product without forcing every detail through a single approval point.

At Momentum, some of the most useful work I did concerned how initiatives moved between teams rather than which feature appeared next on the roadmap. Making ownership clearer, structuring conversations about priorities and improving visibility into dependencies addressed problems that no feature specification could solve. It also reinforced my view of process: a process earns its place by removing friction or making decisions more reliable. A small team may not need much ceremony; a growing portfolio may need more deliberate planning and records because several products share people and services. More meetings and approvals are not evidence of greater maturity. If a process doesn't improve the way work moves, it is probably consuming capacity the product needs elsewhere.

Earlier, at Mega Studio, I had approached a related problem through budgeting. I built a planning model that broke roadmap initiatives into features, estimated the effort required from different disciplines—including frontend, backend, art, design and QA—and connected that work with people costs and alternative delivery scenarios. The purpose wasn't to turn strategy into a spreadsheet exercise. It was to make conversations about budgets and priorities more concrete: what exactly could be delivered, which resources would it need and what would change if we chose a different sequence of work? That experience stayed useful when I moved into broader product responsibilities. A roadmap is more valuable when its ambitions can be discussed alongside the capacity and trade-offs required to make them real.

Leadership also involves recognising how much knowledge sits outside any one person. Centralising every decision may create consistency for a while, but it can eventually slow the team and discourage specialists from using their judgement. Clear objectives, understandable priorities and explicit boundaries allow people to make decisions within their expertise while remaining aligned with the product. That doesn't remove accountability or difficult choices; it makes them easier to place where the relevant information and responsibility actually sit. A capable organisation should not depend on one person to resolve every uncertainty.

The common thread through my work in Game Design, economies and Product Management has been trying to understand why a product behaves the way it does before deciding what to change. Sometimes that means asking whether players have enough meaningful choices; sometimes it means understanding why rewards have lost value; at portfolio level, it may mean finding why a promising initiative cannot move despite the immediate team being ready. The scale changes, but the underlying approach is familiar: understand the problem, look at the systems around it and make the trade-offs explicit. What interests me in product leadership is making that approach useful not only for individual features, but for the decisions an organisation makes about the product as a whole.

Product leadership, as I see it, is less about being involved in every decision and more about creating the understanding and conditions that allow better decisions to be made throughout the product.

Conclusion: Building What Comes Next

The gaming industry has good reasons to celebrate individual games. They are what players see, play and remember, and a successful title can create enormous value. But working across Game Design, economies, LiveOps and Product Management has made me increasingly interested in what allows that value to extend beyond an individual release. Progression can give players continuity, economies give decisions weight, and operational capabilities allow teams to observe what happens once a game is live. In a platform where the connections make sense, some of those systems can support multiple experiences rather than stopping at the boundary of each title.

That perspective changes how I evaluate growth. Adding more games, progression layers or engagement features can increase the amount of content available without making the product more coherent. A useful shared capability can improve several experiences, but a poorly chosen connection can introduce dependencies, balancing problems and operational cost. The presence of systems is not proof of their value. We still need to understand what they encourage players to do, how they interact with the games themselves and whether the organisation can support them as the product changes.

The same principle applies behind the scenes. A roadmap has to reflect what teams can realistically deliver; LiveOps needs the information and tools required to learn from player behaviour; shared infrastructure needs ownership and room to evolve. Much of this work will never be visible to players, but its effects are. It determines whether new ideas can be introduced without destabilising what already exists and whether the next release benefits from the lessons and capabilities developed for the last one.

Looking back, I don't see my progression from Level Design through Game Design and economies into Product Management as a series of unrelated roles. Designing levels taught me to pay attention to the choices available in an experience. Working with economies made me think about why players value certain actions and rewards. Live development introduced the gap between what we intend players to do and what they actually do. Product Management connected those questions with the people, resources and technical constraints involved in building the product. Each perspective has made the others more useful, and together they have changed what I consider when deciding whether an idea is worth pursuing.

Great games will always matter. The longer-term opportunity is to build the right systems around them - systems that help an experience retain its value, allow useful capabilities to carry forward and give both players and teams a better foundation for what comes next.