Developing New Products in Emerging Markets

For more than a decade, multinational enterprises from developed countries have been moving a substantial part of their research and development (R&D) activity to emerging markets such as India and China. While the location of R&D centers in other developed countries has been driven by lucrative markets or specific expertise available in the local ecosystems of those countries, the location of R&D in developing countries has been driven largely by the availability of skilled manpower at low cost. At first, these R&D centers in emerging markets operated largely as extended arms of R&D in the home country, executing well-defined projects under close supervision from headquarters.

However, the dynamics of multinationals’ R&D are rapidly changing. Emerging markets are new growth drivers of the global economy, and their unique bundle of opportunities and challenges can be a wellspring of innovation1 for a multinational company. Simultaneously, many R&D centers in emerging markets have evolved to accumulate advanced technical capabilities, leading their employees to clamor for higher-value-added work and to seek responsibility for a complete product or technology. This clamor gets louder when the R&D subsidiary is located in a country with a large local market, such as India or China.

Given these trends, R&D subsidiaries in emerging markets are uniquely positioned to play an important role in multinational companies’ innovation strategies. However, this thinking is often at odds with the dominant innovation mindset, structures, and processes within multinational companies based in developed countries. Also, the fact that the product-leadership capabilities of R&D centers in emerging markets are often not well established within the multinational enterprise creates a higher hurdle. Against this backdrop, we explore several questions: When is the subsidiary ready to take on such responsibilities? What kinds of products or technology should the subsidiary work on? How should this be developed? While many companies have struggled with these issues, a successful innovation from Cisco Systems Inc.’s R&D unit in India — a family of mobile backhaul routers, named ASR 901 aggregation services routers2 — offers insights into these questions. (See “About the Research.”)

The ASR 901 family of routers acts as the entry point for consumer voice and data into the mobile telecommunication network and sits in what is referred to as the “last mile” of the network. (See “How a Telecom Network Is Structured.”) ASR 901 was conceptualized and developed by Cisco’s R&D center in India to serve the unique needs of emerging-market customers. However, the product also found traction in developed markets, making it a global product. The decisions taken with respect to the choice of ASR 901 as the product to be developed in India, its technological features, and its resourcing strategy provide valuable lessons for multinational managers both at headquarters and at subsidiaries on how to turn the company’s emerging-market presence into a source of innovation.

Decision #1: Key Enablers of Emerging-Market Innovation

Managers in emerging-country R&D outfits need to consider three key factors before they embark on innovation for local and similar markets. These enablers are the R&D capability of the unit, the size and uniqueness of the market opportunity, and the presence of executive champions, both at headquarters and at the subsidiary.

R&D Capability

First and foremost, the R&D unit needs to have well-developed R&D capabilities. This means the unit should have the breadth and depth of technical knowledge required to undertake complete product development. Without this capability, the unit will remain reliant on headquarters and other units within the company, which might unnecessarily prolong the process or end the project prematurely.

Leading up to ASR 901, Cisco India had built these capabilities to a large extent. In 1996, Cisco set up an R&D center in Bangalore, India. The center started with a handful of engineers working as an offshore, extended team of Cisco headquarters, executing specific tasks for one or two business units. The primary driver for setting up the center was the availability of a large pool of English-speaking engineering talent and low operating costs.

In the years following its establishment, the India center consistently met delivery and quality targets, attracting more investment from headquarters and increasing the scale of its R&D. At the same time, the center enhanced the depth and breadth of its technical capability, and by 2009, the center had filed more than 170 patents. The India center was given development ownership for certain product components, although product innovation continued to be driven by headquarters and oriented to the needs of the developed markets.

As the India R&D center matured, the R&D managers and staff aspired to innovate rather than simply execute; a culture of innovation and entrepreneurship emerged. More importantly, the center had accumulated most of the capabilities required to deliver on that aspiration.

Market Opportunity

As Cisco India’s R&D matured, the Indian economy saw a major transformation in the telecom sector. As a result of deregulation in the 1990s, a number of telecom service providers (both domestic and foreign) entered the Indian market. The free-market forces triggered above-average growth, and the telecom subscriber base grew more than 20-fold in a decade, from under 28.5 million subscribers in 2000 to over 621 million in 2010.3 To keep pace with this growth, telecom service provider investments in network infrastructure also grew sharply in India, going from $60.8 billion in 2007 to $89.6 billion in 2010, at a time when capital investments stayed fairly flat in developed markets.4 The market opportunity in India and other emerging markets was clearly big, and it was reflected in Cisco’s strategy. In 2006, Cisco’s then-CEO, John Chambers, announced that Bangalore would be developed as Cisco’s Globalization Center East. The goal was to grow the Bangalore site to reach an equal technical footing with the company’s headquarters in San Jose, California, to support Cisco’s globalization strategy. To execute this ambitious goal, Cisco senior vice president of customer advocacy Wim Elfrink was appointed the company’s chief globalization officer and relocated to Bangalore in 2007. As a result, the footprint of the India center, which had been predominantly an R&D organization, expanded. Cisco services — both technical and advanced — gained a strong presence in India. Sales, marketing, and supply chain management also grew.

Growth on multiple functional dimensions created a better dialogue between R&D in India and customer-facing teams. The R&D center started receiving feedback on the lack of appropriate products for the local market. It became increasingly evident that Indian and other emerging-market customers had unique requirements with respect to price, network scalability, subscriber monetization, and simultaneous support for legacy (2G) and 3G/4G network deployments. This created an impetus to innovate.

In sum, a large market opportunity combined with unique customer requirements is a key enabler of innovation for emerging markets. While most emerging markets do present a sizable market opportunity, it is the uniqueness of customer requirements that creates a compelling need to innovate.

Executive Champions

The third key prerequisite for innovation by subsidiaries in emerging markets is the support of executive champions, both at the subsidiary and at corporate headquarters. Leading an innovation effort from an emerging-country R&D center, especially one without an established track record, goes against the dominant mindset of many multinationals and presents many challenges. An executive champion who believes in the center’s ability can mitigate these challenges.

Cisco India R&D had built credibility with key executives at the company’s headquarters through its consistent performance over the years. Pankaj Patel, a senior vice president in Cisco R&D at the time, was a strong believer in the emerging-market opportunity and the capabilities of the India center. Wim Elfrink, Cisco’s chief globalization officer, who was located in India at that time, was also a strong champion.

With support from these executive champions, Cisco India’s R&D leadership in 2009 put up seed funding to explore opportunities in emerging markets. The funds supported two key staff positions — a chief technical architect and a product manager — bridging the skill gaps at the India R&D center and creating the core team for new initiatives.

In sum, Cisco India’s R&D had all three enablers of innovation in place: a critical mass of end-to-end product development capability, a growing market with unique needs, and executive champions. It is easy to see how an innovation initiative would falter without any one of these three factors. Without advanced technical capabilities, it would be impossible to architect and lead product development. Without a unique market opportunity, there is no business case. Without executive champions, it would be difficult to mobilize resources and find traction within the company. Therefore, R&D managers need to evaluate where they stand vis-à-vis these factors before embarking on innovation in and for emerging markets.

Decision #2: What Product to Develop?

Once the key enabling factors are in place, the next step is to identify a suitable product to develop. This demands careful consideration of market needs and an assessment of both internal capabilities and the overall fit of the chosen product and its category with the company’s product portfolio. While the actual product will vary depending on the industry, attention to these three factors increases the chance of success.

Market Need

The product has to address an important need that customers in emerging markets have. The core team at Cisco met with customers in emerging markets to understand their needs and pain points. Cisco found that the mobile-subscriber explosion in emerging markets was fueling rapid capacity expansion by service providers. At one point in 2009, India was adding about 15 million new mobile subscribers a month. The number of cell sites was expected to grow rapidly in such markets: The technology market intelligence company ABI Research predicted that by 2014, 39% of all cell towers would be located in the Asia-Pacific region. These trends indicated that there was an opportunity to develop a mobile backhaul router5 (also known as a cell site router) that links cell towers to the core telecom network.

Portfolio Fit

The product should also fill a gap in the company’s product portfolio. This will generate new revenue streams and increase the chance of internal support for the product. A modern telecom network is hierarchical, with the core backbone network of large routers connecting cities over very high-speed links; the core network is fed by networks that aggregate traffic from cell towers in a geographical area such as a metropolitan zone. In 2009, Cisco was a strong player in the “core” and “aggregation” layers of the service-provider network, but it was less dominant in the mobile backhaul router segment, which had a few strong competitors. Therefore, a product for this segment seemed to be complementary to the company’s existing portfolio.

Further, the pattern of network evolution in India and other emerging markets imposed some unique requirements on the product. Mobile backhaul was moving from the prevalent 2G technology for voice to 3G/4G technologies for data and broadband. However, even with the deployment of 3G/4G, legacy (2G) systems persisted, as voice was still a large source of revenue for telecoms in India. Therefore, the proposed router had to be versatile enough to support existing 2G services as well as to handle rapid scalability to the next-generation 3G/4G mobile backhaul technology.

Product-Capability Fit

The product should ideally be one that is reasonably complex, but also one that builds on the capabilities of the subsidiary and that can be developed within a relatively short period. A product of low complexity would not work as a compelling proof point to demonstrate the subsidiary’s product-development capability. At the same time, a very complex product would take too long, which would test the patience of headquarters. The project might even run out of steam before the R&D center could develop a working prototype and validate demand.

The aforementioned attributes helped the core team arrive at a product that could be developed from the India R&D center. Cisco India decided to develop a family of routers, the ASR 901, for last-mile access in mobile backhaul of telecom networks. Essentially, these routers would be the entry point for consumer mobile voice and data from the cell towers into the telecom network. For Cisco India, a product for last-mile access in mobile backhaul was something that could be developed in 12 to 18 months and also filled a critical product portfolio need.

Decision #3: How to Develop the Product?

Once a suitable product has been identified, the next step is to develop a working prototype, followed by the end product, which is fully functional, is extensively tested and qualified, and can be manufactured in volume. Product development is a resource-intensive activity, requiring head count, equipment, and other infrastructure. At this stage, there are generally two options that subsidiary managers can pursue.

The first option is to present the business case for the identified product to headquarters and secure necessary resources to undertake prototype and product development. In this approach, the development of the product will have the full support of the organization. However, with multiple proposals for products in different market segments competing for resources, there is a chance that the proposal may not be supported. This is especially true in the case of unproven product-development capability and an untested emerging market. The second approach is to develop the prototype with locally available resources and demonstrate product-development capability and commercial viability. In this approach, garnering the necessary level of resources may be a challenge. Furthermore, any unforeseen challenges and delays may compromise the viability of the project due to its limited resources and acceptance within the company.

The Decision Matrix

We have developed a decision matrix to provide a general framework for choosing one approach over the other. (See “A Decision Matrix for Product Development by a Subsidiary.”) The horizontal axis captures the relative strategic importance of a given geographic market to the company vis-à-vis other markets, which could be high or low. The vertical axis is project specific and captures the nature of the business case for the proposed product.

The business case may have a strong quantitative orientation, which means it would include hard metrics such as investment dollars, total addressable market, estimated market share, estimated revenue for one to three years, and return on investment. A qualitative business case, on the other hand, would stress factors such as mind share in a new market, gaining early-entrant status, countering growing competitor dominance in an emerging market, and the total addressable market over a longer period. Of course, every business case will have both quantitative and qualitative elements, but this dimension identifies which one predominates. When the business case is quantitatively oriented, it is easier to communicate and garner support than when it is qualitatively oriented.

When the relative importance of the geographic market for a company is high, it can be assumed that the company is well attuned to the market’s trends and requirements. Therefore, any such product with a quantitatively strong business case (top-right quadrant) is likely to be on headquarters’ radar and to get into the development pipeline.6 In this case, the local R&D center has to compete with other R&D centers in the company to take ownership for developing the product. If there is a quantitatively strong business case for a product, the local R&D unit has a good chance of convincing headquarters to invest. Therefore, initiating the standard product-approval process with headquarters would be the preferred option (top-left quadrant). However, it is possible that the business case has a qualitative orientation because the opportunity is still nascent. In this case, even if the market is important for the company, the opportunity may not be immediately apparent. The local R&D unit, by virtue of its proximity to the market, is more likely to be in tune with such emergent requirements. But the qualitative orientation of the business case makes it difficult to quantify the return on investment and get product development approved by headquarters. In such cases (bottom-right), the R&D center needs to creatively mobilize resources to develop a working prototype. We refer to this as “bootstrapping.” Finally, if the relative importance of the geographic market is low and the business case is qualitative (bottom-left), it is better to wait until there is a more quantitative business case or there is a strategic shift toward the market within the company.

Cisco India’s mobile backhaul router for last-mile access mapped onto the bottom-right quadrant of the decision matrix. Even though India was an important market for Cisco, as evidenced by the establishment of the globalization center in India, the business case for the proposed router would not have met some of the quantitative thresholds typically needed to successfully get through Cisco’s companywide R&D project-commit process. However, the router project presented a qualitatively strong business case: The product addressed a pressing customer need, filled a critical gap in the company’s portfolio, and aspired to open up a segment where competitors were rapidly gaining a foothold in an important market. Therefore, the core team in India decided to take a bootstrapping approach (bottom-right in the matrix) to develop the prototype. This novel approach to product development provides an alternative to the more common structured product development process within companies.

Bootstrapping

The core team, comprising the chief technical architect and the product manager, realized that it would be difficult to start the development of ASR 901 through Cisco’s structured R&D project-commit process. They needed to bootstrap by cobbling together the limited resources at their disposal to build a prototype and successively work their way toward broader acceptance within the company. This strategy had to be executed on multiple fronts to mobilize the key resources required for development.

In addition to the chief technical architect, the team needed a few senior technologists with expertise in specific domains to design state-of-the-art, complex features and provide general technical direction to the rest of the engineering team. However, there was a shortage of domain experts, especially in some of the advanced networking protocols, and hiring from outside was difficult and expensive. The team instead bridged the domain expertise gap by borrowing a handful of senior engineers handpicked from other business units in India. This was possible because several groups had developed advanced technical capabilities in specific technology areas over the years. Further, since the success of the project was important for establishing the product-development capabilities of the India R&D center, other engineering organizations within the company’s operations in India were forthcoming in offering resources to help the project get off the ground. This arrangement also kept the costs down and stretched the modest seed funding the team was given. However, the technology implemented was cutting edge and adhered to global standards.

To build a prototype, the engineering team had to be staffed up considerably. With minimal seed funding at its disposal, the team decided to engage with an engineering-services partner. The service partner would execute part of the development effort through a new revenue-sharing model. Instead of the traditional time and materials model, where payment is made at the time the services are provided, the new model involved payment as a percentage of revenue as the product started selling.

This new revenue-sharing model had several advantages. First, it deferred the nonrecurring engineering cost to a future date when the product had wider acceptance within the company, thereby stretching the minimal seed funds available. Second, it helped develop deeper partnerships with local companies and strengthen the local ecosystem through technology transfer. Third, it was a much faster way of staffing the team than hiring from the market. Fourth, the services partner had “more skin in the game” and worked as an integral part of the team, which was essential for a new product development effort.

ASR 901 product development involved working across the entire stack of technologies — silicon chips, platform hardware, platform software, network operating system, and network management — and having them closely interface with each other. Many of these technologies were developed within Cisco, some came from suppliers as off-the-shelf components, and other portions were codeveloped with partners.

For codevelopment, physical proximity and constant engagement with the partners was extremely important. However, most of the partners did not have a significant presence in India, and the handful of people who were locally available did not have the in-depth technical expertise to work with Cisco on a complex, next-generation product like ASR 901.

There were two particular touch points when close interaction was critical. First was at the time of architecting the product, when it was important to understand the chip’s capabilities and all its nuances, to be able to clearly define the hardware/software interfaces. Second was the “bring-up” phase, when the functionality of the prototype was tested for the first time, and intimate understanding of the silicon component and the hardware/software interface was critical. Working with partners halfway around the world was not viable.

To overcome this hurdle, the team leveraged Cisco’s long-standing relationship with its suppliers. The team, through its champions at headquarters, was able to convince the key suppliers to staff up in India in order to support the development of ASR 901. The suppliers moved some key personnel to India, and this essentially plugged the gap in the hardware ecosystem for the development of ASR 901.

In sum, the team creatively mobilized all types of resources necessary for prototype development. It worked like a startup within a large company. The hierarchy was kept to a minimum, and all the engineers — Cisco employees as well as engineers from the partner organization — worked in a common workspace. This facilitated impromptu whiteboard discussions and quick resolution of questions and issues. The junior engineers were guided by the senior engineers and received immediate feedback on pieces of code and design. This setup facilitated rapid learning and quick resolution of issues through joint problem-solving. Further, close interactions with the partner organization gave the team ample exposure to technical constraints and trade-offs. As the team members designed and developed the product prototype, they constantly challenged entrenched design norms to meet the stringent product requirements of emerging-market customers with respect to cost, power, and form factor, while simultaneously advancing the state of the art in mobile backhaul technology. With this setup, the team was able to build a working prototype within six months.

The effort shows that bootstrapping can be a viable alternative to the standard corporate prototype-development process that involves getting up-front commitment to a concept. The specific activities involved in bootstrapping will depend on the industry in which the company operates and the nature of the product being developed. However, the Cisco experience provides some general guidelines to managers on the types of organizational arrangements that can be structured to build a prototype on a shoestring budget.

Integration Into Mainstream Development

Once a working prototype is in place, managers can demonstrate the technical and commercial viability of the product to all stakeholders within the company. They can also showcase the prototype to select customers for early feedback and assess the level of interest in the product. If the prototype is well received by internal and external stakeholders, the business case is made, which paves the way for full-scale development.

The ASR 901 prototype started getting attention from customer-facing organizations in the company. The active engagement of the core team with customer-facing groups resulted in a slow but sure realization that the product filled a gap in the company’s portfolio. This provided market validation for ASR 901. Importantly, the product gained excellent traction with some key customers in the developed markets because it offered leading technology features at attractive cost, power, and form-factor-design points. For example, low power consumption, which was critical to containing operating expenses in emerging markets, found an additional application in the developed markets, where corporations have a social-responsibility mandate to be “green” in addition to delivering economic benefits.

The team now had a working prototype along with a demonstrated business case, thanks to customer interest in emerging and developed markets. The validation of the concept cleared the way for “execution commit” from the company. Headquarters sanctioned the next round of funding, which went toward staffing up the engineering teams and building the large number of prototypes required for full-fledged testing and qualification.

As a result of these developments, the product became part of the mainstream engineering organization. With formal recognition and funding, the team aligned itself with Cisco’s standard product-development process and was able to leverage domain expertise from other teams to complete the development and qualification and enter trials with early customers.

The Transformation of Cisco India

ASR 901 was launched in October 2011. Over the next year, several variants of ASR 901 were developed and sold to more than 100 customers in 46 countries. The product improved on the state of the art in some of the key emerging mobile backhaul technology areas. It achieved this with significant improvements in cost, power, and footprint efficiencies, which met the stringent requirements of emerging markets while greatly appealing to developed markets. The success of the project was one of the factors that contributed to the formation of a new Cisco business unit, Provider Access Business Unit (PABU), centered in India.

The market success, strengthening of product-development capability, and organizational evolution led to a string of new products from Cisco India over the next few years. In December 2014, Cisco showcased three new communications products conceptualized, architected, and designed in India.

In 2015, Pankaj Patel, executive vice president and chief development officer at Cisco, summarized the transformation of Cisco India: “We came to India for the costs, we stayed for the quality, we invested for innovation, and now we are creating a new industry.”7