What causes a project to fail?

Success often looks the same, but failure takes many forms.

For a game to succeed, it must meet a series of essential criteria—plus a bit of luck—but stumbling into just one pitfall can spell its doom. We’ve witnessed the demise of many games that looked promising on the surface, and we’ve sighed with regret over projects that had real potential but accidentally fell into the abyss.

A producer once described to me how developing a project is like walking on thin ice; game development on a certain scale is a complex undertaking, and there are always unexpected pitfalls ahead.

Although most people find it difficult to truly learn from others’ experiences—and can only gain real insight by making their own mistakes—observing the failures others have encountered can still serve as a cautionary tale to some extent.

In this episode of the Youcha Roundtable, we sat down with industry professionals to discuss: “What causes a project to fail?”

▍Caohejing Wanderers: King of the West

Looking back on the projects I’ve worked on that failed, there’s really only one reason: we were working in isolation.

From the boss to the producers and all the way down to middle management, everyone is brimming with a strange sense of arrogance. They reject all outside expertise, dismiss any suggestions or feedback, and insist on doing things their own way. Validation is unnecessary, feedback is unimportant—they believe that once development is complete, everything will fall into place.

During the project’s development, we did organize some small-scale player testing sessions and interviews, but the player feedback surveys were merely a formality. As for the interviews, the producer would personally snap back at each player one by one, only to then turn around and dive back into the development process, seemingly oblivious to the realities of the player market.

Working in isolation like this can’t go on forever. As the player test pool grows larger and the data becomes so terrible that it’s impossible to ignore, arrogance gives way to panic. In a desperate attempt to save the project, the team frantically changes direction, only to ultimately fail because the problems have become too deep-rooted and the data is simply too terrible.

▍Miguel, who left the gaming industry yesterday

Actually, when it comes to solo projects, the process of failing is pretty common. It’s like slowly drowning—each problem seems manageable if you just hold your breath and tough it out, but eventually, they all come crashing down on you at once.

I believe the root cause is that our creative vision was out of touch with reality. After several rounds of testing, the player feedback was consistently poor. At the time, I was too stubborn; I kept thinking that players simply lacked the patience to appreciate it, and I couldn’t bring myself to scrap the project and start over.

And then there’s that vicious cycle: taking on freelance work to make ends meet → projects stall → money runs out, so you take on even more freelance work. Sometimes, we get so caught up in freelance work that we don’t even touch our own projects. In a way, maybe we’re just pretending not to see it.

One day, I was tweaking the effects until 3 a.m. when it suddenly dawned on me that we weren’t making any progress—we were just patching things up. At that point, admitting that the project was dead actually felt easier than trying to keep it going.

▍Retired 3A Veteran XX

The vast majority of games die the very next day after being greenlit, but it takes a year, a year and a half, or even longer before they’re finally shelved.

▍Tape for a Steady Win

It is undeniable that the vast majority of buy-to-play games have a short lifecycle; their ROI can typically be predicted within a month or less of launch. This means that buy-to-play games generally require significantly less ongoing operational investment than GaaS titles. Consequently, when a buy-to-play game project “dies,” it usually refers to one that fails to get off the ground during the development phase.

From the perspective of a publisher or investor, this means ceasing investment in the project and cutting off funding to the development team. So what factors could lead to a complete loss of confidence and ultimately result in the project’s demise?

My experience is limited to indie game projects. Deciding whether to partner with a team or invest in a project involves a multifaceted risk assessment: a playable demo with potential, a clear market positioning and unique selling points, a roadmap and vision for future development, and a team that “seems” reliable.

Assessing a game project’s future potential is a prerequisite for collaboration. Beyond that, I believe the most difficult factor to predict is the stability of the team. Independent game development is typically carried out by individuals or small studios, and core members rarely have experience with successful projects or mature, proven technical skills. During the initial engagement phase, we can only gain limited insight into their communication and collaboration skills, the clarity of their project plans, and whether they possess “disciplined enthusiasm”—and this is far from sufficient.

From a human resources perspective: the loss of key talent and team expansion; balancing headcount with project ambitions; and development efficiency issues caused by technical or staffing shortages.

From a project management perspective: The constant addition of new ideas and features has expanded the scope of the project, making it impossible to complete and even causing it to deviate from its original core gameplay; technical debt has accumulated due to the team’s lack of expertise, and frequent bugs have led to an exponential decline in development efficiency.

They say a "boring" but complete game is worse than an "interesting" half-finished one, because at least the former can be sold.

But even after navigating the challenges of refining the game’s concept and dealing with extended development cycles, once the project finally launches, we still face one final hurdle: shifts in market trends. “For example, while roguelike action games might be all the rage now, by then their popularity could be completely overshadowed by AAA action titles.”Consequently, when a project faces a crisis, investors often rely on project health assessments to decide whether to continue the partnership or cut their losses—essentially determining the survival of a buyout-based game project.

Due to various factors such as those mentioned above, independent game studios today must complete at least 70% of a game’s development before they can even begin to consider partnership opportunities for distribution. Furthermore, the core gameplay concept must be sufficiently distinctive. Consequently, the maximum level of completion a game can reach is inevitably limited, creating a vicious cycle within the domestic indie game development landscape.

But I remain optimistic. Time can solve any problem, and I believe there will always be more talented individuals or serendipitous collaborations between developers and publishers that will gradually help build China’s 3i game market.

▍An industry professional lll

Before we discuss why a product fails, we need to first ask: why is a product created in the first place?

The lifecycle of every product is actually determined the moment it is launched, and the foundation of that lifecycle is the product’s quality.

Factors such as marketing, public sentiment, incidents, and optimization that arise during the R&D and operations process are, in fact, merely reflections of the product itself. Essentially, 90% of the reasons for a product’s decline are inextricably linked to its inherent quality.

I believe the root cause lies in the initial rationale behind each project’s launch within a company—whether it’s a successful project or a failed one.

I’ve seen too many projects that start out based solely on the lead designer’s and producer’s “preferences” and “ideals,” only to realize halfway through that their product is too niche or lacks broad appeal (or isn’t commercially viable), and then begin making adjustments to cater to users, ultimately ending up as a “mishmash.”

Too many teams end up creating a flawed product for the reasons mentioned above—a product that is out of step with the times, incompatible with the company’s technology, and fails to meet user needs. While a very small number of these products manage to succeed thanks to their exceptional quality and capabilities, the vast majority are, in fact, failures.

So, what causes a project to fail? I believe the most crucial factor is its underlying purpose. That purpose determines the project’s lifespan and shape. To borrow a cliché from TV dramas, some products are, quite simply, “children that should never have been born.”

▍Milestone of the Dead -D

A project will die from endless overtime sprints (I’m certain of it)—from a poor, overworked game designer currently working overtime.

Of course, I’m just joking. Whether or not people work overtime, how harsh the project environment is, or even whether profitability meets expectations… none of these factors really count as decisive factors in determining whether a project will fail.

There is only one direct reason that can truly kill a project: the boss or investor simply doesn’t want to continue. The project next door has been live for a year, with players steadily leaving, operating at a loss almost the entire time, and development staff leaving in wave after wave. Yet the project has managed to hang on—simply because the boss believes this genre must have a decent product. Of course, more often than not, the boss’s decision brings the bad news that the project is being shut down.

Unless a live project shows clear signs of impending failure (such as revenue failing to cover server costs), whether a project under development will ever launch—or how long it will survive—is often something that R&D team members simply cannot predict. One day everything might seem sunny and bright, with everyone enjoying full benefits and laughing and joking during team-building activities, only for the project to suddenly be canceled over the weekend.

It’s also possible that the team is in a state of panic, with deadlines never being met. Everyone feels that the quality is subpar and needs to be addressed, but the project is constantly facing new challenges and incurring new costs. The launch seems to be a long way off, yet the development team has remained steadfast for years.

A friend in the industry once told me that working overtime isn’t about meeting output targets, but about alleviating the boss’s anxiety. Sometimes, as you work those long hours, you can’t help but feel lost: during those endless development cycles, are we constantly “sprinting” to ensure the project is polished and launched, or simply to keep the boss calm and prevent the project from dying before it even sees the light of day?

▍A Guide to Project Failure for Former Top-Tier Game Producers

From Meetings to Budgets: The Pitfalls That Kill Game Projects:

Empty talk in conference rooms, bloated budgets, and teams that have lost their way are quietly killing game projects one by one. “We’ve always focused on analyzing the lessons from our successes, but rarely reflect on our failures—it’s like rubbing salt into the wound,” wrote one industry insider while summarizing the lessons learned from a failed project.Behind the glitzy success stories of the gaming industry lie countless projects that have failed in obscurity. These failures are not accidental; they result from a systemic collapse—from meetings and budgets to courage and the ability to stay focused on priorities.

Meetings are supposed to be platforms for solving problems, yet they often become the scene of a project’s demise. Effective meetings require three key steps: setting clear objectives, identifying feasible methods, and determining specific implementation paths. Many project leaders overlook this fundamental principle, indulging instead in the self-satisfaction of “speaking for the sake of speaking.”Lead designers speak just for the sake of speaking, while team leaders steer discussions toward abstract questions—such as whether a game needs a storyline—or even resort to a show of hands to resolve technical issues. Meetings lacking clear agendas and decision-making mechanisms directly lead to a lack of direction and inefficiency within the team. When team members interpret meeting conclusions differently and work toward conflicting goals, the project has already begun its descent into failure. Ambiguous objectives trap team members in a quagmire of redundant work and misalignment, wasting precious development resources.

Counterintuitively, an overly large budget can sometimes hasten a project’s demise. A small team with a budget of $1 million to $3 million typically has clear objectives, a balanced workload, and high execution efficiency. However, when the budget swells to $20 million and the team expands, an imbalance in resource allocation often emerges, resulting in some team members being swamped while others are idle. This imbalance not only leads to decreased efficiency but also triggers internal conflicts.When resources are misallocated, critical tasks may be delayed due to insufficient resources, while non-critical tasks may consume excessive resources. Amid the chaos, communication costs within the team skyrocket, and internal buck-passing replaces collaborative problem-solving.

When a project’s test data is poor or its commercial performance falls short of expectations, teams are most prone to falling into one of two extremes: either giving up prematurely or stubbornly pushing forward no matter what.Many teams lack the courage to delve into the core issues, preferring to make superficial fixes rather than confronting the project’s fundamental flaws. Successful adjustments require the team to have the “courage to undergo a complete transformation” and the “patience and meticulousness to deconstruct and rebuild.” When a game fails to meet expectations, the team must dive deep into its inner workings to untangle all frameworks, features, interconnections, numerical values, and interactive relationships.

A common mistake during the revision process is trying to address every issue at once—adding features, filling in content gaps, and optimizing the game all at the same time. This attempt to cover every angle often backfires. Revisions should have clear priorities. The primary goal is to optimize the core gameplay experience and positive feedback loops to keep players engaged. Only then should you develop new features and expand gameplay based on that experience. Monetization strategies should be built on a solid foundation of player retention.

In addition to the core issues mentioned above, game projects often fail in a variety of ways. For instance, technical flaws can be a “silent killer” for game operations, and technical stability is crucial for games that rely on real-time interaction. Blindly following trends and a lack of innovation are equally fatal. Confusion over responsibilities, inefficient workflows, and a lack of team buy-in are also common causes of project failure. When team members “don’t even want to play the kind of game they’re making,” the project has lost its soul.

A game is by no means a mechanical amalgamation of design, programming, and art; rather, it is an organic entity that requires human input to come to life. Many managers believe that opportunities can be identified simply by making snap decisions, reading articles by industry leaders, or listening to industry insiders’ boasts—and that game development can then be completed by simply “following the blueprint.” This misconception is akin to “thinking you’re a master chef capable of preparing a gourmet meal just by following a recipe.”How does one gauge the “pinch,” “just the right amount,” or “as needed” in game development? How does one master the timing? These all require experience and intuition.

Finally, I’m not sure if I should say this, but in my view, most corporate decision-makers suffer from severe cognitive dissonance with the “battlefield” where real value is created—that is, the game itself—due to information overload.

Decision-makers are exposed daily to a massive volume of industry trends, market data, peer perspectives, and social media analyses. While this information is valuable in itself, the danger lies in the fact that it can easily construct an abstract, “idealized” virtual market, leading decision-makers to become engrossed in “strategic simulations” at this abstract level.They discuss “2D game genres,” “party game trends,” and “user acquisition models,” yet overlook the fact that all these macro concepts must ultimately be embodied and realized through a concrete, engaging game product. When decisions are based primarily on external analysis reports and scattered briefings rather than a deep, hands-on experience with their own product, such decision-making is akin to building a house on sand.

“Walking through the entire process” is precisely the most effective way to burst this cognitive bubble. A leader who has never, as an ordinary player, completed the full journey—from download and onboarding to the core gameplay loop and monetization points—simply cannot understand at which stage players become frustrated by lengthy loading times, at which mission point they get stuck due to poor design, or at which monetization point they decide to quit because they don’t perceive enough value.The modification instructions they issue are often based on abstract concepts like “I think,” “the data shows,” or “others have succeeded,” rather than the genuine experience of “I felt frustrated when I played through that part myself.” This creates a massive cognitive gap between the execution team—who deeply understand the product’s details—and the decision-makers—who operate within a macro-level perspective. Consequently, the modification instructions inevitably fall short of the mark or even miss the point entirely.

So is there a solution? Yes, there is. It involves forcibly pulling decision-makers’ attention away from fantasies of “unfathomable wealth” and the overwhelming sea of information, and bringing it back to the game’s most fundamental “first principle”—is it fun? This requires decision-makers to become the most demanding and loyal players of their own product. They must not only play the game themselves but also bring their team along, organizing “Bug Bash” sessions to anonymously collect the most genuine and harsh feedback that frontline employees—especially customer service and community managers—have heard directly from users. The foundation of decision-making should shift from “Industry reports say…” to “Last night, when I reached Level 3, I noticed…”

Ultimately, most of the responsibility does indeed lie with the producers themselves, because these are all issues I’ve actually encountered and experienced firsthand. Very few of the domestic producers I’ve seen actually play their own games; most of them just go through the motions, playing a bit and casually giving their input once the game reaches the release phase.