First we were planning to design an article that explains how a professional mobile games publisher should work.
But then we realised you will find this out by yourself — for instance, from the attractively sounding presentations on conferences, previously checked by a bunch 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.
Everything is going to change: you used to have absolute control before working with a publisher.
Literally everything: from the app icon in stores to event start time.
But now you are not the only decision-maker, and all decisions should be made together with the publishing producer assigned to your project.
He has his own KPIs and goals here, his own ideas and vision of the project.
You have 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 midcore, and remake the tutorial entirely?
We will likely cancel everything, because:
- We have already tested this on a similar project;
- 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;
- This feature should be designed in a different way — this will allow us to save time and money while the result stays the same;
- This and that should be analysed first;
- 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.
An overwhelming majority of developers hate A/B tests for some reason.
This is perhaps the main emotional difficulty for developers in general when working on their own project. The idea can be successful enough, but still — it is not your idea as a developer.
That means if the idea will perform, 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 profit.
Nonetheless, their ideas have a head start over the developer’s, since they already tried and tested tonnes of different projects, features and solutions.
“But the producer doesn’t understand my game like I do” — you object. Yes, they might not know your game backwards — 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
- The workload increases, while the speed decreases
- Your autonomy will decrease
- Development focus will change
- Your project has priority
Or cut to the chase. Let's talk!Click here to view the list »