Game as service has become the default model in the mobile sphere. More often than not in that context “service” refers to the regular release of new content – whether it’s game modes, new levels or new items/characters/skins for purchase.

There is a fundamental aspect of service that is too often overlooked in all this. Without even going into the etymology of the word (google tells me service comes from the latin servus: slave), at the core of the notion of service lies the idea doing something for someone else. To serve is to provide something for someone else – not what the person serving wants to provide. It’s to provide what the recipient wants. Namely, catering to the users’ needs, preferences and desire.

Your game is not your game

One crucial thing to never lose sight of is that we don’t control what users do – the way they play our games. Of course, you are probably designing your game with some specific intention in mind (the way the game ought to be played). But user behavior will never perfectly match that design intention. The degree to which it differs can greatly vary – and I’m not even convinced the most successful games are the ones where the design intention and user behavior match the most. And that’s not (necessarily) the result of bad design, implementation or product strategy. An important part of the success of a game is simply out of our hands. That doesn’t mean we shouldn’t do everything we can to try to improve game performance – but it does have implications when thinking about how we can try to improve game performance. If we say “game as service” means giving users what they want and what’s most convenient for them, then we should start by being clear on what users want. And what users want is not always what we think is cool (or even what really is cool).

There are some clear and consistent behavior patterns that are found across all games. That applies to high level socio-economic factors: there are strong play patterns that follow the time of day or day of the week – and those patterns might be less pronounced during the summer. Conversion is something that consistently occurs early. Users who return to a game usually do so within a few hours of install, etc. So maybe you can decide you want to get users to play Wednesdays at 3:00am. Any system you come up with will probably be successful in getting a few individuals to come play according to your plan. But on aggregate you won’t be successful in leveraging your userbase.

The same logic also applies when considering game features and systems – although here we’re more at the level of cultural trends and audience preference. You might design the game with a specific intention in mind, but ultimately once it’s out in the wild users will play your game as they please – not as you intended. Maybe you designed an elaborate loop where users need to play PvP in order to get a resource that will provide them with a unique upgrade and a specific benefit in the campaign mode. Once your game is out there, you might see your users don’t play PvP – at all or as much as you were expecting. Or maybe users play PvP but don’t bother with the new upgrade tree – because they don’t find that benefit appealing or it’s too complicated or convoluted. Once you see that’s the case, what are your options?

The main question in that context is: is the goal to get users to play PvP, or is your goal to better monetize your users (or any other outcome)? There’s a (very mistaken in my opinion – and backed up by quite a few examples) belief that the sunk cost fallacy will be a strong motivator for user behavior in your game. I’ve rather seen that this applies more to people in the gaming industry. Having spent time, effort – and love – into a feature isn’t enough of a reason to make users engage with that feature. One of the big risks is when your game becomes an end in itself. In other words, when you’re focusing on what your game is more than what it does.

What do you do when users reject what you put your heart and soul into? If users are not interested in the PvP game mode or in the new upgrade loop, should your goal be to make them play it anyways, or find ways to cater to what they are already doing – and build on that? Making games is not making a statement or a work of art – it’s making a digital entertainment product. The end goal of your game shouldn’t be your game – it should be giving users what they want. If users are not playing the way you want or expected, then there are 2 main options. You can choose to double down and increase your efforts to change user behavior, or you can pivot your design intention and see how you can make the most of an established user behavior.

The way to improve game performance usually isn’t to get users to play the way you want to. That’s because mobile games are a modest and marginal part of our users’ life. Users won’t reorganize their daily obligations or change their personal preferences to play a game – they’ll probably stop playing that game and find another one that will better match their preferences instead. The best way to improve your game performance will usually be to identify what users like the most and provide it to them. So, what is the starting point of your design process?

Of course, data is key to having a service driven process. By analyzing your game – and asking the questions that will help you (in)validate your hypotheses concerning user behavior and motivations – you will be able to identify what users might want.

Don’t try to make users play a way you know how to monetize – find a way to monetize the way your users are playing

The above problem doesn’t only occur when thinking about game features and systems. It also (mostly?) happens when considering monetization strategy.

Say you wanted to implement the PvP loop because you wanted to monetize a new PvP consumable (or the upgrade for campaign mode). You will need users to play PvP, because that’s how they will in turn start engaging with the new monetization loop you thought about.

The problem in this case occurs when you start with a plan to monetize a certain way – then try to get users to play in a way that will achieve your monetization design. There is another, better approach. It might require more creative thinking, but that will probably be more successful in both the short and long run. Instead of starting by an abstract and isolated monetization design – and foster the user behavior you need to get that monetization loop to work – you can start by finding ways to monetize existing behavior. It will probably be more effective to devise ways to monetize existing play patterns rather than changing play patterns to engage with a monetization plan (that only works in theory at that point). In case you don’t succeed on the first shot (which will more often than not be the case) it will also be much faster/cheaper to iterate off a monetization design than trying to make a significant change in user play patters.

Creating a new behavior is something you never totally control. You have one plan in mind, but users choose to go in a different direction. Changing an established behavior is at least as hard to accomplish. But this resilience of user behavior can turn out to be a huge asset. If you find a way to leverage an existing behavior and cater to it – monetize in a way that goes along with it and reinforces it – then you are in a situation where you have a very robust and sustainable monetization flow. You’re not trying to modify a natural pattern – you’re going along with and capitalizing off an established pattern. When game as service consists in giving users what they want, everybody wins.