<h2 data-toc-id="opening" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">Before You Choose a Monetisation Model, Make Sure Your Studio Is Ready for One</h2>Over the years, I've seen a few teams spend a surprising amount of time debating which monetisation model to choose.Looking back, what strikes me isn't that they were asking the wrong questions. It's that the decision often depended on things nobody around the table was really discussing yet.I remember one studio that almost copy-pasted the monetisation model of another game that was performing extremely well.Partway through the project, conversations started about changing direction. The team had realised their retention simply wasn't compatible with the model they had initially chosen.I left the company before I knew how that story ended. But it stayed with me because I found myself wondering whether changing the model was really the question they should have been asking.Looking back, the question that stayed with me was:<blockquote style="border-left: 3px solid rgb(236, 124, 0); padding-left: 16px; margin-left: 0px; font-style: italic; color: rgb(90, 90, 90);">Were we ever ready to support this model in the first place?</blockquote>It made me realise that choosing a monetisation model isn't only about deciding how a game will make money. It's also about understanding what your studio is actually prepared to sustain.<hr><h2 data-toc-id="operating-model" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">Choosing a monetisation model… or an operating model?</h2>I've gradually come to believe that teams rarely choose just a monetisation model.They're also choosing an operating model, whether they realise it or not.Every monetisation strategy comes with a set of organisational requirements attached. Some studios already have them in place. Others discover them halfway through production, or worse, after launch.A battle pass assumes a content cadence the team can sustain. A hybrid of ads and in-app purchases (IAP) assumes a level of data maturity many studios are still building. A subscription model assumes retention that's already proven, not simply hoped for.None of that makes one model better than another. But it does mean that the conversation shouldn't stop at "Which model should we choose?" It should also include "Are we ready to support everything this model requires?"<hr><h2 data-toc-id="three-questions" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">Three questions worth asking</h2>I've found three questions that tend to reveal whether that gap already exists before a single euro of user acquisition (UA) budget is spent.<div style="background-color: rgb(247, 242, 236); border-left: 4px solid rgb(236, 124, 0); padding: 16px 20px; margin: 20px 0px;">❓ Does the monetisation model actually fit the retention curve you have today, rather than the one you're hoping to achieve?❓ If your UA and Monetisation teams described what's working, would they tell the same story, or two different ones?❓ Has anyone mapped what this model will demand from Data and Live Operations (LiveOps) six months after launch, not just on day one?</div>Individually, these questions aren't particularly complicated.However, in the situations I've experienced, these conversations didn't always happen together, with the same people, at the same time.And that's often where the disconnect begins.<hr><h2 data-toc-id="business-decision" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">Why this stops being a game design decision</h2>The more I reflected on these situations, the more I realised this wasn't a decision any one team could make on its own.Product, UA, Monetisation, Data, Finance and Leadership all influence whether the chosen model succeeds.The challenge is that every function naturally optimises for its own objectives. UA improves acquisition efficiency. Monetisation focuses on revenue. Data builds reliable dashboards. Finance watches profitability.Individually, everyone may be making sensible decisions.Collectively, though, those decisions can start pulling in different directions.A key performance indicator (KPI) that looks healthy from one perspective may quietly create problems somewhere else. Day 1 retention (D1) and Day 30 retention (D30) don't always push teams toward the same decisions. Average revenue per user (ARPU) and average revenue per paying user (ARPPU) can tell very different stories about the same player base.None of these metrics are "wrong." The problem is that they don't always point in the same direction.<hr><h2 data-toc-id="what-surprised-me" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">What surprised me most</h2>When I first started sharing some of these concepts with wider teams, I expected people to leave with a better understanding of the foundations of monetisation. However, what surprised me wasn't what people learned about monetisation. It was what they learned about each other.People started seeing how decisions made in one department created consequences several teams away.People who had spent years optimising their own area suddenly had a clearer picture of how everything connected. Designers better understood UA constraints. UA teams gained more appreciation for LiveOps.It became less about learning monetisation, and more about understanding the system they were all contributing to.That reminded me of something I hear surprisingly often from people across studios:<blockquote style="border-left: 3px solid rgb(236, 124, 0); padding-left: 16px; margin-left: 0px; font-style: italic; color: rgb(90, 90, 90);">I know what I'm supposed to do. I'm just not always sure how it affects the bigger picture.</blockquote>Helping people answer that question may be one of the most valuable outcomes of all.<hr><h2 data-toc-id="closing" style="color: rgb(236, 124, 0); text-align: left; font-size: 24px; line-height: 1.2;">A closing thought</h2>The more teams I work with, the more I think many monetisation problems begin long before anyone looks at revenue metrics. They begin with alignment.With teams making individually sensible decisions that don't quite add up to a coherent strategy.That's one of the reasons I created the <a target="_blank" rel="noopener noreferrer" href="https://www.sparking-waves.online/course-detail/monetization-basics-for-game-studios/41277/">Monetization: What Every Team Member Needs to Know </a>module.It's not about turning everyone into monetisation specialists.It's about helping people understand the consequences of the decisions they're making together, how retention influences monetisation, how UA and LiveOps depend on one another, and why a successful business model is often as much an organisational challenge as it is a design choice.If this article made you think about your own studio, I'd genuinely love to hear your perspective.Have you ever seen a monetisation model struggle, not because the model itself was wrong, but because the organisation wasn't ready for everything that came with it?

Most studios choose a model before checking if they can support it. Three questions to ask first, and why the gap rarely comes from bad decisions.

What Are You Really Choosing When You Pick a Monetisation Model?

Before You Choose a Monetisation Model, Make Sure Your Studio Is Ready for One

Choosing a monetisation model… or an operating model?

Why this stops being a game design decision

Read articles, tips, and resources to help you learn, grow, and succeed. Explore our latest posts covering education, community, and personal growth

Blog – Insights, Tips & Resources for Learning and Growth

Explore articles, tips, and insights to help you succeed in learning, community building, and personal development.

What Are You Really Choosing When You Pick a Monetisation Model?

What Are You Really Choosing When You Pick a Monetisation Model?

Related Posts

The Myth of the “Magic” UA Creative Formula