Platform Ecosystems: Aligning Architecture, Governance, and Strategy (2014)

Part IV. Orchestrating Evolution

Chapter 11. Evolving an App

Abstract

This chapter describes how app developers can evolve apps in platform markets. It begins with an overview of the dynamics of platform markets from an app developer’s perspective, and describes how an app can be designed and then evolved through a careful combination of app microarchitecture within the constraints of a platform’s governance. We first describe how apps can be evolved in the short term to be resilient, scalable, and composable. We then describe how app developers can improve their stickiness, manage the tradeoffs in choices about platform synergy, and improve their app’s plasticity in the medium term. We then describe how, in the long term, app developers can exploit envelopment opportunities and rebuff envelopment attacks from other apps as well as from the platform owner. We also describe two strategies that app developers can use to grow an app into a platform in its own right. We conclude with a description of how their durability or survival in a competitive market and mutation into different markets can be orchestrated.

Keywords

Eureka moment; app resilience; synergy tradeoffs; growing stickiness; horizontal envelopment; app survival; app durability; app mutation; business ecosystems

People don't know what they want until you show it to them.

Steve Jobs

In This Chapter

• Dynamics of apps in platform markets

• The Eureka moment and the origin of apps

• How an app's microarchitecture influences its evolvability

• Ensuring app resilience, scalability, and composability

• Growing app stickiness

• Managing tradeoffs in platform synergy

• Enhancing app plasticity

• Orchestrating vertical and horizontal app envelopment

• Bold retreats and envelopment survival tactics

• Enhancing app durability

• Orchestrating app mutation

In the late 1990s, a major US chemicals manufacturer stumbled upon a promising market opportunity: There was not one single brand of bug spray that customers were unequivocally happy with. The company invested millions of dollars in research and development to create the most effective bug spray ever created. It refined the packaging to eliminate everything about existing brands of canned bug sprays that irritated consumers. It priced it competitively and launched with a glamorous advertising blitz on television and in print. It was an investment in the future, the company thought, to make the product a household name. Sales immediately took off nationwide and it looked like it had a winner on its hands. Until a week later, when, to its utter surprise, sales stalled. Instead, the company's warehouses were flooded with returns. It immediately sent the returned cans of bug spray back to the lab. It found nothing wrong. Every can consistently killed bugs more effectively than any product on the market. Puzzled, it interviewed a sample of consumers to figure out what went wrong. To its surprise it found that when the consumers used the bug spray, the sprayed bugs scurried away, only to die a few minutes later. This created the perception that the formula was not effective. Instead, what the consumers were expecting was that the bugs would die on the spot. The company tweaked the formula to add a paralyzing agent to it, which immediately paralyzed the bugs and then slowly killed them in the same amount of time. The revised formula went on to become one of the leading brands of bug spray since then. The company's mistake: Failing to recognize that the customers' latent need was not just to kill the bugs but to see the bugs squirm and die.

Perception is as important as substance. Any product must meet its customers' latent needs. In platform markets, perceived value often trumps technological superiority, otherwise Linux would have a 90% market share and Windows 10%. The lesson for app developers is that the key to thriving in competitive markets is discovering and meeting their end-users' latent needs—needs that they often might not be able to even articulate. Evolving apps is then the process of discovering and satisfying end-users' latent needs, and doing it better than rivals.

This chapter focuses on how app developers can evolve apps in platform markets. It begins with an overview of the dynamics of platform markets from an app developer's perspective, and describes how an app can be designed and then evolved through a careful combination of app microarchitecture within the constraints of a platform's governance. We first describe how apps can be evolved in the short term to be resilient, scalable, and composable. We then describe how app developers can improve their stickiness, manage the tradeoffs in choices about platform synergy, and improve their app's plasticity in the medium term. We then describe how, in the long term, app developers can exploit envelopment opportunities and rebuff envelopment attacks from other apps as well as from the platform owner. We also describe two strategies that app developers can use to grow an app into a platform in its own right. We conclude with a description of how app durability and survival in a competitive market and mutation into different markets can be orchestrated.

11.1 Dynamics of platform markets

Like the book publishing and movie business, app development—particularly in consumer-oriented platform markets—is a hits-oriented business. Apple alone paid on average over a billion dollars a year in royalties to app developers in the first 5 years of its iOS platform's existence, a number that rose to $4 billion a year by 2013 (Strietfeld, 2012). However, the payoff was very unevenly distributed: 25% of its app developers made less than $200 and about 4% made over a million dollars. App development is therefore an ecology weighed heavily toward a few winners (Strietfeld, 2012)—a classic winner-takes-most market. It is the prospect of a huge payoff and the modest upfront investment that attracts new app developers into platform markets.

The numbers tell this story. The “app economy” surrounding mobile computing platforms created 500,000 new jobs in the United States alone (Strietfeld, 2012). For an app developer, one big hit can make up for the losses on many duds. The top 250 apps in iOS and Android platforms had an average daily audience of about 52 million users, which roughly equals the circulation of the top 200 US weekend newspapers or the three top-rated primetime TV shows in the United States in early 2013.¹ This market grew from almost zero to $25 billion in revenues in five years by 2013. On average, users of iOS and Android platforms actively used eight different apps on an average day.

App development can be costly and multihoming even costlier from an app developer's perspective. For example, apps for iOS average about $10,000 in upfront development costs (Economist, 2012a,b). When competition is fierce—as it often is in growing markets—introducing a decent app alone does not guarantee success in a crowded marketplace (Strietfeld, 2012). Neither does aggressive pricing. An app must solve a fundamental but widespread enough problem in a novel way, as described in the next section. If an app meets this criterion, it will not be long before it has many clones. Evolving the app to introduce new features faster than rivals can copy them is the only shot at surviving. In other words, an evolvable app is a more competitively adaptable app. Such evolvability is determined by the app's microarchitecture. While these patterns illustrate dynamics specific to consumer-oriented mobile computing platforms, they are just as applicable to any other platform market.

11.1.1 A rising tide floats all boats

When entering or creating a new market segment, an app developer is likely to see an initial period of slow growth followed by a sharp takeoff (Agarwal and Bayus, 2002). For example, the auto industry was created in 1899 but the mass market did not take off until 1909 (Agarwal and Bayus, 2002). The popular belief is that new entrants put downward pressure on price, and that price decreases attract new adopters. This is only part of the story. How much downward price could possibly exist when apps are priced at zero, as was typical in mobile computing platforms in the mid-2010s? The other part of the story is that new entrants often also raise all boats because they also grow the market. As economists would describe it, the new entrants shift the “demand curve” (Agarwal and Bayus, 2002). In particular, the entry of big firms legitimizes the new app category. Initial sales are often slow due to the primitiveness of new apps in new categories, where new entrants subsequently foster more features-driven competition. As new rivals enter the category created by such an app, the actual and perceived product quality improves (Agarwal and Bayus, 2002). Therefore sales growth does not have to come at the expense of profitability compression associated with declining prices. In other words, the initial innovator can be better off because there is now a much bigger pie to be split. A study of 30 major product innovations over a 150-year period showed precisely this: Price decrease accounted for only 5% of the takeoff growth but new entrants accounted for about 50% of the takeoff of a new market (Agarwal and Bayus, 2002).

11.2 The Eureka moment and the origin of apps

To understand how apps evolve, we must begin with the question of where the ideas for the most successful apps come from. Innovation theorists and marketers often think of end-user needs as hidden, waiting to be discovered by a clever entrepreneur. However, in platform markets, this is a tricky assumption and only half the story. Sometimes new needs are created by the introduction of technologies themselves, which create a need that did not exist until recently (Arthur, 2009, p. 175). As complexity scientist Brian Arthur (2009, p. 175) once said, possession of rocketry technologies created the need for space exploration. Similarly, the introduction of new technologies can generate new needs that are unobvious to the naked eye.

The commonality in blockbuster apps? They surface and address needs that end-users don't even realize they have. There is no substitute for deep immersion in an ecosystem as an end-user to recognize such emergent needs spot an app opportunity. Would-be app developers often discover a fresh opportunity when they realize that some difficulty that they are experiencing might be faced by other end-users as well. Deep immersion as an end-user in an app's application domain can be a rich source of deep, firsthand insights into real problems, frustrations, and irritations that spark an idea that becomes an app's Eureka moment. The most successful apps begin with one insight about an unrecognized problem and a potential solution to it. Such insights, grounded in knowledge of the app's application domain, can play a primary role in defining opportunities for new apps. The Eureka moment that led to Dropbox was when Drew Houston (Dropbox's founder) left his USB thumb drive at home when he showed up at work. The Eureka moment for the Polaroid instant camera was when founder Edwin Land's daughter asked him why she could not see the photograph that he had just taken. App developers that enter a platform market in this way are often new entrants who see opportunities that existing app developers might have failed to see.

If the problem is real and widespread, an app that addresses it can create an entirely new market within a platform's marketspace. Such markets are what we describe as blue ocean markets that expand the entire ecosystem, as opposed to red ocean markets where rival apps compete over existing end-users in existing markets (see Figure 11.1). The former create new segments of the market and address unmet end-user needs, as opposed to the latter that engage in a bloody fight over an existing pool of end-users.

FIGURE 11.1 Blue ocean apps often originate with a Eureka moment.

Such “blue ocean apps” have little precedent or historical demand data because their market has not yet emerged. Traditional market research methods are of limited value in such markets. Evaluating the idea then requires answering a few elementary questions.

1. How widespread is the problem that the app addresses?

2. Who will be the primary adopters, how will they use the app, and why?

3. What will they be prepared to pay? What will stop their adoption dead in its tracks?

11.2.1 Who is the incumbent? Think again

A trickier question is identifying what the app must compete against. The obvious answers are usually the wrong ones. Dropbox, for example, succeeded where many other file synchronization services failed because Houston recognized that his competition was not other file-sharing services but inexpensive USB thumb drives. Palm succeeded in creating a PDA market where Apple, Texas Instruments, Sony, Microsoft, and Sharp failed because it recognized that its competition was the plain old paper organizer, not users' desktop PCs or laptops. Their offerings were designed from the outset to outdo the value proposition of incumbent technologies very different from what their failed predecessors had envisioned. This led to a different prioritization of functionality that they focused on and also led to consequential decisions about what their solutions were not going to attempt to accomplish. From the get go, Dropbox and Palm focused solely on outdoing the value proposition of a thumb drive and a paper organizer.

End-users' perceptions matter tremendously in the success and failure of new market offerings. It is therefore critical to recognize what they'll actually compare your app against rather than what you think they will compare it against. In entering such nascent markets, it is important to not attempt to go for the big market at once. Understanding this origin of blockbuster apps can guide app developers to evolve just about any app by recognizing sources of fresh insights and ideas that compensate for the lack of the rare Eureka moment. Successful category-creating apps will soon attract new rivals out of thin air, initiating a Red Queen race within that category. This brings us to app evolution.

11.3 How app microarchitecture shapes app evolvability

Platform architecture constraints but does not determine the microarchitecture of apps in its ecosystem. Apps within the same platform can have considerable variance in their internal microarchitecture because of two choices made primarily by app developers. First, identical apps with identical internal microarchitectures can vary in their compliance with a platform's interface standards. This gives them different architectural properties that impact their evolvability. Second, different app microarchitectures partition the app's functionality differently between the code implemented in an app and the functionality leveraged from the platform. This choice changes the parts of an app that are built from the ground up by an app developer and those that are reused from the platform through application programming interfaces (APIs) and platform interfaces. Recall that the four pieces of functionality in an app are:

• Presentation logic, where the interaction with an end-user is handled

• Application logic, where the core function of the app is implemented

• Data access logic, where access and retrieval of data are handled

• Data storage logic, where data are stored

The division of these four functions across a client device and a server results in cloud, client-based, client–server, and peer-to-peer app microarchitectures. (If all four functions are implemented on the client side, it results in a standalone app.) In a platform environment, an app developer can choose how much of each of these four functions is implemented from the ground up in an app and how much is implemented by calling on the services of a platform. This is illustrated in Figure 11.2.

FIGURE 11.2 The four functions in an app's microarchitecture can flexibly be split between an app and the platform.

The choice of app microarchitecture influences the evolutionary trajectories that are open and closed to an app. Put another way, an app's microarchitecture embeds real options and allows an app developer to subsequently repartition the division of the functions that are platform-based versus app-based. This has consequences for what an app builds and leverages. It also has implications for an app's potential for resilience, scalability, requirements of processing power on client devices, and dependence on a robust data network, as summarized in Table 11.1.

Table 11.1

A Comparison of the Key Properties of Various App Microarchitectures

, Low; medium; •, high; ~, varies.

A few noteworthy properties of each of these app microarchitectures have implications for app evolution:

• Cloud-based microarchitectures are the modern reincarnation of dumb terminals in host-based systems. Their advantages are that they are the most conducive of all app architectures to running on “weak” client devices with low processing power, updates can be centrally pushed out to app users instantaneously, and the app developer usually has almost complete control over the app. However, this microarchitecture's weaknesses are a single point of vulnerability shared by all end-users, costliness to scale, and the potential to be sluggish as its usage grows.

• Client-based microarchitectures keep only the data storage logic on the server side. It is most appropriate when app data storage needs are high but the devices that it is deployed on are modest in their own storage capacity (e.g., devices connected to the Internet of Things). It is also network-intensive because of the large volume of data that must flow between a client and the server.

• Client–server microarchitectures follow a balanced partitioning of the four functions. They are average in every property but excel at nothing. They are also the most conducive of all app microarchitectures to placing the most server-side functionality on the platform.

• Peer-to-peer microarchitectures are the most scalable of all app microarchitectures and have the strongest potential for positive same-side network effects. However, they leave an app developer with the least control over the app. They are also harder to implement in their pure form in platform environments because some app developer control and centralized coordination is often needed for most apps.

• The implementation of any of these app microarchitectures can also involve tiering, which is splitting the implementation of at least one of the app's core functions across multiple server-side devices. (Tiering, as we subsequently explain, increases an app's scalability.)

Standalone app microarchitectures are the most resilient simply because they do not do much. Standalone architectures are like using a computer without an Internet connection. It will never fail, but you will not be able to do much with it to begin with. Leveraging a platform in building an app inevitably means exposing the operation of an app to some vulnerability. Once an app developer accepts this risk, the choice of app microarchitecture has irreversible strategic consequences. Therefore, the choice of microarchitecture should not be made lightly. An app's microarchitectural choice is made in the initial implementation of an app and therefore largely irreversible.

11.4 Evolving an app: a preview

Table 11.2 summarizes the influence of app microarchitecture and app governance on app evolution in the short, medium, and long term. Their influence on the nine individual metrics of app evolution is described next. These are summarized in Figure 11.3.

Table 11.2

A Summary of How App Design Influences Its Evolution

FIGURE 11.3 A summary of the primary drivers of the nine metrics of app evolution.

11.5 Evolving an app in the short term

11.5.1 Managing app resilience

The resilience of an app is primarily a function of its microarchitecture. Overall, an app should err on the side of being internally monolithic but externally modular to follow the mirroring principle. Four high-level principles can help improve resilience of the app:

1. The KISS principle. Keep the four functions simple by not splitting too many of them across the app and a platform. When faced with two alternative design choices in the implementation of your app, the correct choice is always the simpler solution.

2. Follow the rules. Stick with standardized platform interface guidelines and API conventions. This ensures that the relationship between the platform and the app remains sufficiently modularized. Avoid workarounds, which often result in architectural debt that must be paid back with often too much interest along the evolutionary trajectory of an app. A simple proxy to estimate the modularity of an app is to count the number of function calls by an app to the platform (MacCormack et al., 2006). By reducing the span of changes needed to implement a change in the app, modularization facilitates efficient testing and verification of the integrity of app-level changes (Baldwin and Clark, 2000, p. 88). Compliance with the platform's interface standards also ensures that the app can readily integrate with the platform every time an internal change is made in either the app or the platform.

3. Understand your decision rights. Clearly understand what decision rights belong to you and which ones to the platform owner. Decision rights that are assigned to you as an app developer encompass both the authority and the accountability for those decisions.

4. Internal design redundancy provides future flexibility. Designing some internal design redundancy within your app embeds real options that can provide valuable future flexibility. For example, redundancy in the design of the data storage logic would allow relocating to local storage from cloud-based storage services provided by the platform (e.g., iCloud) or to external storage services (such as Amazon Elastic Cloud). Also minimize cross-app dependencies and stick with standardized, open interfaces where possible.

11.5.2 Improving app scalability

The scalability of an app refers to its ability to maintain its functional performance and financial viability with increases or decreases in the number of app end-users. Scalability is heavily influenced by an app's microarchitecture, as summarized in Table 11.1. From a technical scalability perspective, the peer-to-peer architecture is the most upward and downward scalable. However, this microarchitecture is limited in its viability to a few apps where centralized coordination requirements on the part of the app developer are modest. The next best choice in terms of scalability is client–server architecture, which provides a middle-of-the-road value on all evolutionary metrics. The cloud-based microarchitecture will provide high scalability under one of two conditions: (1) if the most data-intensive functionality such as the data storage and data access logic resides on the platform or (2) if some core aspects of an app's application logic builds heavily on the platform's native capabilities or ecosystem-wide services and APIs that cannot viably be implemented within the app. Platforms such as iOS and Android provide such services, for example, in the form of voice recognition capability. App developers must, however, be wary that their app's performance is then critically dependent on the resilience and scalability of the platform, which a platform owner ought to be able to guarantee in the form of service-level agreements and uptime promises. A second technical consideration for app developers is the preference to use tiering. This embeds real options in the app in the form of the SWITCH INPUTS option.

To cope with a growth in demand and the associated need for upward financial scalability, app developers can create a menu of different versions or editions of an app, each priced differently to cover the costs of features that are scale-intensive. See also the subsequent discussion on app versioning strategies.

In terms of an app's financial scalability, building in downward scalability also has implications for the design of the initial implementation of the app: Its fixed costs should be low for it to have a scale-down option. Cloud microarchitectures have the most downward scalability when the four app functions are implemented primarily on the platform rather than app side. This minimizes the app developer's upfront investment on the app side, reducing the app's fixed costs. In turn, this reduces the number of end-users needed to reach the positive financial breakeven point using the same logic as platform scalability that was described in Chapter 10. In developing the initial release of the app, an app developer must first deliver baseline standalone value to end-users to be viable before a critical mass of users is reached. A valuable standalone application is very powerful in overcoming the critical mass problem at the outset (Rohfls, 2003, p. 197). Recall that most successful platforms started out as products or services that were useful in isolation. Similarly, an app that it useful even in the absence of network effects faces a less uphill battle in getting off the ground. Think in terms of the must-do elements of the app in a real options sense, starting with the minimum viable footprint. Focus on the anchor features and unique functionality in the initial version that you get out of door. This is the smallest subset of features needed to validate the key assumptions in your app's business model. It should be accompanied by an app roadmap—the “may-do” list in real options lingo—that articulates the plan for adding new features and functionality over time. Tweaks, refinements, and nice-to-have features can come later as cognitive bandwidth and app development resources permit. Networks effects-based features are a good add-on, but often as a subsequent may-do stage of the app development project. Alternatively, if the app's concept depends on the need for network effects, an app can sometimes ride on the platform's end-users network from the get-go. Many platform owners, however, explicitly prohibit apps from doing this. If they do allow it, it introduces the risk of making the app too dependent on the platform and making it more vulnerable to downstream vertical envelopment by the platform owner.

11.5.3 Enhancing app composability

Evolvability of apps is even more important than the evolvability of the platform because different apps will often face differential market pressures, to which they must adapt at different rates (de Weck et al., 2011, p. 125). We described in the previous chapter how modularization of a platform's interfaces and their alignment with how a platform owner governs the platform ecosystem allow the ecosystem to absorb differential rates of change in apps. The same alignment that facilitates platform composability facilitates app composability. (The linkages between a platform and a particular app are identical from the app developers' vantage point and the platform owner's perspective.)

Recall from Part I of the book that app developers face two types of costs in developing for a platform: app innovation costs incurred in developing capabilities unique to their app and systems integration costs incurred in getting the initial app and every subsequent revision working with the platform. Figure 11.4 illustrates the approximate breakdown of these costs across different stages of the app lifecycle. The stages in the development cycle of an app can be summarized as follows. In reality, they are rarely as linear or sequential as suggested by their oversimplified representation in Figure 11.4.

1. Opportunity recognition. A latent need is recognized and a market for a future app is identified.

2. Design. A vision for what an app will accomplish is first developed. This is the app's high-level design that also spells out a detailed description of the app's features and capabilities in the sense of the classic waterfall model. This is followed by the detailed design, where app features are prioritized, mockups are field-tested with representative prospective end-users, and microarchitectural choices are made. The microarchitectural choices are usually one-time choices that are subsequently not reversible in subsequent revisions of the app. Most of the app innovation costs are incurred in these two stages and the work in the subsequent stages is largely grunt implementation and integration work.

3. Implementation. The actual implementation of the detailed design in code is done in this stage.

4. Platform integration. The completed app is integrated with the platform at this stage. Most testing tools and simulators provided by a platform owner are used to reduce costs at this stage.

FIGURE 11.4 Reducing app integration costs frees up more resources for app innovation.

The app developer's total app development costs are the sum of app innovation costs and app integration costs. Modularizing the connections between the app and the platform reduces app integration costs. Modularization grants within-app freedom while also lowering the need for coordination, thus making an app more free to evolve (Baldwin and Clark, 2000, p. 221). This in turn frees up cognitive resources that an app's developer can now reallocate toward innovation in the functionality of an app, increasing the potential for increasing the inflow of new innovations into the app.

Modular linkages with the platform allow app developers the autonomy to decide how the app is implemented and to freely make changes inside an app. An app developer can treat the rest of the ecosystem largely as a blackbox, paying attention to only how the app will interact with it. This is akin to driving a car: You don't need to know how its parts work; just knowing how to interact with them is sufficient. This allows an app to evolve faster, reduces cycle times for new releases, and allows the app to evolve at a rate that is appropriate for the dynamics of its own market rather than be constrained by the platform's tempo. Put another way, modularization speeds app evolution and minimizes the cost of change (Ethiraj and Levinthal, 2004a,b; Sanchez, 1995; Simon, 2002). This increases the likelihood that an individual app can—but not necessarily will—adapt faster to its environment, hence be more likely to survive in evolutionary Red Queen competition (Simon, 2002).

However, platform modularization without an alignment with decision rights does not grant sufficient autonomy to app developers to pursue app evolution. Similarly, decentralized governance without modularization of the linkages between an app and the platform will spiral app developers' integration costs out of control. The integrating mechanisms provided by modularized architectures must therefore be complemented by decentralized app governance for the two to reinforce each other. Therefore, for an app developer to realize the advantages of modularized linkages with the platform, the app decision rights granted to app developers must be accepted by an app developer to make this mirroring arrangement work. This requires compliance by an app developer with the platform's interface standards and platform API guidelines described in Chapter 5. This is a function of the decision rights and control dimensions of governance. As long as an app developer complies with the interface standards of a well-modularized platform, successful integration is virtually assured. Therefore, an externally modularized app architecture coupled with an internally monolithic app microarchitecture enhances an app's plasticity, and subsequently its competitive durability in the long run.

11.6 Evolving an app in the medium term

11.6.1 Growing app stickiness

Stickiness of an app is with the app's end-users. Stickiness is a challenging objective for app developers. Recent surveys show that while end-users, on mobile platforms for example, are using apps more intensively, only half of the apps that they were using heavily in the preceding year were still in use a year later (Economist, 2012a,b). This app abandonment rate of about 50% is a troubling number, especially because it is for apps that broke through the crowd of rivals to become heavily used apps. Increasing app stickiness begins with the prerequisite that an app's end-users perceive it as valuable and easy to use. After this, app developers can use six distinct strategies to enhance the stickiness of an app over time:

1. Discovering and meeting the latent needs of existing and prospective end-users. While a platform owner can have a large number of app developers feeding ideas and innovations into a platform's ecosystem, who can an app developer turn to for generating a stream of new ideas that expand an app's stickiness? Three sources: (a) discovering latent end-user needs, (b) learning from lead users and early adopters, and (c) insights from the analysis of embedded in-app analytics.

• Discovery of latent needs. Steve Jobs once said that customers do not know what they want. As Apple's success in the past decade demonstrates, consumers' self-stated opinions of what they want in a product can be a poor predictor of market success. Asking consumers what they want will give you a list of needs that they can articulate, not needs that they don't even realize they have. These are their latent needs. Discovering latent needs requires the same kind of deep immersion in the end-user context as the one that leads to bigger Eureka moments, described earlier. What you need are insights into what your end-users want to accomplish, not what they say they want or need. Figure out the “job to be done” in a better or more affordable way. But identifying, say, three latent needs still does not tell you which one matters more in the mind of an end-user. How much would they be willing to pay if an app met that need?²

• Watch to your lead users. Your app's lead users and early adopters are a second rich source of new ideas. These are your app's users who tweak, hack, and modify an app to make it do things they would want it to do. Lead users have specific needs that arise before the mass market and often have very high expectations. Their pressing needs today might eventually be widespread in your app's core market because they face them ahead of the mass market. By incorporating and monitoring ideas from the lead users, app developers can enhance their offerings, reduce the risk of market failure, and reduce their own design costs (Baldwin and von Hippel, 2011; von Hippel, 1986, 1988). However, be wary of the widespread blindspot created by having app evolution decisions inordinately influenced by the needs of its existing end-users while neglecting prospective ones.

• Embedded in-app analytics. A third source of new ideas for extending an app is by embedding deep analytics into an app that show how an app is actually used. Analyzing such usage data can provide unexpected insights into functionality that is not being used, tasks that require more steps than they should, and features that end-users most use. Subtract what gets in the way of the functionality that an app's users really value. Retire features that have run their course and no longer match users' real needs. In-app analytics can also be used to run mini-experiments with iterative tweaks to an app and seeing how users' respond in their behavior. The data-rich nature of software platforms and their near-ubiquitous connectivity allows probing markets, testing hypotheses, and making evidence-driven app evolution decisions.

2. Create multiple versions or editions of an app to target multiple end-user segments. Book publishers often release new books in hardcover editions first followed by lower-priced paperback versions a year or two later. The idea is that readers who value the book more will pay for the higher-priced hardcover edition and those who value it less will wait for the lower-priced paperback edition. Similarly, movie studios sequentially release movies in theaters, followed by DVDs, and then into the rental market. This strategy, which segments prospective consumers by their willingness to pay, can also be used to create variants of an app that target different segments of end-users with different levels of willingness to pay.
Having lower-priced, crippled apps with in-app upgrade options similarly lowers the barriers for end-users to try and app before they commit to buying a full-priced version of an app.
Two related tactics are the use of vanity pricing and Goldilocks pricing. Vanity pricing uses a high-priced version of an app to anchor end-users' perceptions of the value of all other versions; it is priced so high that it makes other versions appear like a bargain in comparison. The expectation is that few end-users, if any, will actually spring for the vanity-priced version. Restaurants and car companies routinely use this strategy effectively. A restaurant that has a $1200 steak on its menu makes an $80 steak look like a steal. Similarly, Lexus sells a $400,000 car, which makes its $60,000 model look like a bargain. The same tactic can be used for pricing apps, with a free version, a $2 version (the one that the app developer hopes to sell the most), and a $10 anchoring version. This strategy only works well if end-users' ability to comparison-shop across rival apps is limited.
Goldilocks pricing is based on the idea that if a customer is offered three different models of a product, they will usually go for the middle choice. If you price the middle one to make the most profit, this strategy can maximize profits. Fast-food chains and coffee shops frequently use this technique, offering three sizes of a drink with the expectation that customers will almost always gravitate to the middle size. It is perceived as neither too small nor too big but just right. App developers can use this approach to create a light, standard, and professional version of an app as long as they are careful to price their business models on the premise that the middle version will sell most. This strategy does not work if the low-end version is free and is advertising supported. In that case, the middle version should be priced to at least equal the expected lifetime advertising revenue of the low-end version. App stickiness, described subsequently, also then becomes crucial to sustaining the app developer's business.

3. Develop app-specific rather than platform-specific network effects. Just as a platform's network effects protect platform owners from rival platforms, an app's network effects can protect an app developer from its rival apps as well as from downstream envelopment by a platform owner. However, to be effective, such network effects should be unique to the app and based on that app's users rather than a broader base of a platform's users. They should also be nonportable to rival apps. For example, Dropbox's users value their ability to share files with other Dropbox collaborators. For an end-user to abandon the service for a rival offering not only requires the rival to have to deliver better functionality but also be high enough to justify losing Dropbox-specific network effects that an end-user might have developed and values.

4. Develop end-user lock-in through nonportable, app-specific personalization. This noncoercive lock-in involves implementing ways to make an app more useful the more an end-user uses it. Such personalization can create a powerful incentive for an end-user to stick with an app because abandoning it in favor of a rival app also requires abandoning the value that the app is able to deliver to that end-user through learning effects. However, app personalization is effective in increasing stickiness only if such personalization is (a) nonportable to rival apps and (b) perceived as value-enhancing by an app's end-user. App developers must be careful to keep such personalization under their complete control and in a proprietary rather than standardized format to prevent rival apps from being able to import it with the end-users' consent.

5. Multihoming across nonrival platforms. If a platform's users multihome across nonrival platforms, having an app on those nonrival platforms can increase app stickiness. For example, an app that allows an end-user to access its functionality on a mobile device and a personal computer can be stickier than one that exists on just one platform.

6. Multihoming across rival platforms. When should an app developer multihome across rival platforms? In deciding whether to multihome across rival platforms, an app developer must also recognize the risk of getting stranded with a platform that eventually turns out to be the loser. The choice of platform has significant consequences for the audience that an app reaches: In 2014, less than 100 devices were responsible for 80% of the 50 + million daily app sessions on the two leading mobile computing platforms, iOS and Android (Strietfeld, 2012). Hedging bets requires multihoming, which is easier said than done because multihoming can be costly. The safe way to avoid backing the wrong horse requires the app developer recognizing whether a platform's core market has properties that make it as winner-take-all market or whether multiple rival platforms will persist for the foreseeable future. An app developer is better off single-homing if the platform's market is a winner-takes-all market and a clearly dominant platform has emerged. However, a developer should multihome across rival platforms if a clearly dominant platform has not yet emerged. A single dominant platform will emerge only if three conditions are simultaneously satisfied in the platform's market: (a) multihoming costs are high for both end-users and app developers, (b) cross-side network effects are positive and strong, and (c) end-user needs for a platform are relatively homogenous (Eisenmann et al., 2011). If even one of these conditions is not true, an app developer is better off multihoming (i.e., developing the app for multiple rival platforms). This also protects app developers from the threat of downstream envelopment by a platform owner. Furthermore, the existence of multiple rival platforms is an opportunity for an app to gradually evolve into a small platform in its own right.

11.6.2 Tradeoffs in managing an app's platform synergy

Increasing an app's platform synergy means that more of an app's application logic and presentation is moved out of the app's own code and into the platform over time. Figure 11.5 illustrates a growth in platform synergy.

FIGURE 11.5 Increasing platform synergy involves reallocating more of the presentation or application logic to the platform.

Increasing an app's platform synergy is a catch-22 from an app developer's perspective for reasons. First, it can reduce the app developer's app innovation costs but make the app developer more dependent on the platform owner. Second, it can increase an app developer's costs of multihoming if the platform services leveraged by the app are unique to the platform and not widespread across rival platforms. Increasing app synergy can therefore make an app developer more vulnerable to downstream vertical envelopment by the platform owner. (Apple is notorious for doing this with iOS developers.) Until a dominant platform has emerged, an app developer is better off multihoming, emphasizing genericness, and deemphasizing platform synergy in the app's implementation.

App developers should increase their app's platform synergy only under two conditions, in this order. First, when increasing platform synergy allows an app to deliver unique functionality that the app's end-users value. Second, when it dramatically increases the size of the app's prospective adopter pool. Whether it economizes the amount of code that an app developer must write to implement an app often matters less unless: (1) the app developer single-homes only on that platform or (2) the app's partitioning of the four functions in its microarchitecture is heavily skewed toward being implemented in the platform rather than in the app.

11.6.3 Enhancing app plasticity

App plasticity measures how extensively an app morphs over time to allow its end-users to do new things that it was not originally designed to do. It is an emergent property rather than a preplanned one, indicating how rapidly new innovations and capability extensions flow into the app. Plasticity is primarily a function of (1) the modularization of an app's platform-facing interfaces into the ecosystem and (2) use of open standards within the app's microarchitecture where possible. The first attribute embeds flexibility in the form of real options within the app's microarchitecture, allowing it to evolve independently of the platform. An app developer can make changes within an app to extend its functionality without needing to coordinate with the platform owner. All it requires is compliance with the platform's interface standards and APIs to ensure interoperability. It also allows the app developer to rapidly exploit and integrate new innovations within the platform into the functionality offered by the app. The second attribute allows the app developer more flexibility to repartition the division of the four core functions in an app across the app and the platform. It also allows some of these functions to be moved entirely outside the ecosystem, for example, to exploit innovative external software-based services that did not exist at the time of the app's original creation. Therefore, app plasticity is driven primarily by app microarchitecture and secondarily by an alignment in the app developer's work with the platform's control dimension of governance.

11.7 Evolving an app in the long term

11.7.1 App envelopment: how apps evolve into platforms

Envelopment moves by apps provide a pathway for an app to evolve into a platform in its own right. Like platform envelopment, app envelopment can either span the turf of apps in adjacent markets (horizontal envelopment) or adjacent portions of the app's place in the platform value chain. These are illustrated in Figure 11.6.

FIGURE 11.6 Horizontal and vertical envelopment by an app.

11.7.1.1 Horizontal envelopment by apps

Horizontal envelopment involves incorporating the functions of another app or a standalone product or service experiencing technological convergence that is also widely used by an app's current end-users. (Tapping into a nonoverlapping pool of end-users is mutation.) This is a promising move only when the expanded app can deliver a stronger value proposition (lower cost, better capabilities) to the users of the enveloped target app by leveraging its existing capabilities or economies of scale. As in platform envelopment, there must be some overlap in the user base of the app and the envelopment target app. However, the enveloping app's existing users that overlap with the target app matter less than the nonoverlapping users in assessing the value proposition of the expanded app. Nevertheless, an app developer can expect a reciprocal envelopment attack. Therefore, horizontal envelopment attacks should only be attempted if the app's own assets leveraged in the target app's domain cannot readily be matched by the target app's developer. Examples of such assets include unique functional capabilities, large user base, or brand recognition.

The same strategies that platform owners use to spot horizontal envelopment opportunities, discussed in the previous chapter, can also be used by app developers. The more insights an app developer has into the mini-sized segments of the broader platform userbase, the more likely it is to recognize a horizontal envelopment opportunity. Recall that it is precisely this sort of contextual immersion that also helps bolster app stickiness and durability. Unlike platforms, an additional way in which apps can make such horizontal envelopment moves is by recognizing geographic or segment adjacencies (Zook and Allen, 2003). This involves creating an adaptation of the same app to new prospective end-users in different geographical areas or a previously unaddressed segment of the market (e.g., creating a French translation of an English app). This approach simply repeats the execution of an app's core business idea—which already has a solid foundation elsewhere—in adjacent markets.

Horizontal envelopment offers the first pathway for an app to begin growing into a platform. As the native functionality of an app expands and provided it is of value to other apps as well, app developers can begin providing access to it by introducing its own APIs. By following this strategy, an app can potentially evolve into an infrastructural component for other apps to build on (Messerschmitt and Szyperski, 2003, p. 200). Today's app can therefore become tomorrow's platform by executing a series of envelopment moves. Dropbox and Twitter did precisely this over time, growing into a nested “platform within a platform.” Similarly, Google has—with mixed success—slowly grown its Chrome browser into an ecosystem with its own apps, and then into a standalone operating system (Chrome OS). Skype also attempted to grow its service into a platform by adding a second side but had almost no success, largely because the two sides (end-users) did not have a compelling need for each other and the business model lacked compelling incentives to attract enough developers (i.e., the pricing dimension of governance was weak).

The key requirement for facilitating horizontal envelopment is governance, specifically that the app developer possess app strategic decision rights to a much greater degree than the platform owner. Horizontal app envelopment allows an app to either resegment its existing end-user base or to reach a pool of prospective end-users that is relatively new to the app (Figure 11.7). Horizontal envelopment therefore offers app developers an opportunity to grow an app's end-user base. The risk faced by an app developer in attempting horizontal envelopment moves increases as the overlap in the user base of the app and the target app shrinks.

FIGURE 11.7 Overlaps in user bases open up three types of markets to apps through horizontal envelopment.

11.7.1.2 Vertical envelopment by apps and on apps

Vertical envelopment involves selectively incorporating functionality originally provided by the platform into the app. Vertical envelopment primarily expands an app's functionality upstream in the platform's value chain. This will often put an app developer in direct competition with a platform owner. An app developer can expect a retaliatory downstream envelopment attack from the platform owner, especially if the app's functionality is of sufficient usefulness to other app developers in the platform's ecosystem. Vertical envelopment is therefore a second pathway for an app to evolve into a nested platform (a platform within a platform), especially when it either spans multiple nonrival platforms used by the same end-users (e.g., mobile and tethered operating systems) or multiple rival platforms (e.g., iOS, Android, and Blackberry).

11.7.1.3 Thwarting envelopment attacks by a platform owner

How does an app developer thwart an envelopment attack by a platform owner? We described several reasons that can compel a platform owner to justify such moves, but none of those reasons change the likelihood that it jeopardizes an app developer's survival. Although platform owners should ideally avoid invading their app developers' turf, it has historically happened often enough that app developers should take any promises with a grain of salt. An app developer facing a downstream envelopment attack by a platform owner often has little choice but to either sell out or quit the business. However, this no-win scenario can be avoided if an app developer plans ahead for it. How can an app developer safeguard against vertical envelopment of its app by a platform owner, which can otherwise instantly destroy an app developer's business? There are three ways to protect against downstream vertical envelopment by a platform owner. First, such an attack is less likely to happen if a platform owner cannot innovate in ways that an app developer can. Second, network effects that are unique to an app but that it does not share with the platform offer an additional protection against such threats. This protected Twitter from an envelopment attack from Apple, which instead chose to partner with it by creating deep hooks into iOS (thus exploiting Twitter's network effects to its own advantage). Third, an app developer can hedge against this risk by multihoming across multiple rival platforms. These three things were precisely what saved Dropbox when iOS enveloped its functionality with iCloud. It continually innovated in cloud storage technologies faster than Apple, had a network of end-users who valued strong network effects with their collaborators spanning a wide array of mobile and tethered platforms, and it multihomed extensively.

11.7.1.4 A bold retreat as an alternative to quitting

When it is not possible to thwart an envelopment attack by a platform owner—often the case—the next best bet is to pursue what Adner and Snow, (2010) calls a bold retreat. An app developer can engage in a bold retreat by retrenching to a niche of the existing market where it has an advantage over the platform owner in addressing end-user needs (Adner and Snow, 2010). This can sometimes be more effective than fighting a losing battle or quitting the market altogether. This allows an app developer to pursue a less vulnerable, sustainable niche. Adner (2010) showed how effectively this strategy worked for dot matrix printers with the advent of lasers, mechanical watches with the advent of quartz watches, and calculators with the advent of PCs. The questions to assess the viability of a bold retreat are:

• What elements or valued attributes of your app does the post-envelopment platform leave unaddressed?

• Which of the platform's (not the app's) end-users care about these attributes?

• If you focused on this segment of end-users, would that result in a sustainable business?

• How would product and pricing have to change? Sometimes, increasing pricing becomes viable after a bold retreat. For example, the average price of a new, well-engineered mechanical watch increased after the advent of quartz watches. Similarly, the prices of fountain pens increased about tenfold after ballpoint pens largely replaced them in the 1960s.

• How would your pool of rivals be different after a bold retreat? Remember that smaller niches can support fewer competitors, so early moves are important.

11.7.2 Enhancing app durability

An app's durability is its capacity to survive in the face of rival apps in a platform ecosystem. Like for platforms, we are more interested in changes—increases and decreases—in app durability over time. An app's durability is always relative to rival apps within the same platform. A brilliant idea can put an app on the map, but only unrelentless evolution keeps you there. An app will endure only if it continues to provide a stronger value proposition to its end-users relative to rival apps. The resource litmus test of value, rarity, inimitability, and nonsubstitutability again provides a simple but powerful framework to assess app durability. An app initially gains traction if it provides its end-users the ability to accomplish tasks that are valuable but that they cannot accomplish using other apps or the platform's native functionality (i.e., it is rare). But to sustain this initial advantage, such functionality must also be hard for rival apps to copy (the inimitability criterion) and have no readily available substitutes (the nonsubstitutability criterion). An app that continues to meet the inimitability and nonsubstitutability criteria can viably command a price premia, which the market will bear. (Such price premia need not be money charged directly to end-users and can instead be charged to a third side of the market such as advertisers.) An app's initial advantage is often short-lived because imitation by rival apps replicates valuable technological features and destroys their rarity. The app developer must then resort to the same strategies that platform owners use to bolster platform durability: (1) adding valuable new functionality faster than rival apps and (2) accumulating nonsubstitutable assets such as app-specific network effects that are independent of the platform. The techniques described in the preceding discussion on app plasticity to identify valuable new functionality to add to an app directly contribute to enhancing app durability as well.

However, apps are not victimized by architectural decay with age to the same extent as platforms. Unlike a platform that cannot be scrapped and rebuilt due to ecosystem-wide dependencies, an app can be. Nevertheless, app developers must remain cognizant that as a platform ages, platform owners are more likely to grow more controlling and intrusive in how an app is implemented. (As explained in the previous chapter, this is often motivated by the architectural decay that accompanies an aging platform.) Apps are also less constrained than a platform in their ability to build on new generations of technology and software services from outside the ecosystem. Being able to build on these can make an app more valuable to the platform, as it can compensate for the platform's own weaknesses.

11.7.2.1 Tempering expectations

App developers must, however, shape their expectations of how widely an app will be adopted and the profit margins that they can expect the market to bear. This depends primarily on whether the app's end-users: (1) strongly value network effects in how they use the app and (2) whether their needs are relatively homogenous. If both these conditions are simultaneously met, the app's market will be a winner-takes-most market and one (or few) apps will dominate its category. If even one of these conditions is not met, multiple rival apps will continue to coexist. Unfortunately, this is exactly the kind of market where competition between undifferentiated apps becomes a race to the bottom in terms of pricing. Even when an app is in a market without winner-takes-most dynamics, an app developer can expand an app's installed base by creating multiple variants of an app targeting distinct user segments, as described earlier in this chapter.

11.7.3 Orchestrating app mutation

Unlike envelopment, which expands an app's functionality, app mutation creates a distinct derivative app in a different application domain and does not require an overlap in end-users across the existing and mutation target markets. It involves replicating your app's strongest strategic advantage in new markets, contexts, and applications (Courtney, 2001, p. 43). Each mutation move opens up further possibilities of new niches to mutate into. In a real options sense, mutation therefore creates growth options for an app. Just as species can break out of extinction by diversifying, apps can break out of the bloodiest Red Queen races in zero-profit markets by diversifying into different markets where their existing assets give them some advantage.

An app developer must first use the resource litmus test to compare how it would fare using its existing assets against rivals in mutation target markets. Mutation does not require carryover of existing end-users of an app into the new market, although carryover can potentially be valuable where it is viable. Opportunities for app mutation arise primarily from the convergence of previously separate streams of technology. For example, Skype tried but failed to grow into a platform. Yet it managed to successfully mutate into smart televisions (TVs with built-in Internet connectivity using a hardware-embedded version of the app) and use them as a platform to gain a promising position in a completely different market. It also successfully used a carryover strategy, albeit into a small but growing market of smart television owners.

Unlike platform owners who can use app developers as their eyes and ears for spotting mutation opportunities, app developers are on their own. To identify opportunities for mutation, an app developer must look outside its existing markets. The focus should be on identifying either less crowded markets or emerging market domains. The key enabler for platform mutation is governance, particularly the possession of app strategic decision rights by the app developer. The governance structures that enhance app composability and durability are also conducive to app mutation. It also requires a modularized app microarchitecture that can readily be split from the platform and reimplemented if the mutation target is completely outside the original platform ecosystem (as it was in Skype's case).

11.8 Lessons learned

• App markets are hit-driven markets. A miniscule number of apps become blockbusters, which encourages more rival entrants. Unlike movie and book markets, entry of rival apps usually expands the pie of the nascent market for everyone.

• Blockbuster apps often begin with a Eureka moment. Firsthand insights into real problems, frustrations, and irritations that come only from deep immersion in an app's usage context usually spark an idea that becomes an app.

• Most apps in nascent markets fail to recognize their real competition. It is usually not the obvious competitors. Dropbox's was cheap thumb drives, Palm's was paper organizers. Failure to get this reference point right results in overengineering the wrong solutions.

• Similar apps in the same platform can vary considerably in their architectural properties. These are shaped by two choices made by app developers: compliance with a platform's interface standards and choice of an app's internal microarchitecture.

• An app's microarchitecture shapes its evolvability. An app's microarchitecture has consequences for what an app builds on its own and what it leverages from the platform. It also affects an app's resilience, scalability, processing requirements, and network dependence.

• Managing app resilience, scalability, and composability. In the short term, app microarchitecture shapes its resilience; microarchitecture and microarchitecture–governance alignment influences its scalability and composability.

• Enhancing app stickiness, synergy, and plasticity. In the medium term, app stickiness, synergy, and plasticity are shaped by an app's microarchitecture–governance alignment.

• Orchestrating app envelopment, durability, and mutation. In the long term, envelopment as well as its capacity to rebuff envelopment attacks is influenced by app governance, app durability by an app's microarchitecture–governance alignment, and app durability by app microarchitecture and app governance.

The next chapter recaps the core ideas developed in this book and previews the road ahead for nonplatform product and service businesses as they see their own industries acquire platform-like properties.

References

1. Adner R, Snow D. Bold retreat. Harv Bus Rev. 2010;88(March):1–7.

2. Agarwal R, Bayus B. The market evolution and sales takeoff of product innovations. Manag Sci. 2002;48(8):1024–1041.

3. Arthur B. The Nature of Technology. New York: Free Press; 2009.

4. Baldwin C, Clark K. Design Rules: The Power of Modularity. Cambridge, MA: MIT Press; 2000.

5. Baldwin C, von Hippel E. Modeling a paradigm shift: from producer innovation to user and open collaborative innovation. Organ Sci. 2011;22(6):1399–1417.

6. Courtney H. 20/20 Foresight. Boston: Harvard; 2001.

7. de Weck O, Roos D, Magee C. Engineering Systems. Cambridge, MA: MIT Press; 2011.

8. Economist. Make your own angry birds. Economist 2012a;(July 21):55.

9. Economist. Outsourcing is so last year. Economist 2012b; www.economist.com/blogs/babbage/2012/05/future-customer-support; (accessed 12/6/2012).

10. Eisenmann T, Parker G, Van Alstyne M. Platform envelopment. Strateg Manag J. 2011;32(12):1270–1285.

11. Ethiraj S, Levinthal D. Bounded rationality and the search for organizational architecture: an evolutionary perspective on the design of organizations and their evolvability. Adm Sci Q. 2004a;49(3):404–437.

12. Ethiraj S, Levinthal D. Modularity and innovation in complex systems. Manag Sci. 2004b;50(2):159–173.

13. MacCormack A, Rusnak J, Baldwin C. Exploring the structure of complex software designs: an empirical study of open source and proprietary code. Manag Sci. 2006;52(7):1015–1030.

14. Messerschmitt D, Szyperski C. Software Ecosystem. Cambridge, MA: MIT Press; 2003.

15. Rohfls J. Bandwagon Effects in High-Technology Industries. Cambridge, MA: MIT Press; 2003.

16. Sanchez R. Strategic flexibility in product competition. Strateg Manag J. 1995;16:135–159.

17. Simon H. Near decomposability and the speed of evolution. Ind Corp Change. 2002;11(3):587–599.

18. Strietfeld D. As boom lures app creators, tough part is making a living. New York Times 2012; In: www.nytimes.com/2012/11/18/business/as-boom-lures-app-creators-tough-part-is-making-a-living.html.

19. von Hippel E. Lead users: a source of novel product concepts. Manag Sci. 1986;32(7):791–805.

20. von Hippel E. Sources of Innovation. Cambridge, MA: MIT Press; 1988.

21. Zook C, Allen J. Growth outside the core. Harv Bus Rev. 2003;81(December):2–9.