Jingna Zhu on Why “Almost Ready” Is Dangerous in Game Production

A conversation about feature delivery, live operations, ownership, and why production risk often appears after a team thinks the hard part is already done.

Context

Jingna Zhu is a Producer and Project Manager with experience across game production, live service, product delivery, cross-functional coordination, and global product teams.

Her background is interesting because she has worked across both games and tech, where delivery is not only about planning tasks, but about keeping many moving parts connected: engineering, QA, localization, release management, publishing, marketing, stakeholders, and live operations.

This interview focuses on a production problem that many teams underestimate: “almost ready” is often the most dangerous stage.

A feature may look close from the outside, but hidden dependencies, unclear ownership, late feedback, QA issues, localization gaps, release timing, or live service pressure can still turn it into a real production risk.

The goal is to understand what delivery readiness actually means, why tools and meetings are not enough by themselves, and how producers help teams keep the real goal visible when production becomes messy.

↓ VSQUAD’s work for Ruined King: A League of Legends Story

Main topics

• Game Production
• Feature Delivery
• Release Readiness
• Live Service
• Production Risks
• Cross-Functional Collaboration
• Team Ownership
• Product Management

Interrview

Q: In game production, why can “almost ready” be such a dangerous stage?

“Almost ready” is dangerous because that’s usually when teams discover whether a feature actually works within the full production pipeline, not just inside the implementation itself.

I’ve seen cases where a feature looked complete and worked as intended in development, but issues only appeared once localization started. For example, concatenated strings may look perfectly fine in English, but break in other languages because of word order, gender rules, or plural forms.

Sometimes localization also exposes technical dependencies that were easy to miss earlier, for example, nested assets that require Blueprint changes or additional implementation work.

↓ VSQUAD’s work for Ruined King: A League of Legends Story

Another common example is content review. An asset can pass functionality testing and QA, but still run into problems related to age ratings, regional regulations, or cultural sensitivity requirements in specific markets. None of these issues are visible when a team is only looking at whether the feature technically works.

What makes this stage risky is that these discoveries happen very late, when release plans, QA schedules, localization timelines, and stakeholder expectations are already moving forward. At that point, even a relatively small issue can affect multiple teams and create delays that are much harder to absorb than if the same problem had been found earlier.

That’s why I don’t think of readiness as “the feature works.” Readiness is whether all the teams that need to touch the feature before launch have actually had a chance to validate it.

Q: What usually separates a feature that looks ready from a feature that is actually ready to ship?

For me, the difference comes down to the definition of done.

A feature can look ready because the implementation is complete and the feature team has finished everything they were responsible for. But shipping readiness usually requires a broader definition of done that includes marketing.

↓ VSQUAD’s work for Ruined King: A League of Legends Story

legal, localization, community management, live operations, and any other teams involved in bringing the feature to players.

I also think a feature should not only be shippable, it should be operable. In a live game, teams need to consider what happens after release.

Can key parameters be adjusted without a client patch? Can balancing changes be made quickly if player behavior is different from expectations?

I’ve seen features that were technically complete but required a new build for every adjustment. They were done from a development perspective, but not from an operational one.

To me, a feature is truly ready when the teams responsible for launching and supporting it are confident they can manage it successfully after it goes live.

Q: Your recent post mentioned that tools, processes, and frameworks matter, but they should not become the whole focus. Where do teams usually lose sight of the real goal?

I think teams usually lose sight of the real goal when ownership becomes disconnected from decision-making.

When a team has little autonomy and relies entirely on direction from above, people tend to focus on completing assigned tasks rather than thinking about outcomes. The conversation shifts from “Is this the best way to solve the problem?” to “Did I finish what was assigned to me?”

At that point, processes, reports and JIRA status updates can gradually become the focus instead of the actual goal.

↓ Official artwork from Riot Games

I’ve also seen this happen on long-running live projects. Over time, teams become comfortable with existing workflows and stop questioning whether those workflows are still effective. People follow the process because that’s how things have always been done, and optimization becomes nobody’s responsibility.

For me, one of the producer’s responsibilities is to keep ownership visible. Teams should understand not only what they are doing, but why they are doing it and what outcome they are trying to achieve.

Otherwise it’s easy to mistake activity for progress and end up working harder instead of working smarter.

Q: What are the most common delivery risks that teams underestimate before launch or release?

One of the most common mistakes before launch is underestimating how connected different risks are.

A delay rarely stays contained within a single team. For example, teams may plan for platform certification, but not fully account for multiple review rounds. If issues are identified during review, the resulting rework and resubmission process can extend the timeline much longer than expected.

At that point, the biggest risk is often not the certification issue itself, but missing the intended release window.

↓ Official artwork from Riot Games

I’ve seen similar situations with marketing assets. Trailers, screenshots, store pages or other promotional materials are often created using early footage. If the game’s direction, mechanics, or positioning change later in development, those assets may need to be recreated.

A change that starts in development can quickly affect publishing plans and launch timing.

There are also factors outside the team’s direct control. A release window that looked attractive months earlier may suddenly become crowded because of a major competitor launch, a DLC release, shifting publisher priorities, or even geopolitical events that affect business in specific markets.

For me, the biggest delivery risks are usually not individual issues. They’re the chain reactions that happen when one issue forces multiple teams to revisit work that was already considered finished.

Q: How does live service change the producer’s job compared to traditional development?

The biggest difference is that a live service game never reaches a true endpoint.

In a traditional project, production is largely focused on getting the game to a launch milestone. With a live service game, launch is when a different phase of work begins. Teams are constantly collecting player feedback, analyzing data, identifying problems, deciding what to do next.

Because of that, a producer spends much more time helping teams make decisions in an environment where priorities can change quickly. A feature that seemed important a month ago may become less relevant once real player behavior starts coming in.

Roadmaps need to evolve, and teams need to be comfortable adjusting course based on what they learn.

That also means a more agile way of working. The goal is not to execute a fixed plan perfectly, but to continuously improve the product while balancing player needs, business goals, and development capacity.

↓ VSQUAD’s work for Ruined King: A League of Legends Story

The challenge is maintaining that pace without burning people out. Live service creates a constant stream of requests, feedback, and opportunities. Part of the producer’s job is making sure the team stays focused on the changes that matter most instead of reacting to everything.

One thing I value about live service development is that it encourages a more data-informed mindset. Teams can learn from actual player behavior and use that information to make better decisions, rather than relying entirely on assumptions made before launch.

Q: When many teams or regions need to work together, what usually breaks first?

In my experience, what usually breaks first is shared understanding.

When teams across different regions work together, language can create subtle differences in interpretation. A requirement or decision may seem clear, but different teams can walk away with different assumptions and not realize it until execution starts.

Cultural differences also play a role. I’ve worked with teams that were more hierarchical and waited for direction, while others expected broader discussion and consensus before making decisions. Problems tend to appear when those expectations aren’t aligned.

↓ Official artwork from Riot Games

Time zones make everything harder. Something that could be resolved in a five-minute conversation can easily take a day or two when teams are distributed globally.

Most of the cross-regional issues I’ve seen weren’t caused by a lack of communication. People were communicating.

The problem was that they weren’t always operating with the same understanding of ownership, priorities, or decisions.

Q: What can game teams learn from tech product delivery, and what does not transfer well?

From my own experience, one thing game teams can learn from tech product delivery is a stronger habit of validating assumptions through data.

When I worked in tech, especially at ByteDance, experimentation was deeply embedded in the development process. A/B testing was part of everyday decision-making, and teams were constantly measuring outcomes, learning from user behavior, and adjusting direction based on real data.

That creates a very strong feedback loop and helps teams avoid relying solely on intuition.

↓ Official artwork from Riot Games

At the same time, I don’t think everything transfers directly to game development. Many tech products can be rolled out gradually through pilot markets, limited releases, or controlled experiments.

Games, especially larger titles, often involve a much bigger investment in content, creative direction, and player experience before launch. The opportunities for incremental testing can be more limited, and creative decisions cannot always be validated through metrics alone.

That’s why I see the relationship as a balance rather than a choice between creativity and data. Game teams can benefit from the delivery discipline and data-informed mindset that are common in tech, but game development still requires room for creative judgment, iteration, and ideas that may not be immediately supported by data.

Q: What does a good producer actually protect during production?

For me, a good producer protects the team’s ability to focus and do their best work.

Most disciplines already have deep expertise in their own areas. A producer’s job is not to tell people how to do their work, but to remove friction, manage dependencies, align stakeholders, and shield the team from unnecessary distractions.

I see production as a facilitation role. If the team has clarity, can make decisions effectively, and can stay focused on what matters most, then the producer is doing their job well.

Q: For smaller studios, what production habits are worth adopting early before the project becomes too complex?

For smaller studios, culture matters more than a perfect process. Workflows, checklists etc. won’t be mature early anyway, those come with iteration. What matters is an environment where people communicate openly and take ownership of solving problems.

The one concrete habit I’d push for early is a simple feedback flywheel: problems get surfaced, picked up, and resolved, and the team keeps that loop turning. It can be very lightweight, but it has to exist.

↓ VSQUAD’s work for Ruined King: A League of Legends Story

In practice that’s three things: make it cheap to raise a problem (for example, a confluence page), make sure every issue gets an owner and a close, and look back regularly (maybe bi-weekly) on what we found, fixed, and got stuck on.

The point isn’t tooling. A small studio’s real risk isn’t a rough process, it’s having no mechanism for problems to surface at all, so they stay hidden until late, when they’re most expensive to fix.

The flywheel can be simple, but it has to be there.

Q: As the industry changes, what makes a producer stay useful beyond tools, certificates, and frameworks?

As tools, frameworks, and technology are all useful, I think what keeps a producer useful is understanding people.

Every team works differently. A good producer respects the expertise of the people doing the work, understands how they collaborate then helps remove obstacles that get in the way.

In the end, it’s the people who get things done. Understanding people and helping teams work effectively together remains essential.

Explore more behind-the-scenes stories in our exclusive interview series. We have many more conversations with industry visionaries coming soon, so be sure to visit us again.