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

Part III. Dynamics and Metrics of Ecosystem Evolution

Chapter 8. Real Options Thinking in Ecosystem Evolution

Abstract

This chapter describes real options thinking as a tool to designing and exercising the six different types of real options, primarily by platform owners but, to a lesser extent, also by app developers. The architecture of platforms and the microarchitecture of app embeds can create different types of flexibility to adapt to volatility in technology and in end-user needs. When the design of a project creates such future flexibility without the obligation to use it, it is said to have a real option embedded in it.

Keywords

real options; flexibility; agility; embedded options; options framework; business ecosystems

The menu is huge, sophisticated, and very creative but I keep to simple choices.

Jean Reno

In This Chapter

• An introduction to real options as a way of thinking

• Coping with technology and market volatility in platform projects

• Six types of real options

• Applying real options thinking in practice

• Exercising real options

The architecture of platforms and the microarchitecture of an app can create different types of flexibility to adapt to volatility in technology and in end-user needs. When the design of a project creates such future flexibility without the obligation to use it, it is said to have a real option embedded in it. The value of such flexibility is greater when a project involves more volatility in either the technology or the market needs addressed by the project. This chapter describes real options thinking as a tool for designing and exploiting the six different types of real options, primarily by platform owners and to a lesser extent by app developers.

8.1 An introduction to real options thinking

Real options are a way of thinking that disciplines how projects—both platforms and apps—can be structured to protect against potential losses while preserving potential gains. It is an approach to position for the upside by hedging against possible futures. A real “option” is simply the right to do something without the obligation to do it (Trigeorgis, 1993). It refers to the flexibility to do something along a project’s evolutionary trajectory—grow, scale, switch ingredients, stage expansion, or kill a project—in the future without having to do it. When the flexibility specific to any type of real option is present in a project, that real option is said to be embedded in it (Bollen, 1999; Hilhorst et al., 2008; Huchzermeier and Loch, 2001). Although traditional approaches to strategy are often seen as an answer to uncertainty and dynamic markets, they are based on an assumption of predictability in the environment. Real options thinking, in contrast, is based on the assumption of uncertainty and unpredictability, which is precisely the kind of environment where the flexibility provided by real options is valuable. The value of embedding real options in a platform project lies in the future flexibility to defer, expand/contract, repurpose, or terminate projects, without the obligation to do so. Often, this flexibility relates to when and how to implement specific features and functionality. Thinking in terms of creating real options allows firms to prepare today for an unpredictable future.

8.2 Volatility in technologies and markets

Generally, the greater the variance—or volatility—involved in a project, the more valuable is any real option. Real options therefore tend to be most valuable as well as more plentiful in fast-moving, unpredictable markets and in large, complex projects with greater disparity between the upside and downside outcomes (Fichman et al., 2005). The flexibility provided by embedded real options is valuable under two conditions: (1) greater technical and market (e.g., how end-users will respond) volatility and (2) how long an option can be held before the flexibility provided by it disappears (known as an option’s expiration period). By corollary, options are of lesser value in predictable markets and when platform projects use stable technologies and have short development timelines.Figure 8.1 summarizes the key sources of technical and market volatility. Technical volatility is largely an uncertainty on the supply side of a platform and market volatility is largely on the demand side of a platform.

FIGURE 8.1 Two types of volatility and their sources.

8.2.1 Technical volatility

Technical volatility arises from the immaturity of technology, unpredictability of how it will evolve, the need for integrating a system with other existing systems within and outside a platform ecosystem, and a platform project’s sheer complexity. Such technical volatility is reduced only through small-scale, tip-toeing investments (McGrath, 1997); by cautiously “doing something,” unlike market volatility, which is reduced simply by waiting (if the risk of being preemptively locked out of a market by potential rival platforms is low). The greater the technical volatility involved in a platform project, the greater is the value of flexibility created through options thinking.

8.2.2 Market volatility

Market volatility arises from not knowing how potential end-users will respond to a project, how fast they will adopt it, and whether rival platforms will quickly replicate to match the features and capabilities introduced by the project. Market volatility also arises from attempting to target a market where the needs of users are diverse (both end-users and app developers are a platform’s users). The value of a real option is low when consumer preferences are homogeneous and predictable and high when they are heterogeneous and unpredictable (Adner and Levinthal, 2001). The latter is likely to be the case in the early lifecycles stages of a platform where users are diverse and it is unclear what functionality they will value more. This means that any project targeting a group with heterogeneous needs will have to make compromises in what it can and cannot offer to its average user. Real options simply provide a way to reverse those choices if they turn out to be wrong. Although the volatility of new markets is greater than established markets, real options have much greater value in such markets (McGrath, 1997). Therefore, real options are more useful in new platform markets than in well-established ones. A final source of market volatility is from uncertainty about whether and when critical complements such as apps will arrive. If a platform project introduces functionality that is of limited appeal without the arrival of complementary apps that make it useful in practice, it can be a death knell for the platform. This is precisely why Blackberry drummed up new apps for its Blackberry 10 platform long before its public release in 2013. (It guaranteed minimum payouts of $10,000 to each app developer for its new platform.)

Expiration period of a real option refers to the time remaining during which the option can be exercised after it is created. This means that the longer the development schedule of a project, the more valuable it is to embed real options in it. Such projects should also have the shorter gaps between periodic project reviews and smaller stages. The expiration period of a real option also depends on the length of the product lifecycle in the platform’s market, its stage along the S-curve, and the intensity of competition in its core market (e.g., number of rivals and prevalence of race-to-the-bottom pricing).

Besides technical and market uncertainty, three additional sources of uncertainty influence the value of real options in platform projects because they alter the volatility surrounding them (McGrath, 1997).

• Feature matching by rival platforms. A greater likelihood of feature matching retaliation by rival platforms reduces the value of real options. In contrast, uncertainty about whether a rival platform will move to match a new feature added to a platform increases its volatility, in turn increasing the value of real options.

• Blocking-related uncertainty. If rival platforms or complementary services (such as external APIs) block access to the project, it reduces the variance in returns, therefore reducing the value of real options.

• Slow adoption. Slow adoption by app developers or end-users reduces the variance in cumulative returns, therefore reducing the value of a real option embedded in a platform project.

Risks can be managed proactively using options thinking only if the platform owner plans for such uncertainties in advance. The emphasis should be on recognizing upfront the key technical and market uncertainties inherent in a new project. Each of these key uncertainties can then be approximately classified into four levels, illustrated in Figure 8.2 (Courtney, 2001, p. 22); real options thinking is most useful at levels 2 and 3.

• Level 1. A clear trajectory and predictable view of the future exists for the focal volatility. At this level, traditional strategic planning techniques work well and investments to create flexibility and diversification solely to manage risk are wasteful (Courtney, 2001, p. 103). Real options thinking has little value at this level.

• Level 2. A limited set of possible outcomes can be readily identified on a contingent roadmap, one of which will occur. For example, two different dominant designs for a platform or two competing standards (e.g., Flash vs. HTML 5) might exist, one of which will prevail. Real options selectively embedded in a project begin to become valuable. In the preceding example, a switch use option would be key. Scenario planning techniques that actively track the relative probabilities of each evolutionary path are useful complements to real options thinking at this level.

• Level 3. A range of possible outcomes can be identified, but there is considerable ambiguity within that range. At this level, real options thinking becomes most useful. It is also necessary to actively track the changes in the key technical and market uncertainties to update the value of embedded options and to determine the timing of exercising the flexibility associated with them.

• Level 4. True ambiguity where not even a range of possible outcomes can be predicted. Real options thinking has limited usefulness at this highest level of uncertainty. Reversibility of decisions in the form of embedded abandonment and switching options, and some ability to insure against worst-case scenarios, is valuable at this level (Courtney, 2001, p. 103).

FIGURE 8.2 Four levels of technical and market volatility.

The simplified options exercise framework described in Figure 8.5 is immediately applicable for creating, holding, and exercising possible real options in a project. Such tracking not only requires actively monitoring the sources of key uncertainties but also small-scale experiments that can generate new information to reduce ambiguity. Other tools such as latent demand discovery of user needs using methods such as conjoint experiments (discussed in Chapter 11) can therefore also be useful. Such experiments with app developers and end-users can allow an app developer or a platform owner to develop preliminary hypotheses about functionality that they would likely value and then confirm or disconfirm such hypotheses. This approach allows iterative refinement and narrowing down of the range of possible outcomes, effectively reducing uncertainty to Level 2 in Figure 8.2.

8.3 Types of real options

Real options can either be strategic or operational, as shown in Figure 8.3. Table 8.1 summarizes the six types of real options that can be embedded in a platform project and how each can create value. A strategic option (also known as a growth option) refers to future flexibility to use the project as a foundation or stepping-stone for yet-unimagined follow-on projects through further investment. Strategic options are obvious in hindsight but usually challenging to foresee. Operational options relate to the operational implementation of a project and consist of five types:

1. Defer. This option is embedded in a project if it can be delayed without missing a market opportunity. The key requirement is that the upside opportunity must not be imperiled by delaying the project and the risk of preemption or lockout must be minimal. The presence of a defer option allows market volatility to be resolved by allowing the developer to delay implementing functionality whose value to a platform’s or app’s primary users is not yet clear. The presence of a deferral option is the key mechanism for reducing market volatility. A deferral option embedded in a platform project therefore provides a way to cope with volatility by providing an opportunity to delay an investment decision with uncertain future value until the uncertainty has been resolved or reduced. The pitfall associated with defer options is the risk of a false illusion that a project can be deferred without imperiling its potential. In reality, the creation of network effects by a rival and the initiation of the Red Queen effect can cause a project to fall irrecoverably behind. Recall that network effects can protect early movers because end-users’ willingness to adopt a network effects-dependent system is a function of the number of existing users.

2. Stage. This option exists if the project can be implemented in sequential stages, where the functionality in each stage can be implemented independent of subsequent stages. The new information generated in each stage allows a better assessment of the value of proceeding to the next stage. Embedding a staging option is one of the most powerful ways to apply options thinking in platform markets, beginning with a minimalist project footprint and progressively expanding it.

3. Scale. A scale option is embedded in a project if it can be scaled up without increasing a system’s complexity or scaled down without compromising its viability. The scaling option therefore captures both the flexibility to expand and contract the scale of a project. As described subsequently, the option to scale up is embedded in architectural choices and the option to scale down is closely related to choice of business models and governance. The scale-down option is a milder form of the abandonment option.

4. Switch. The switch option is embedded in a project if it has the flexibility to either be switched to a different use than the one it is designed for or if a key foundational technology used in it can be swapped out for another one. In software systems, switching use rarely requires discontinuing the original application due to low reproduction costs for software. This is valuable when a project is better used in a different application domain than the one for which it was intended, or if a selected building block technology proves less robust than an alternative that subsequently emerged. This option provides a springboard to envelopment and mutation of apps and platforms.

5. Abandon. A project carries an abandonment option if it can be terminated midstream and the freed-up resources can be salvaged and redeployed for a different project. In theory, any project can be abandoned. But in practice, sunk costs, morale damage, and the desire to save face can make it impossible to terminate projects that are on a failing course. The abandonment option can most readily be embedded in a project by (1) setting upfront explicit and clear exit criteria and (2) separating the authority to pull the plug from those directly involved in a project.

FIGURE 8.3 Six types of real options.

Table 8.1

Spotting Embedded Real Options and Their Sources of Value

Multiple real options can simultaneously be embedded into a project, some naturally but more through deliberate design. The level of flexibility in implementing a platform is not preordained but deliberately designed into its initial design and architecture. For example, staging options can be embedded by carefully structuring a larger platform project into smaller, staged subprojects that cumulatively build on each other. Switch use options can be embedded by internally modularizing a core technology component in a platform or app that could later be swapped out with a rival one. It is through this process of deliberate design and restructuring at the outset of a project that real options are embedded.

8.4 Applying real options thinking in practice

The tactic for applying real options thinking in practice is to decompose a project in a series of sequential subprojects. This requires first decomposing a larger project into smaller, shorter subprojects and then sequencing them using options thinking. Consider an example of a system for collaborative file synchronization (such as Dropbox), as illustrated in Figure 8.4. For simplicity, assume that the project has three intended pieces of functionality: (1) file synchronization, (2) text message notifications of file changes, and (3) social networking capabilities. For simplicity, let’s assume that the project would take three months of development effort and the expected payoff of the project is $3 million, equally attributable to the three pieces of functionality. The traditional big-bang approach to software development would treat it in a monolithic fashion, as illustrated on the left-hand side of Figure 8.4. If all goes well, the project would be completed on schedule and would realize its payoff at the end of the third month, when the project goes live. However, this assumes that its users’ needs would remain stable over that time and that no glitch or technical challenge will appear. Such monolithic implementations also tend to incorporate rigid assumptions about users and user needs. If the development team runs into an insurmountable technical problem or if user needs turn out to be different from what the project team had assumed, say in the second month, the project can stall and realized payoff would be zero. Put another way, there is not much to show for the $2 million already spent.

FIGURE 8.4 A project (A) without embedded options and (B) decomposed to embed real options.

Embedding real options in the same project requires decomposing the project into smaller subprojects and then appropriately sequencing their implementation. Consider the same example, but broken down into three subprojects: A (file synching), B (text notifications), and C (social networking capabilities). This provides two advantages. First, if something goes awry after stage A is completed but stage B is in progress, there will be some return to show, as shown in the shaded area on the right-hand side of Figure 8.4, even if stage B is never completed. This payoff would have been forfeited if the project were not decomposed. Second, new information might be generated at the end of stage A that might reduce the uncertainty about whether proceeding to stage B is likely to be worthwhile. The staged nature of investments lowers downside risk, which is capped at the money already invested in the ongoing stage. However, the upside remains open because the decision to invest in further stages can be made after the completion of one stage generates new information about the prospects of the subsequent stages. Such information generated at the end of each subproject would not be available if the project had not been decomposed.

The decomposed version of the project therefore separates calculated risks from foolish risks, disciplines investment decisions, and safeguards against misreading the writing on the wall. It contrasts starkly with the big bets approach, which are riskier in the presence of volatility.

Therefore, in the presence of volatility, a project with embedded real options is more valuable than one without them.

8.4.1 Decomposing a project into smaller subprojects

There are two possible ways to decompose a project into standalone stages (Fichman and Moses, 1999): (1) successive stages involve the same systems but with additional detail and features added to them (akin to adding layers of paint on a canvas, called canvas painting incrementalism) or (2) successive stages involve functionality that was intentionally excluded from preceding stages (akin to adding slices to a pie, called pie slice incrementalism). We recommend the second approach, which is more conducive to applying real options thinking to platform evolution. However, for the advantages of project decomposition to be realized, both decomposition and the sequencing of stages require forethought. The decomposition must follow three simple rules of thumb:

1. Separate must-do and may-do elements. The first step to begin applying options thinking is to distinguish what a project must do and what it may do. The must-do element is a project’s “minimum viable footprint,” or minimal baseline functionality that it must deliver (Adner, 2012, p. 194). For things that a project must do, there is no flexibility by definition, thus no option value. Think of the leanest configuration of functionality that can be implemented to create a distinct, functioning platform (or app), focusing on its distinctive feature set and nothing more. This allows you to begin by tackling the subset of problems that you are currently in the best position to solve, and enables cheaper and faster iterations. The must-do and may-do elements of the larger project must first be clearly separated. All options are embedded in the may-do elements of a project, where value can be created by structuring these may-do elements as options. To identify the may-do elements, think of which additional elements can be added on top of the must-do elements so that each new may-do element cumulatively benefits from the preceding stages.
Increasing the may-do to must-do ratio expands opportunities for embedding real options in a project by increasing the number of stages. The must-do subproject creates the flexibility without the obligation to proceed to the next stage. Its outcomes generate new information about the true value of proceeding to the first may-do subproject, which is appropriate given the milestone-driven, iterative management processes that underlie real options thinking. This approach also curbs scope creep and overengineering of solutions by keeping the implementation focused on a few key attributes that the completed project must deliver at each stage (Fichman and Moses, 1999). Overengineering otherwise produces a proliferation of complexity (Fichman and Moses, 1999).

2. Segregate by volatility. Segregate functions with the least technical and market volatility into a different stage from those with the greatest volatility.

3. Each stage must be discrete with a measurable value proposition. Each stage must deliver clear measurable benefits even if no further stages (the may-dos) are ever completed (Fichman and Moses, 1999). Each increment must implement everything required to produce the desired results for that subproject, and must be doable in a relatively short timeframe.

8.4.2 Sequencing subprojects

The may-do stages must be cleverly sequenced to maximize the potential for extracting value from embedded real options. Sequencing stages follow three additional rules of thumb:

1. The planned functionality implemented in any stage should not be dependent on later stages. Each stage must produce a distinct outcome that is not dependent on the subsequent stages. In other words, each stage must provide a standalone value proposition. Later stages can, however, cumulatively build on the outcomes of preceding stages. This ensures that each stage is cumulative such that accomplishments from each stage feed into and provide foundations for the subsequent stages.

2. Sequence the lowest uncertainty stages first and highest uncertainty stages last. Schedule stages with the greatest uncertainty as late as possible in the overall project roadmap. The must-do elements must focus on opportunities with the least technical uncertainty and the highest immediate payoff, ensuring that the stream of benefits will begin accruing earlier rather than later. However, defer functionality to a later stage only if there is no clear first-mover advantage (i.e., the upside opportunity is not imperiled by delaying it and there is no realistic danger of preemption or lockout from the market due to rivals). This approach can reduce challenges in subsequent stages by generating new information during the implementation of the preceding stages. Even if some later stages are never implemented, some payoff is generated from what is feasible instead of pursuing an all-or-nothing proposition.

3. Sequence stages with the most cumulative learning first. Start with a set of features where conditions are most favorable to success and where learning is most cumulative (i.e., lays the foundation for the subsequent stages). Resolving uncertainty should be dependent on the direct experience that can be gained through learning-by-doing in the earlier stages. The upside is that uncertainty about later stages can potentially be decreased by new information generated during each stage, allowing a more informed decision about whether to proceed to the next stage.

This decomposed sequencing approach sounds logical in theory, but is challenging in practice because of a penchant for an all-at-once mindset prevalent in software projects (Fichman and Moses, 1999). Furthermore, the project must also be technologically divisible into stages, which has a lot to do with the choice of its architecture.

8.5 Exercising real options: the devil is in the details

Recognizing and embedding flexibility in a project in the form of real options is only half the story. Such flexibility is not of much value unless it is exercised appropriately, which is where its value is extracted. This requires recognizing when to exercise the flexibility, when to keep it in the back pocket, and when to ditch each embedded option.

The simplified options exercise framework in Figure 8.5 provides a simple way to make such decisions (Courtney, 2001, p. 143). On the y-axis is the volatility involved in a project, which can be technical or market volatility. Embedding a real option in a project often has a direct cost and some value. On the x-axis is the ratio of value to cost for a specific real option. This ratio is 1 when value and costs are equal; greater than 1 when value exceeds cost; and less than 1 when cost exceeds value.

FIGURE 8.5 A simplified real options exercise framework.

8.5.1 Cost of an option

There is no free lunch because creating options in a project incurs both direct costs and opportunity costs. Embedding real options can therefore add to the initial development cost. Direct costs are the costs of additional development work that is needed to embed various flexibilities in the design of the project. Opportunity costs are the costs of not being able to do something else (e.g., implementing a feature) because of the time and effort expended on creating that flexibility. Creating such flexibility often requires upfront investments such as restructuring or decomposing a project into stages or designing it to allow for swapping out one ingredient technology with another. You must weigh the potential loss of fleeting opportunities because embedding a real option can also add to the development time. This is the cost of embedding that option, the loss if that option is not subsequently exercised. The cost of embedding an option is usually the same, no matter what the level of volatility surrounding the project.

8.5.2 Value of an option

The value of a real option, unlike cost, is a lot harder to estimate. Various methods, including partial differential equations, dynamic programming, and simulations, have been developed to estimate the value of options. However, research is ongoing and these techniques are typically beyond the grasp of most other than a few specialists who can read research papers written mostly in Greek symbols! In fact, Professors Black and Sholes won the 1997 Nobel Prize for their attempt to solve the options valuation problem. However, applying real options thinking in practice does not require acquiring arcane academic skills to value real options.

8.5.3 Exercising an embedded option: when to hold and when to fold

The simple question to ask is whether—given the known cost of embedding a specific real option in the design of a project—its value is likely to exceed its cost. If not, the option falls in the left half of Figure 8.4. Here, if volatility is low, it falls in the ditch region (D) of the framework. Such options are not worth investing in creating and if they are already present in a project, they are safe to ditch. A flexible design is valuable only in the presence of volatility but is suboptimal when volatility is absent. An inflexible design optimized to a particular set of stable circumstances can often outperform a flexible one when volatility is absent. Because embedding a real option such as switching use or inputs in the initial design of a project costs real money, when volatility is low or expiration time short, the cost of creating the option can exceed its potential value. However, if the volatility associated with the option is very high, it falls in the hold region (H) of the framework. Such options are worth holding on to if they are already present in a project, and worth investing in creating if the project is new. As volatility declines, it shifts to the exercise region (E) in the framework. Such options should immediately be exercised to extract their value. Poorly timing the exercise of an option can wipe out its potential value.

This simple options exercise framework emphasizes that the changes in volatility associated with an option are the key factor that can shift it from the hold (H) to ditch (D) or exercise (E) regions in the framework. Volatility is a simplified representation of reality and is based on assumptions help by the system’s designers. Like any subjective representation based on assumptions, it should evolve over time. Therefore, volatility is a dynamic rather than a static attribute. Active tracking and constant monitoring of the key volatility and proactively monitoring unfolding trends associated with each embedded real option is therefore key to realizing their value. This also requires frequently testing and updating assumptions about the core technologies and adopters of a platform. In software-based platforms, such data can often be gleaned inexpensively from usage patterns and metrics. What cannot be predicted can also often be gleaned through small-scale experiments with feature tweaks (e.g., users find one interface option easier to use than another). But such information is of value only if the new information they generate is acted on and used to update volatility estimates used in real options thinking.

The common traps in failing to recognize when to exercise the flexibility provided by an embedded real option include the lack of diverse inputs from multiple project stakeholders, looking only at existing end-user and app-developer pools while neglecting prospective new ones, and basing decisions on a static project roadmap rather than one that is a living document.

8.6 Lessons learned

• Real options discipline imagination. Real options thinking disciplines projects to safeguard against potential losses while preserving their upside potential.

• Real options are more valuable under uncertainty. Uncertainty can be in either the technology or the market needs addressed by a platform or app project.

• Real options are of six types. Real options embedded in a project provide the flexibility to use a project as a foundation for strategic growth, defer, stage investments, change scale, switch its components or purpose, or abandon it.

• Staging is the most common real option. This requires decomposing a project into must-do and may-do elements, and then implementing them in an options-driven sequence. Real options thinking guides both the decomposition and sequencing of such subprojects.

• Timed exercise extracts real option value. Embedded real options must be exercised using a simple options exercise framework, described in this chapter.

The next chapter delves into five discrete operations called modular operators that can be performed on a platform or an app, and within the ecosystem to evolve it using real options thinking. These modular operators provide the language to precisely describe evolution in platform ecosystems.

References

1. Adner R. The Wide Lens. New York: Portfolio; 2012.

2. Adner R, Levinthal D. Demand heterogeneity and technology evolution: implications for product and process innovation. Manag Sci. 2001;47(5):611–628.

3. Bollen N. Real options and product life cycles. Manage Sci. 1999;45(5):670–684.

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

5. Fichman R, Keil M, Tiwana A. Beyond valuation: real options thinking in IT project management. Calif Manage Rev. 2005;47(2):74–96.

6. Fichman R, Moses S. An incremental process for software implementation. Sloan Manage Rev (Winter). 1999;39–52.

7. Hilhorst C, Ribbers P, van Heck E, Smits M. Using Dempster-Shafer theory and real options theory to assess competing strategies for implementing IT infrastructures: a case study. Decis Support Syst. 2008;46(1):344–355.

8. Huchzermeier A, Loch CH. Project management under risk: using the real options approach to evaluate flexibility in R&D. Manage Sci. 2001;47(1):85–101.

9. McGrath R. A real options logic for initiating technology positioning investments. Acad Manage Rev. 1997;22(4):974–996.

10. Trigeorgis L. The nature of option interactions and the valuation of investments with multiple real options. J Financ Quant Anal. 1993;28(1):1–20.