Creative Operations for a Scaling Game Portfolio

Tripledot's integration of AppLovin's former Apps business this month is a useful, if extreme, illustration of a problem every growing publisher eventually meets: what creative operations for a scaling game portfolio actually require once the number of titles in a pipeline grows faster than the team producing for them. The specifics of that one deal matter less here than the structural question it puts sharply into focus. A creative operation built for five titles does not scale to fifteen. Asking everyone to work faster is not the answer.

Where the model breaks first

Output volume is rarely the first thing to break under portfolio growth. Most creative teams can, for a while, brute-force more variants out of the same headcount by cutting corners on iteration depth. Prioritisation breaks first: with more titles competing for the same editors, the same motion designers, the same playable developers, someone has to decide which game's testing slate gets the next production slot. Most teams have no explicit answer to that question until the queue is already backed up.

Knowledge transfer breaks second. A five-title team can hold what is working for each game in a handful of people's heads. Past ten or fifteen titles, tribal knowledge about which hook categories are fatiguing, which formats a given network rejects most often and which past concepts already failed stops circulating reliably, and teams start re-learning lessons other teams on the same portfolio already paid for.

Building creative operations that fit a scaling game portfolio

The fix is not a bigger team, at least not as the first move; it is a shared operating layer that sits above individual title teams and makes explicit what used to run on informality.

Prioritisation needs a stated rule rather than a judgement call made fresh every week. A workable starting point: allocate production slots by a blend of current spend share and recent creative fatigue signal, reviewed every two weeks, so a title burning through creative fast picks up more capacity automatically instead of through whoever argues loudest in a planning meeting.

Knowledge transfer needs a living, searchable record rather than reliance on memory. A shared log turns individual team learning into portfolio-level capital: hook categories tested per title, fatigue timelines observed, network-specific rejection patterns. It doesn't need sophisticated tooling. A disciplined shared spreadsheet, updated as part of the weekly review rather than as a separate task, captures most of the value.

As we set out in Creative concept portfolio sizing for a flat budget, sizing decisions hold up better when a team makes them against an explicit model rather than instinct, and the same discipline applies one level up at portfolio scale. Capacity planning needs to separate reusable infrastructure from title-specific production. Build the reusable pieces once and share them across titles: templates, safe-zone specs, localisation pipelines, QA checklists. That frees the individual production slots for what genuinely differs game to game, meaning the actual creative concepts and the game-specific implementation.

A worked example

Consider a hypothetical publisher moving from eight titles to eighteen after two acquisitions in one quarter, without a corresponding doubling of the creative team. Under the old model each title's producer requested resources independently, and titles with the most vocal or senior producer tended to win contested production slots regardless of actual creative fatigue or spend share.

Under a portfolio operating model, the same team allocates production slots by a fortnightly scoring pass. Each title's current spend share, its creative fatigue signal from the shared log and the time since its last major concept refresh feed into a simple weighted score that sets its slot count for the fortnight ahead. A title burning through creative fast because it is scaling spend gets more slots automatically; a stable title with low fatigue gets fewer, freeing capacity for where it actually matters. Headcount hasn't changed. The eighteen-title portfolio just allocates its existing capacity against evidence rather than against whoever asks first.

The role that usually goes missing

All of that assumes someone is watching the shared layer full time, and that role is the one most growing publishers skip while they are busy absorbing the new titles themselves. A portfolio operations lead, distinct from any individual title's producer, maintains the fatigue log, enforces the prioritisation rule when a senior stakeholder tries to jump the queue, and notices when reusable infrastructure has started drifting out of date across titles onboarded at different times.

Without that named role the operating model degrades quietly rather than failing outright. The shared log stops getting updated within a few weeks because updating it is nobody's explicit job, and the prioritisation rule survives on paper while informal exceptions pile up underneath it. Six months later the team is back to allocating production slots by whoever argues loudest, just with an extra document nobody consults. Hiring or designating this role early, even part time against another responsibility, is usually cheaper than rebuilding the operating model from scratch once it has quietly stopped working.

What to put in place before the next acquisition

• A written, scored prioritisation rule for production slots, reviewed on a fixed cadence rather than decided ad hoc each week.
• A shared, searchable log of hook categories, fatigue timelines and network rejection patterns that survives any single team member leaving or moving titles.
• A clear split between reusable infrastructure, built once, and title-specific production, so growth in title count does not automatically demand proportional growth in headcount.
• A named owner for the portfolio-level operating layer itself, distinct from any individual title's producer, so the shared system has someone accountable for maintaining it.
• A trigger point, defined in advance, for when title count genuinely does require more headcount rather than a better operating model, so the team is not permanently trying to solve a capacity problem with a process fix alone.

Portfolios grow in steps, usually through an acquisition or a fast run of new launches, rather than smoothly. Building the operating model before that step arrives, rather than after the queue has backed up, is the difference between absorbing growth and being visibly overwhelmed by it in front of the studios whose titles just joined the pipeline.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• Creative Hook Variety: Designing Ads for Mobile Games
• Creative concept portfolio sizing for a flat budget