Amir Lev-Ran- Director / Head of Product · ex-Playtika (9 years), ex-Dragonplay · Plunge Games

When a Day-7 number drops, the instinct is to find the broken feature, then ship a fix, add a LiveOps event, or reset the tutorial. I've seen this at companies of every size, from Dragonplay, where I was one of the first employees, through nearly a decade at Playtika, to building Quiiiz from scratch.

And in most cases, the instinct leads teams in the wrong direction. The feature is rarely what's broken. What's broken is the operating model underneath it: who owns the funnel end-to-end, how quickly data reaches the people who can act on it, whether onboarding and retention are even coordinated with each other.

The Misdiagnosis Trap

Here’s how the conversation usually goes when retention starts slipping: A large meeting is called, numbers go up on the screen, and each department explains why their part isn't the problem while quietly pointing at someone else's. Then comes the sentence that ends every one of these meetings:

"We just need to do this one thing and the numbers will improve."

It doesn't work. Retention is a process, and a single feature can't fix a broken process.

The deeper issue is timing. By the time a retention problem shows up in your dashboard, the feature that caused it shipped two sprints ago. The decision to even build it in the first place was made six weeks before that, using stale data, unclear ownership, and a team too underwater to ask hard questions.

Before moving to the next idea, the last one deserves a proper diagnosis: what specifically didn't work - was it the design? The economy? The user communication? A few targeted iterations on art, pricing, or notification timing will tell you more than abandoning the feature entirely, and that knowledge compounds into every future decision.

I made this mistake myself when we built Quiiiz’s first retention feature: a simple challenge mechanic where players completed a set number of games to earn a bonus free game. We built the feature properly on the surface — the UI was good, the UX was solid, and the configuration system was there — but retention barely moved. We kept trying to improve the presentation, when the real issue was the economy behind it. The reward itself was not appealing enough to drive the behavior we wanted. That was the mistake: we ran to build the feature before thinking hard enough about whether the underlying economy could make it work.

Three Operating Model Failure Modes

If your team is making good decisions slowly, or fast decisions on bad information, the problem is structural. These are the three failure modes I see most often.

1. No single owner for the funnel end-to-end. Onboarding sits with one team, retention with another, LiveOps on its own cadence. Nobody owns the arc from install to loyal player, so nobody is accountable when it breaks. The result is three departments each solving a different symptom of the same underlying problem, usually without realizing it.

2. The insights loop is too slow. When your data team, product team, and LiveOps team aren't on the same cadence, signals take too long to travel from user behavior to a decision. I've watched teams consistently react to last month's numbers while this month's problem quietly gets bigger and bigger. Retention is a data game, and if the data isn't moving fast enough, you're always behind.

3. Onboarding and retention are treated as the same problem. They're connected, but they need to be measured separately and approached with different goals. Onboarding is about building familiarity - helping a new user form a connection with the product. Retention is about deepening a habit that already exists.

When teams blur this distinction, they push retention mechanics too early, frustrate new users, and then neglect onboarding follow-through by assuming it's someone else's problem once the tutorial ends.

What a Functioning Cross-Functional Model Actually Looks Like

An org chart isn't an operating model. What matters is the rituals - the weekly review, the shared dashboard, who has the authority to pause a build, and what happens when the data shows something nobody wants to hear.

The functioning models I've seen share a few consistent properties:

There's a weekly retention review that sits above individual team cadences. Someone arrives with data, someone else with product context, and together they decide what moves next. At Playtika, the rule was simple: we couldn't leave without a decision written down. That single constraint changed the quality of every conversation in the room
Ownership is explicit, not assumed. Someone is accountable for D1, someone for D7, someone for D30 — and those people are named, not inferred from a job title
Communication is designed to surface signals, not produce summaries. When something meaningful changes in user behavior, the right person hears about it before the next sprint planning

“Retention improvement is not a sprint. It’s an ongoing process of iteration, measurement, and honest diagnosis. The teams that do it well have internalized that — and their operating models reflect it.”

One practical note: resist the temptation to over-segment. Breaking down user behavior is valuable, but the more granular your cohorts become, the harder it is to act decisively on what you find. Segment enough to make good decisions, and no further.

The Backoffice Connection Nobody Prioritizes

Internal tools are almost always treated as a second-class priority. They're invisible to users, unglamorous to build, and there's always a PM ready to say "we'll do it manually for now and improve it later." The ops team is rarely fine with this arrangement, and the cost compounds every week.

I watched this play out at a company struggling with both retention and operational speed. The team was configuring and setting up features under constant time pressure, working with a fragile system and a fully manual setup process, and the stress was affecting everything — the atmosphere, the output, the people.

So we stopped and interviewed every person on the team about their actual workflow, what slowed them down, and what they thought needed to change. Then we put the findings on the table and prioritized them together.

What we built wasn't glamorous: a configurable, multi-segment, dynamic system for setting up recurring game events. But it led to real, org-wide results:

The marketing team could plan a full week in advance
The ops team cut setup time by 75%
We shipped in stages over four weeks, so the team could see progress as it came

The team had headspace again — to validate their work, generate ideas, and actually think rather than execute on autopilot. That's the real ROI of a good backoffice system.

Building Quiiiz from scratch reinforced that for me. From day one, I treated the backoffice as a real product, not just a helper layer behind the game. The operational team needed to be able to understand the player clearly, configure the core loop easily, and manage communication without friction — so the backoffice had to be designed with the same seriousness as the player-facing experience. What I got wrong, even with that mindset, was the onboarding. Some of the field names and parameter definitions made sense to me but weren’t clear enough to the people actually using the system day to day. That created confusion, mistakes in configuration, and eventually extra work to rename variables and re-teach the system. A backoffice system is not finished when it technically works. It has to be immediately usable by the team operating it.

“If your ops team is running through mud to keep the product live, your product team is flying blind, because the retention signals they need are buried in manual workflows nobody has time to read.”

Onboarding Is a Systems Problem, Not a UX Problem

When an onboarding flow underperforms, the first instinct is to redesign it, like changing the tutorial, simplifying the first session, or adding a reward at step two. Sometimes that's the right call, but more often than not the real issue is that nobody owns the full arc from install to first meaningful session. And, there's no defined loop for testing and learning from what happens in between.

A simple prioritization model helps when deciding what to focus on and fix. Score each proposed change across three dimensions:

Its impact window — D1, D7, or D30, since not all onboarding improvements affect the same moment
Effort, whether it's a copy tweak or a new flow
Reversibility, how quickly you can undo it if it goes wrong

A Quick Operating Model Audit (Run It Tomorrow)

You don't need an external consultant to identify whether your operating model has a problem. Five questions will tell you:

Who owns retention end-to-end — can you name one person? If you can name one person, that's a strong foundation to build on
How long does it take for a significant behavioral signal to reach a product decision? Teams that have closed this loop — getting from user behavior to action in days rather than weeks — consistently make better decisions over time
When did you last run a structured post-mortem on a feature that didn't perform? Teams that do this regularly get smarter with each cycle, because the learning compounds
Do the people setting up your LiveOps events have the tools to do it efficiently? When they do, they shift from execution mode into optimization mode — and that's where the real gains come from
Do your onboarding and retention teams share a roadmap? When they do, they're pulling in the same direction, toward the same user

If any of these surfaces an opportunity, that's a good place to start the next leadership conversation about retention (before jumping to a feature proposal).

The Pattern That Actually Works

Studios that sustain retention at scale — the ones running LiveOps-heavy titles like House of Fun or managing a Playtika-level portfolio — don't succeed because they have better product ideas. They succeed because they have better systems for testing, learning, and iterating quickly.

After seeing this pattern from the inside at early-stage companies, at scale, and building from zero, the conclusion is consistent: when retention breaks down, the feature is rarely where the problem started. Fix the operating model first, and the product decisions that follow will be better for it.

Amir Lev-Ran is a Director/Head of Product consultant at Plunge Games. He spent nearly a decade at Playtika, was one of the first employees at Dragonplay, and co-founded and led Quiiiz.

PlungeGames · Full-service game growth consultancy · plunge-games.com