First, we were planning to design an article that explains how a professional mobile games publisher should work. But then we realized you would find this out by yourself  — for instance, from the attractively sounding presentations at conferences, previously checked by a bunch of lawyers one after the other. Thus, we have decided to present a sincere article (containing memes!) about what will happen to your gaming project after you, a mobile game developer, have signed a contract with a publisher. 

Now it’s not only your game 

We are not talking about intellectual property here. If previously you were responsible for the entire product representation, now a lot of decisions are going to be made together with the publisher and the publishing producer assigned to your project. He has his own KPIs and goals here, his own ideas, and his vision of the project. 

Have you already mapped out a roadmap and feature list? The producer will bring his own one and will try to merge it with yours. You spent a long time brainstorming and have finally decided to make VFX more appealing, strengthen the narrative of the mid-core, and remake the tutorial entirely? We will likely cancel everything because: 

1. We have already tested this on a similar project;
2. The other feature is more important, so it’s better to start producing it first because it will boost our ARPU/increase average check/escalade conversion from free users to paying customers;
3. This feature should be designed in a different way — this will allow us to save time and money while the result stays the same;
4. This and that should be analyzed first;
5. And this should be implemented only after it has been A/B tested (‘Or over my dead body!’ — says the producer);

A lot of developers are going through emotionally tough times when publishing employees start bringing their feature ideas to the project. This is perhaps the main emotional difficulty for developers in general when working on their own projects. The idea can be successful enough, but still — it is not your idea as a developer. That means if the idea performs, you will have to admit you were not the only one who has contributed to the success of the game. At this point, the responsibility for the vision of the project will lie with the publisher.

It is even worse if the feature is not working. Not all solutions are universal, and not all the publisher’s ideas lead to large profits. Nonetheless, their ideas have a head start over the developer’s since they have already tried and tested tonnes of different projects, features, and solutions. 

“But the producer doesn’t understand my game as I do,” — you object. Yes, they might not know your game backward — however, they have seen hundreds of similar projects and understand what really works.

And sometimes you cannot just take a reliable feature from the “feature database”, because even good existing features have to be renewed — for instance, with new approaches. This is where the main dread lurks: an overwhelming majority of developers hate A/B tests for some reason. Seemingly, it should be the other way around: if in doubt — test it. But in reality, it doesn't work that way. We are not sure why, but the fact is: it is easier to convince a developer to put an undesired feature into the release than the same feature but tested.

Distinguishing a good producer from a bad one

To be honest, in classic mobile game publishing, the producer has no leverage and can simply be turned down. But the thing is that producers who are easily turned down do not stay afloat for a long time. Being polite and, at the same time, convincing is a necessary quality of a publishing producer. We will teach you monetization — but the soft skills have to come naturally.

Try to understand the producer. They dive into your roadmaps not because they’re bored but because of greed. And this is in your interests — remember, we share the revenue.

It is unfavorable if the producer does not take the initiative, and his whole role consists of accounting or the kind of ‘useless’ advice such as “let's do good and don't do bad”.

How can you figure out whether you work with a good producer or a not-so-good producer? Ask your producer on what grounds they recommend changes:

Another misfortune is if the producer still has a lot to offer, but instead of a hand to guide you, they treat you like a puppet. Everyone has heard stories about publishers Who-Must-Not-Be-Named seducing developers with a guarantee that this is still going to be your product and whispering in your ear: "Cmon, these are all rumors, maybe we took over a project — but only once. We swear you will have all the control over your game!".

But your control stops right from the moment your successful project starts stagnating — and stagnation is inevitable. Or even earlier, in case the publisher decides that you just waste the budget.

Advice like “check the contract with a lawyer” would barely help here. But this pitfall is easy to avoid. Just find founders or studio executives who used to work with this publisher and ask them what the publisher did when their flagship started to stagnate? Positive recommendations are not hidden behind NDAs.

The workload increases, while the speed decreases

The publisher takes on an extensive list of responsibilities. It would seem that you can finally let go of part of the tasks and relax. But that is clearly not the case! Now you should perform an infinite number of routine tasks: 

• Create dozens of events for analytics, add analytics literally wherever;
• Design internal systems for A/B testing;
• Design a system for the segmentation of offers and waterfalls;
• Combine all the assets in the game, structure them, and constantly update them on demand from the marketing team. “All assets” means just that, for example, if you have animation existing only as a prefab in Unity, you will have to upload it as sequences in PNG. The task is not too difficult, but someone from your team will have to do it and spend some time on it;
• Connect a publishing force-updater;
• Connect custom payment validation.

What’s the result of adding all these tasks to our “To Do List”? We get more technical tasks, and at some point, we need to fix technical bugs in order to implement everything correctly. Instead of Brave New Worlds, we build brave new segmentation systems. 

In a perfect world, you would only need to complete some of these tasks once. But there will also be a lot of permanent tasks. For example: adding new content, correcting the balance, testing prices, updating adapters, integrating new services, and much more. Yes, we do understand what a “library conflict" is and how it hurts. But what can you do if the expected profit from this work is much higher than from an equally complex feature that you have desired to implement?

At the same time, the project’s development pace will slow down because all the updates must initially be analyzed and launched for a limited number of users. If you are used to doing everything quickly, you will have to adjust to the new pace of work.

Thus, for example, implementing a forced updating solution saved our publishing multiple times. These were situations when we had to upgrade to a new version of ad adapters or Facebook SDK and make sure that our entire audience was updated to the required version within 24 hours.

In addition, a forced updating solution makes it possible to deliver a critical bug hotfix to the entire audience simultaneously.

As for custom payment validation, we tried three different solutions, and each time we found new drawbacks to using them. Tired of searching, we designed our own solution. Yes, it is imperfect too, but at least its bugs are under our control. And we are able to fix them all at once, without digging into the problems of external services.

If you are convinced that your project does not need any validation, it means you simply never got a fake $15k per each real $1k of purchases. You will not even notice it, but your user acquisition campaign will drop down to nothing while the data engineer, sighing heavily, cleans up the raw data with semi-manual scripts (and he really won’t enjoy it). And media buyers will go bald because of working under stress — no one is going to give them their hair back.  

Your autonomy will decrease

If previously you were responsible for the entire product representation, now a lot of decisions are going to be made by the publisher.

The publisher is in charge of the support and community management, as well as choosing localization, analytics, and game porting studios. It’s not always guaranteed that these services will work better than the ones you have chosen. For instance, there have been cases in our practice where developers were finding bugs in localization software. There have also been cases where our support manager, while trying to make a joke, was actually being quite rude to a user. 

But only publishers have the resources to try almost all localization software available on the market and to build a pipeline for hiring, training, and, unfortunately, firing employees. And you, the developer, do not. And even if you do, it would be much more efficient to direct them to something else. 

Got used to working with a “pure” AdMob ad network before? Now there will be 10 ad networks connected at once, and the ads there are not the most appropriate, however profitable. For example, you will need to get used to 45 seconds long rewarded videos combined with playable ads there.

Previously, you had been running 10 creatives that took a month to draw? Now there will be 100 of them, but each one should contain relevant mobile advertising trends (about pregnant women in difficult situations, for example).

The game title is badly indexed, so the publisher will likely change it. And the app page in the store won’t be optimized the way you want, but it will be the best way to get the highest conversion rate. If for you the app icon is the embodiment of your idea, then for us, it is a reason to get an additional 3% of conversion and a profit of around $200,000. 

That means “Hello, yelling man on the app icon” — in fact, this approach is already out of style, now the highest performing icons are those containing top creative elements.

This is what we had, for example, with the mobile game Doorman Story: Hotel Team Tycoon, where the player has to develop their own hotel. Our top creative showed non-existent gameplay. It was not a complete fake, but sort of a fantasy about “what could possibly be in the game” (we also call it meta misleads). We designed the app icon and screenshots in the app stores to be identical to this creative. Result: +10% conversion to install with no damage to retention.

Moreover, your project is now on the publisher's accounts. If you want to release it — you are welcome, but first, it is going to be tested and approved by the publisher. Only then will it be launched. And they will do all of this on their own, because they are in charge of this process.

If you are used to 2 releases a day with minor patches, now we are merging it all into one big update. Testing avoids suffering losses due to stupid mistakes. Nobody wants to launch an incompletely tested build to an audience of over a million and lose $50,000 in a matter of hours. We feel the same way.

Once, a small hotfix, released without testing, instantly decreased all our metrics for a few days. The reason was simple — we were in a hurry and used a different computer to build this hotfix. As a result, we made this hotfix with a bug that broke one of the key game mechanics. But the initial testing did not reveal this, and they considered it unnecessary to test a single tiny fix according to the checklist.

Marketing campaigns at that moment were working to the fullest. However, we had underearned by about $40,000. The support went through a lot at that time — they processed several thousand identical messages over one weekend.

Since then, there have been no exceptions. From an audience of 100 thousand users, the build goes to release only after confirmation from two independent QA specialists.

If you have read this far and are now worried that the publisher will take away your project vision and abuse your game, we have good news for you: the better you handle the project yourself, the more autonomy you have. If you need to be led by someone, we will do it: provide you with working ideas, determine the focus of your project, and prioritize the features. If you have 100 years of experience in your game genre, you know better than us what to do and how to do it. There is no doubt, you will do your producer a favor by removing the need for micromanagement. Therefore, training is for those who need it, partnership is for those who can cope on their own.

The development focus will change

A developer rarely lacks new ideas, but, as a rule, when coming up with features, the developer does not take into account monetization — you just want to implement something interesting and desirable as soon as possible. Now everything will change: from the beginning of working with the publisher, you will be engaged in the monetization process from ⅓ to 100% of the time.

And this is not just about dragging the offer icon across the main screen until the conversion is maximum — this is about prioritization, calculation of the new content production efficiency, and the most efficient resource usage.

Therefore, the late content rendering may be paused until it is statistically proven that a sufficient proportion of players will see this content at all.

If you cannot decide on the setting for the next game chapter, the publisher will help you with this. He will also help with determining the way of game development. There will even be special research conducted by the publisher. However, it is almost impossible to choose the setting by simply listening to your heart — all changes should first go through research, insights, and tests on fake videos and screenshots.

For example, when we were choosing the setting for a new hotel in Doorman Story, we were running tests on fake shots for quite a long time. This determined the way of the game development for six months ahead. Out of 5 ideas, it was necessary to choose 3 and determine the order of their implementation. As a result, we selected the highest-performing settings and prioritized their appearance in the game. Moreover, during the test, we also found an idea for the next game. We began to test this idea as a separate preproduction — and recently, it was released.

Your project has a priority

The publisher team will determine the prioritization of your project — this is unavoidable. Remember that you are guaranteed to have a specific time for calls and syncs, but at other times your producer may be busy. Therefore, in order to get an answer to your urgent question, sometimes you have to wait.

In addition, the publisher ranks projects based on actual or expected profit. The more profitable your project is, the more time will be given to it. This means your tasks will be completed faster, and more marketers will be working with your project simultaneously, more creatives will be produced, and so on. 

If you have already tried all the options of "reanimation" of your product, and have tested all the approaches and optimizations, but there is still no profit, you can expect your game to be returned to your account. The good news is that if a publisher intends to do so, you will be warned about it first. And if the whole studio earns from this project, the publisher may leave the project on a small stream of traffic, so that you have something to live on from organic users.

On the other hand, there are strange prejudices around priorities, which are stem from the market going back about 10 years in the past. These are myths about how publishers tend to bury tonnes of worthy projects, since there is something better in their portfolios, and there is no room left for second-tier projects. The market simply doesn’t work like that.

Of course, we will still be acquiring traffic for the project, even if it is not the top-performing one. There is no “cash gap” for a publisher. In any case, we can easily expand credit lines, connect acceleration or get the cash out of the nightstand.

It all comes down to a simple question: is the project capable of generating at least X profit per month? If the answer is “Yes,” — great, it is about ensuring that you have enough attention and unmissed opportunities. If the answer is “No,” — no one is going to hold your game hostage.

The publisher will not work on a loss-making project, even if you really want to revive it in any way. It would be better if we design a new one with you: brainstorm, generate ideas, and gather insights from the market. Development is on you — marketing and worthy pre-production is on us :) Let's talk.