Management of flexibility in continuous product development

ADVANCE PUBLICATION Annals of Business Administrative Science http://doi.org/10.7880/abas.0180921a Received: September 21, 2018; accepted: October 8, 2018 Published in advance on J-STAGE: October 11, 2018

Management of Flexibility in Continuous Product Development: The Case of the Online Game Industry Wei HUANGa)

Abstract: In existing research on new product development, it has been believed that the product development by companies needs to reflect the changes in customer needs. Particularly, for products in which continual development is a characteristic, customer needs must be addressed at multiple points in time. However, by comparing the cases of two companies from the online game industry, we found that long-term performance of a company which responded flexibly suffered a drop, with the ratio of new users dropping and the user attrition rate increasing. Therefore, we believed that too much attention was paid to the requests of lead users. Keywords: new product development, flexibility, online game industry, continuous development process

a)

Graduate School of Economics, University of Tokyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo, Japan, [email protected] A version of this paper was presented at the ABAS Conference 2018 Summer (Huang, 2018). © 2018 Wei Huang. This is an Open Access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted reuse, distribution, and reproduction in any medium, provided the original work is properly cited.

1

Wei

Introduction New Product Development (NPD) is an important activity for ensuring the success of a company. Numerous studies on NPD have focused on the issue of how to effectively manage development projects and have validated the relationship between organization structure and development processes on product performance in such aspects as lead time, cost, and quality (Clark & Fujimoto, 1991; Cusumano & Nobeoka, 1992; Iansiti, 1997). Since the 1990s in particular, research on NPD adopted diverse perspectives, with an acknowledgment of the common issue of “identifying effective NPD patterns” (Kuwashima, 2012). Companies must adapt their products to changes in the external environment in order for them to create sustainable competitive advantage. Constructs such as competence, organizational routine, and capabilities have been developed to explore these types of adaptations (Fukuzawa, 2015). From the perspective of product development, Thomke and Reinertsen (1998) noted that redesigning and adapting products for shorter lead time and lower cost is an important issue. For the software industry in particular, NPD is becoming a continuous activity (Buganza & Verganti, 2006). Even after a product has been released in the market, it is possible to correct bugs and add new features over the Internet. In such continuous product development, companies must adapt products to information from the outside (e.g., from users) as needed, not only at the planning stages but also throughout the long-term development process. In that case, the question is, “how flexible companies must be in response to information that is continually flowing in from the outside, particularly from users?” This paper examines the online game industry, which is characteristic for (a) the speed of environmental change it experiences and (b) the continuous nature 2

Management of flexibility in continuous product development

of its development activities. (a) With regard to the speed of environmental changes, changes in the needs of users in the overall game industry, including online games, are extraordinarily uncertain and severe. Additionally, mobile games stand out due to the widespread use of smartphones, and technologies related to integrated development environments are frequently updated in conjunction with improvements to hardware specs. (b) With regard to the continuous nature of development activities, unlike console games, online games have very long time spans in which a single title can be used, which requires game content to be constantly

updated

to

ensure

that

users

do

not

get

bored. Development takes place with equal care given to both product development and product operation, with successive continuous small and large updates that lead to a game evolving to the extent that it could actually be said to entirely become a different game. In this paper, a comparison of two online game industry companies sharing these types of characteristics showed a decrease in long-term performance

for

projects

that

flexibly

respond

to

customer

needs. This was caused by product development that took place out of a sensitive reaction to the trends of lead users, which are easily observable.

Case Study Projects

of

comparable

size

in

two

Japanese

online

game-development companies―Company A and Company B―were chosen as case studies. These two projects developed games in the same genre, allowing for a comparison of product performance using the following metrics.

3

Wei

(A) Development-related items (a) Use of agile development methodologies: subjective judgments of interview subjects (b) Development productivity: development man-hours to add new features (c) Closeness of collaboration with operation organizations: communication frequency (d) Update quality: state of bugs (number of bugs occurring with updates) (e) Development cycle (iterations): the period from planning to combined testing (B) Products-related items (a) Integration with product concepts: number of consistency checks between new and existing content when updating (b) ARPU: average revenue per user (c) New user ratio: percentage of new users in the user group between February and March 2018 (d) User attrition rate: rate of attrition by existing users in user group between February and March 2018 (e) Product review points during period: number of points evaluated by users on Android and iOS platforms The survey focused on interviews with development project managers in the two companies and on-site survey material, supplemented by newspaper articles, white papers, and reports, all of which were then analyzed.

Agile software development in the game industry With

increased

development

costs

for

games

and

longer

development cycles in recent years, many game-development companies have focused on the agile development methodology that has come into greater use in industrial software development. This 4


methodology uses short development cycles and proactively brings users into the development process so that all development activities can be faster and more predictable. This methodology has the following three characteristics: (i) it is iterative, completing work through several development cycles; (ii) it proceeds progressively, with product releases made not just once, but several times from simple implementation to final product; and (iii) it is self-organizing, with teams autonomously deciding the best methods to efficiently move their work forward (Boehm & Turner, 2005). Agile development is highly conducive to online game development with small development organizations and is used in numerous game development projects. Agile development has no rigid rules and manuals. Many game-development organizations have opted to use the agile development methodology in conjunction with project circumstances.

Development organizations and products The products studied herein are puzzle game apps on Android and iOS for both domestic and overseas markets. Revenue models for the games rely on the sale of items in the games. Project X is a development project of Company A and was kicked off 2.5 years ago, with actual game service beginning 1.5 years ago. Three years have passed since Company B started their Project Y, with service starting 1.5 years ago. In terms of product performance, the products of both Company A and Company B are highly ranked in their genre for Android and iOS platforms and have about the same level of user rating. The content of both Project X and Project Y can be divided into two types: PvE and PvP. PvE is short for “player versus environment” and involves users clearing tasks given to them by the game environment and fighting against set opponents. On the other hand, in PvP, or “player versus player,” users fight among themselves for ranking 5

Wei

points under rules provided by the game environment. Particularly, PvP has a high social status; therefore, creating and maintaining a healthy game environment is extremely important for it and new user acquisition is an important metric. The development organizations of Company A and Company B are generally made up of 30–40 person teams for each project. Five to six specialists are assigned to teams for each development process: game planning, character design, graphics, UI design, programming, and so forth. These teams do their work under a project leader who manages development work. Project leaders manage overall projects, including budget, development schedule, resource deployment, and game-product quality. Departments involved in a development project are concentrated on a single building floor. In addition, each project has an operations team that holds responsibility for the project. For operating several titles, the team is thus located on a separate floor. The team analyzes users’ play data with the development team after a formal service release and continuously works on graphical refinements and the development of additional content such as maps and other items, promoting further evolution of the product. The primary work of an operation team includes the visualization and analysis of user data for a post-product release, in addition to its maintenance. On the basis of the results of analyses, the team creates validation models for subsequent updates. As an operation team gives periodic feedback to the development team on user trends, they propose ideas such as balancing additional items in the next update. Development teams and operation teams hold meetings twice weekly.

The case of Project X Company A develops games for home game-consoles and personal computers. With the rapid growth of the mobile game market in recent years, they have expanded into mobile game development as a 6


new business. Project X began as an agile development project and settled into a routine of two all-hands meetings on workdays, with vigorous information sharing within teams. All members generally participate in morning meetings, with reports on tasks at the current stage and expected work for that day. The morning meeting is attended by the managers of each department and has a strict 15-minute

time

limit,

covering

only

major

issues

such

as

confirmation of progress in development and adjustments to work, with no detailed discussion. However, after product release tasks for modifying features and adding new content grew more than expected as play information ballooned due to the enormous growth in user data. Development teams attempted to keep up, yet entire teams faced exhaustion after a month, and the overall project productivity plummeted. The leader of Project X made a rule that the project would not respond to all the needs of users, but would instead focus development resources on the company plan based on an analysis of play data. As a result, development burdens were greatly eased. In Project X, the integration of product concepts has been emphasized, and the team has used a development style, where development involves all teams from planning through review stages. The core game system is developed and updated, primarily through proposals from the game-planning team.

The case of Project Y Company B, on the other hand, is a company specializing in mobile game development and operations. The company’s Project Y has aggressively used development methodologies such as iterative development and agile development from the initial planning stage, focusing on improving flexibility. In addition to information-sharing meetings, efforts are made to assign scrum masters (to support autonomous

collaboration

by

development 7

teams)

and

the

Wei

installation of project libraries among teams. Company B built a more open game system than that built by Company A, which enables them to rapidly add new features and content. The time to respond to changes in features or requirements is about 1–2 weeks, about half the time needed by Company A. Project Y heavily emphasizes rapid response to customer needs and aggressively inserts the results of operation team analyses into subsequent updates. It takes around two weeks from when user issues and advices are taken up for implementation into the game, which users feel is a fast response time. Company B develops and updates its game system with proposals from the management team based primarily on the analysis of play data. However, paring down features and improvements to be added through the play data analysis requires the use of many development resources from corporate planning. This is because there is extremely high uncertainty around the relationships between the trends of the massive amount of users and product features, and the accuracy of analyses is still low. In actuality, when analyzing play data, development resources focus on easily observable data. On the other hand, the company is supposed to be creating a healthy game environment, and not enough development resources have been assigned to analysis of user groups that are difficult to observe. Moreover, since response speed is important, discussions and testing of the integration of product concepts when updating are kept to a bare minimum. In Project Y, consistency between added content with existing content is validated only in an overall meeting of development teams as long as there are no bugs.

Comparing Project X and Project Y With respect to the performance of online games that are under continuous development, a well-balanced user composition and a healthy game system are important long-term metrics, in addition to 8


Table 1. Comparison of Project X and Project Y

revenue and user ratings (Table 1). Because user ratings are mostly similar, there is likely no difference in product performance. At the same time, Project X and Project Y greatly differ with regard to long-term performance. New user acquisition is an important metric when considering long-term revenue. Even 1.5 years of service, Project X is acquiring a certain number of new users each month. By switching to a development philosophy that favors consistency of product concepts, it uses information from users selectively, which results in no bias toward the trends of lead users and the ability to maintain a well-balanced game ecosystem. On the other hand, Project Y has higher average revenue per user than Project X, though its ratio of new users has dropped and user attrition has risen, leading to lower long-term performance. Project Y focuses on user needs and rapid responses. However, because lead users are the easiest to observe in play data, it is easy for game design toward the trends of lead users. Perhaps, this is what is creating large divergence between new user needs and the game. Further, in the genre of Project X and Project Y, the PvP content in 9

Wei

which users fight among themselves is an extremely important part of the game. As the rate of new users joining the game drops, the game tends to morph into a competition among paid users such as lead users or heavy users. Game updates bring new content, making users unable to obtain powerful items unless they pay for them, and as lead or heavy users become tired of paying, they may leave the game.

Discussion This paper compares the development projects of two companies in the online game industry. Project X and Project Y are in the same game genre but use different development styles. Much of the existing research argues from the assumption that the flexible adaptation of a product to external environmental changes is tied to higher product performance (MacCormack，Verganti, & Iansiti, 2001; Buganza & Verganti，2006; Buganza, Dell’Era, & Verganti, 2009). In this comparison of two companies in the online game industry, however, the project that showed greater flexibility in adapting to user needs had lower long-term performance. This is because that project develops the product by frequently reacting to lead user trends, which are easily observable. Rapid responses to the needs of specific user groups may actually lead to a drop in long-term performance.

Acknowledgments This work was supported by JSPS Grant-in-Aid for Publication of Scientific Research Results, Grant Number JP16HP2004.

10


References Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30–39. Buganza, T., & Verganti, R. (2006). Life-cycle flexibility: How to measure and

improve

the

innovative

capability

in

turbulent

environments. Journal of Product Innovation Management, 23(5), 393– 407. Buganza, T., Dell’Era, C., & Verganti, R. (2009). Exploring the relationships between product development and environmental turbulence: The case of mobile TLC services. Journal of Product Innovation Management, 26(3), 308–321. Clark, K. B., & Fujimoto, T. (1991). Product development performance: Strategy,

organization,

and

management

in

the

world

auto

industry. Boston, MA: Harvard Business School Press. Cusumano, M. A., & Nobeoka, K. (1992). Strategy, structure and performance in product development: Observations from the auto industry. Research Policy, 21(3), 265–293. Fukuzawa, M. (2015). Dynamic capability as fashion. Annals of Business Administrative Science, 14, 83–96. doi: 10.7880/abas.14.83 Huang, W. (2018, September). The management of flexibility in product development. Paper presented at ABAS Conference 2018 Summer, University of Tokyo, Japan. Iansiti, M. (1997). Technology integration: Making critical choices in a dynamic world. Boston, MA: Harvard Business School Press. Kuwashima, K. (2012). Product development research cycle. Annals of Business Administrative Science, 11, 11–23. doi: 10.7880/abas.11.11 MacCormack, A., Verganti, R., & Iansiti, M. (2001). Developing products on

“Internet

time”:

The

anatomy

of

a

flexible

development

process. Management Science, 47(1), 133–150. Thomke, S., & Reinertsen, D. (1998). Agile product development: Managing

development

flexibility

in

environments. California Management Review, 41(1), 8–30.

11

uncertain