Game Business Decision Manual for Executives | Planning, Launch, Live Operations & End-of-Service

Game Business Decision Manual for Executives | Planning, Launch, Live Operations & End-of-Service

Hello, I’m Toroneko.

Game businesses require decisions at many different stages.

From the beginning of a project to its conclusion, running a game business involves a continuous series of decisions over a long period.

At the same time, game companies often experience personnel changes among development teams, producers, executives, and business leaders. For games with long development cycles, the person who made the initial decision may not be the same person making decisions later in the project.

When decision criteria are unclear, this can lead to problems such as:

In this article, I divide game business decisions into the following three decision processes:

This article can therefore be used as a game business decision-making manual.

It is not a detailed operating manual for development teams. It is a decision-making manual that helps executives and business leaders determine what needs to be decided at each stage of a game business.

 

Who This Manual Is For

This game business decision-making manual is intended for:

• Executives
• Business leaders
• Executive officers
• People responsible for overseeing a game business
• People responsible for presenting decisions to a board of directors

Some companies may have a president who makes every decision alone.

In many companies, however, executive officers and business leaders make the substantive decisions, which are then approved by the board.

For this reason, this manual is designed not only for company owners, but for both executives and business leaders.

 

What This Manual Covers and Does Not Cover

First, I will clarify what this game business decision-making manual covers and does not cover.

What It Covers

• What needs to be decided at each stage
• When a project should be stopped
• How to evaluate short-term performance together with long-term ROI
• How to maintain consistent decision criteria even when personnel change

What It Does Not Cover

• Detailed development procedures for production teams
• Detailed advertising operations
• Detailed KPI definitions
• Detailed operational procedures for shutting down a live service

 

Game Businesses Fail When Decisions Come Too Late

A game business does not become difficult simply because revenue or KPIs are weak.

The real danger begins when decisions are delayed.

For example:

In the game business, there are situations where deciding to stop is more difficult than deciding to proceed.

That is why the conditions for stopping or withdrawing should be defined in advance.

 

Evaluate Short-Term Performance Together With Long-Term ROI

Live-service game businesses require decisions every month, quarter, half-year, and fiscal year.

Teams review monthly revenue, DAU, retention, payer conversion, and other KPIs when deciding which initiatives to implement and where to invest.

Even when monthly revenue is strong, aggressive monetization that damages retention or the player experience can reduce the title’s final ROI.

In other words, a decision that protects current performance may damage long-term profitability.

Executives and business leaders should therefore evaluate short-term performance and long-term ROI together rather than treating them as separate issues.

 

Maintain Consistent Decision Criteria Even When the Organization Changes

The game industry has a high level of personnel turnover.

Development teams, producers, executives, and organizational structures can all change within a few years.

For games with long development cycles, it is therefore common for the person making decisions later in the project to be different from the person who made the original decisions.

Live titles generate continuous performance data, including revenue and retention. This makes it more difficult for decision-making to become completely disconnected from reality when personnel change.

Games still in development, however, have not yet produced results.

Decisions can therefore be influenced by the decision-maker’s understanding, values, or personal preferences.

This can sometimes have a positive effect.

What companies need is not decision-making based on individual judgment alone.

They need clearly defined organizational criteria for making decisions.

In other words, companies need to establish a formal approval process and create a structure in which decision criteria remain consistent even when personnel change.

 

Quick Reference: The Three Decision Processes

The Three Decision Processes in a game business can be summarized as follows.

Decision Process	What Must Be Decided	Stop Decision	Typical Decision Timing
Build Decisions	Approve the concept, move into full production, and confirm the conditions required to sell the game	Stop development	Concept, prototype, and around the alpha stage
Launch Decisions	Launch the game, determine whether to sell it now, and decide how and where to enter the market	Postpone or cancel the launch	Around the beta and master stages, and during launch preparation
LiveOps Decisions	Continue, improve, increase investment, scale down, or end the service	End the service	After launch, monthly, quarterly, and before or after major updates

The following sections explain each decision process in order.

Development phase names differ between companies, so the timing shown above should be treated only as a general reference.

Game companies may use terms such as:

The definitions and duration of these phases also differ between companies.

For this reason, this article focuses less on the names of individual phases and more on what needs to be decided at each major milestone.

 

The Three Decision Processes in Game Company Management

1. Build Decisions

Build Decisions are not limited to deciding whether to approve a game concept.

They also include deciding whether to move into full production, whether the game will be competitive when it launches, and whether development should be stopped before completion.

What Must Be Decided During Build Decisions

• Whether to approve the game concept
• Who the game will be sold to
• Whether the market and competitor analysis is valid
• Whether the game has a clear core gameplay experience
• Whether to move into full production
• Whether to stop development
• Whether the game will be competitive in the market at launch

 

Typical Timing for Build Decisions

• Concept stage
• Prototype stage
• Around the alpha stage
• Major milestones for deciding whether full production should continue

 

Evaluate the Market at Launch, Not Only the Market Today

When planning and developing a new game, teams tend to focus on the current market, current user needs, competing titles, and current trends.

These factors are necessary.

However, they are not sufficient for a game that will take two or three years to develop.

When a concept is approved based only on current trends, the resulting game may no longer be competitive by the time it launches two or three years later.

Under those conditions, the game will not be able to compete.

Predicting the future is difficult.

However, development teams and decision-makers still need to consider the level of quality the market is likely to require in two or three years.

Making decisions based only on what sells today creates substantial business risk.

 

Development Budgets Should Not Be Decided Only by Today’s Standards

The same principle applies to development budgets.

Judging a budget as expensive or inexpensive based only on current expectations can lead to the wrong decision.

What decision-makers actually need to determine is whether the development budget is appropriate for achieving the level of product competitiveness that will be required in two or three years.

• If development proceeds with an insufficient budget, the final product may not be competitive enough
• If the company overinvests, recovering the investment becomes more difficult

The budget should be evaluated according to whether it is appropriate for creating a product that can compete when it launches.

 

Common Build Decision Failures

Common failures during Build Decisions include:

 

 

2. Launch Decisions

Launch Decisions are not limited to advertising and promotion.

They include deciding whether the game should be sold now, where and how it should be released, and how much should be invested in advertising.

What Must Be Decided During Launch Decisions

• When to launch the game
• Whether the game should be sold now
• Which markets to enter and how to enter them
• Which strengths should be communicated
• How much to spend on advertising
• Whether to postpone the launch

Typical Timing for Launch Decisions

• Around the beta stage
• Around the master-build stage
• During launch preparation
• Before pre-registration and the full commercial launch

 

What to Review During Launch Decisions

• App store positioning and messaging
• Marketing creatives
• User acquisition cost
• Early user retention
• Initial game revenue
• Expected investment recovery
• Which regions the company should prioritize

 

Failing to Sell When the Time Is Right Is Also a Decision-Making Failure

Japanese game companies are often comparatively flexible when making Build Decisions.

However, when the time comes to invest in selling the game, companies sometimes fail to accelerate and miss the commercial opportunity.

Typical concerns include:

These concerns are not necessarily wrong.

However, becoming overly cautious when the company should be accelerating is also a management failure.

Conversely, accelerating when the game is not ready is also dangerous.

The important question is not simply whether to proceed or not proceed.

The company must decide how far it should proceed based on the current state of the title.

 

Common Launch Decision Failures

Common failures during Launch Decisions include:

• Becoming overly cautious and missing the correct launch window
• Making business decisions based only on CPI
• Launching prematurely under the assumption that problems can be fixed after release
• Failing to accelerate investment when the title should be sold, and missing the commercial opportunity

 

3. LiveOps Decisions

LiveOps Decisions include determining what to improve, whether to increase investment, whether to scale down the business, and whether to end the service.

What Must Be Decided During LiveOps Decisions

• Whether to continue the service
• Which areas should be improved
• Whether to prioritize new, retained, or reactivated users
• Whether to increase investment
• Whether to scale down the business
• Whether to end the service

 

Typical Timing for LiveOps Decisions

LiveOps Decisions are required at the following times:

• During the initial post-launch period
• Monthly and quarterly
• Before and after major updates
• At major milestones for continuing, scaling down, or ending the service

 

Changes to the Core Experience Should Not Be Decided by the Development Team Alone

Live games may receive updates such as:

These decisions carry a different level of business significance from implementing an event, updating a gacha banner, or adding a new character.

This is because they affect the game’s core experience itself.

When evaluated only by the revenue generated immediately after implementation, these changes may appear successful.

However, the change may affect retention and the lifespan of the game one or two years later, ultimately changing the title’s final ROI.

That is why it is dangerous to leave these decisions entirely to the production team.

Updates that affect the core experience should involve executives and business leaders.

Short-Term Revenue Alone Cannot Determine Whether an Update Was Successful

Game businesses naturally tend to focus on short-term results, such as revenue for the current month or quarter.

However, evaluating an update based only on short-term revenue can lead to the wrong decision.

Short-term revenue may have been generated through measures that place excessive pressure on players.

As a result, the long-term value of the game may be damaged.

A title with declining revenue does not necessarily need to be shut down immediately.

However, it is dangerous to continue operating the game by inertia without reviewing how much should continue to be spent on development, live operations, and promotion.

For a live-service game, the following factors must be evaluated together:

 

This is because the value of a live-service business, such as a mobile game, depends on whether it can contribute profit over a long period.

Its final evaluation is made after five or ten years of operation.

Even if the first year is successful, the title must be evaluated negatively if it has produced a cumulative loss by the fifth year.

 

KPIs to Review During LiveOps Decisions

KPIs that should be reviewed during LiveOps Decisions include:

• DAU and MAU
• Day 7 and Day 30 retention
• Payer conversion
• ARPU and ARPPU
• Revenue trends
• Investment recovery progress
• Return on additional investment
• Scale-down and shutdown thresholds

 

Common LiveOps Decision Failures

Common failures during LiveOps Decisions include:

• Deciding to continue based only on revenue
• Postponing action despite losses because the team believes the next update will change the situation
• Evaluating the title based only on short-term revenue
• Delaying the shutdown decision and allowing liabilities to increase
• Evaluating changes to the core game experience based only on revenue immediately after implementation

 

Situations Where Decisions Easily Become Dependent on Individuals

The Three Decision Processes need to be managed as organizational processes.

Games that are still in development are particularly vulnerable to individual decision-making.

Because there is no performance data yet, the project’s direction can easily be influenced by a decision-maker’s experience, preferences, or sense of what development should cost.

However, decisions should not be made solely according to individuals.

Doing so creates the following disadvantages:

Situation	Why Decisions Become Individual-Dependent	Required Countermeasure
A title is still in development	There is no performance data, so decisions are easily influenced by the decision-maker’s preferences	Document the decision criteria
Immediately after a personnel change	Important assumptions and background information may not be shared	Standardize the items that must be reviewed during approval
During cost reductions	Short-term financial performance may be prioritized over understanding the game	Review long-term ROI at the same time
When changing the core experience	The change may be evaluated only by immediate revenue	Evaluate the impact one year and beyond

When decision-making becomes dependent on individuals, decisions tend to be based only on intuition, personal preferences, or previous successes.

When personnel change, the decision criteria also change.

As a result, the game company may fail to make appropriate decisions, and the business may not perform as expected.

Minimum Information Executives Need for Decision-Making

The following information is the minimum that executives should have available when making decisions.

Using these factors as the basis for the Three Decision Processes can reduce inconsistency.

Information Required for Build Decisions

• Market
• Target audience
• Competitors
• Core gameplay experience
• Expected competitiveness at launch
• Budget
• Expected investment recovery

 

Information Required for Launch Decisions

• ASO strategy
• Game positioning and messaging
• Marketing creatives
• User acquisition cost
• Early-user retention
• Initial post-launch revenue
• Investment recovery hypothesis
• Priority regions

 

Information Required for LiveOps Decisions

• User retention
• Revenue trends
• Monetization performance
• Investment recovery progress
• Return on additional investment
• Scale-down and shutdown thresholds
• Long-term impact of changes to the core experience

 

Common Situations That Delay Decisions

Situations that commonly delay game business decisions include:

 

Conclusion

Game business decisions continue from game planning through launch, live operations, and eventually the end of the service.

Running a game business is therefore a continuous series of decisions.

These many decisions become easier to understand when divided into the following three processes:

Decision-making does not occur at only one specific point.

It is required during development, before launch, and throughout live operations.

It also includes the decision to stop a project.

Short-term performance alone is not sufficient for making these decisions.

Unless the company also evaluates long-term ROI, it cannot make the right business decision.

The game industry also has a high level of personnel turnover, with team members and decision-makers changing over a period of several years.

Defining those criteria clearly and incorporating them into the approval process is essential for preventing a game business from becoming dependent on specific individuals.

Toroneko also provides consulting support to help game companies define and organize these decision criteria.

Please contact me if your company is having difficulty making a game business decision.