Document Sample
ccr-functionalities Powered By Docstoc
					       Functionality-rich Versus Minimalist Platforms:
               A Two-sided Market Analysis                                                     ∗

            Soumya Sen†                             Roch Guérin                         Kartik Hosanagar
       EE, Princeton University                 ESE, U.Pennsylvania                   Wharton, U.Pennsylvania                 

ABSTRACT                                                         adapt to new technologies and foster the creation of
Should a new “platform” target a functionality-rich              a wealth of applications. However, as it matures and
but complex and expensive design or instead opt for              transforms from a “physical” network platform to a
a bare-bone but cheaper one? This is a fundamental               broader ecosystem of software and services, the ques-
question with profound implications for the eventual             tion of whether or not to abandon this minimalist
success of any platform. A general answer is, however,           principle is increasingly raised [18, 7, 28]. Answering it
elusive as it involves a complex trade-off between ben-           is non-trivial, especially given the lack of a systematic
efits and costs. The intent of this paper is to introduce         framework for identifying and evaluating the under-
an approach based on standard tools from the field of             lying design trade-offs. The paper does not claim an
economics, which can offer some insight into this dif-            answer to this complex and multi-faceted question.
ficult question. We demonstrate its applicability by              Instead, our aim is to highlight the availability and
developing and solving a generic model that incorpo-             relevance of tools and methodologies from the field of
rates key interactions between platform stakeholders.            economics to explore this complex issue. In support
The solution confirms that the “optimal” number of                of this claim, we offer an initial quantitative step and
features a platform should offer strongly depends on              illustrate through partial and preliminary results the
variations in cost factors. More interestingly, it reveals       kind of insight it can yield.
a high sensitivity to small relative changes in those               In general, a platform’s success is based on its abil-
costs. The paper’s contribution and motivation are in            ity to “connect” consumers of applications and ser-
establishing the potential of such a cross-disciplinary          vices to developers of those applications and services.
approach for providing qualitative and quantitative              The platform entices developers to join by providing
insights into the complex question of platform design.           access to functionality through built-in APIs, mod-
                                                                 ules, tools, etc., which make it easier to innovate new
                                                                 applications and services of interest to consumers. The
Categories and Subject Descriptors                               platform (development) costs, however, grow with the
C.4 [ Performance of Systems]: Design Studies;                   richness of the functionality it offers. The main ques-
K.6 [ Management of Computing and Informa-                       tion faced by a platform provider is, therefore, to de-
tion Systems]: Economics                                         cide what level of functionality to offer, or in other
                                                                 words how many “features” to include in the plat-
General Terms                                                    form1 so as to maximize its own profit.
                                                                    A minimalist platform has a low cost but makes
Design, performance                                              developing services and applications more complex,
                                                                 which limits the number of application developed for
Keywords                                                         it. This makes the platform less attractive to con-
Platforms, two-sided markets, economics of networks              sumers and lowers revenues. Conversely, a feature-rich
                                                                 platform is expensive to build, but this cost may be
                                                                 offset by facilitating the development of more appli-
1.   INTRODUCTION                                                cations, therefore attracting more consumers. Hence,
   Communication platforms from the Internet to so-              developing tools to explore this trade-off is of interest
cial networks (e.g., Facebook, Twitter), as well as a            to platform providers2 . In the rest of this paper, we
plethora of computing platforms from personal com-               demonstrate how a two-sided market [24] formulation
puting (e.g., Windows, Apple OSX, Linux), to mo-                 can be used to investigate the problem. The platform
bile devices (e.g., Android, iOS, Symbian), to cloud             is the ‘market’ and consumers and developers are the
computing solutions (e.g., Google, Amazon, Microsoft             ‘two sides’ of the market.
Azure), are emerging as the main drivers of our digital             The investigation illustrates how a two-sided market
economy. Together with this emergence often comes a              model can capture the decision problem of a platform
period of transformation during which platforms face             provider. It also affords initial insight that provides
major design decisions that affect their future success           some credibility that the approach holds promises as
and eventual survival.                                           a quantitative tool in support of platform design. In
   For example, many attribute the Internet’s success
to its original minimalist design, which allowed it to           1
                                                                   We use the terms features and functionality inter-
  Supported by NSF grant CNS-0721610.                            changeably throughout the paper.
†                                                                2
  This work was done while the author was at Penn                  The paper assumes a monopoly platform setting.

particular, the model identifies the ratio of the rate            intermediary to invest in network externalities asym-
of change in the cost (to the platform) of adding new            metrically to maximize the network benefits for one
features relative to the cost of developing applications         market side. In contrast, we consider scenarios where
given a number of platform features, as a key factor             the platform provider does not have the means to di-
in determining the optimal (for the platform) number             rectly impact cross-externalities. Instead, the plat-
of features to offer. This optimal choice is, however,            form can invest in adding features that make applica-
highly sensitive to small changes in this ratio, with            tion development easier for developers, and thus in-
minor differences producing drastically different out-             directly influence adoption levels. Such scenarios are
comes, i.e., shifting the optimal operating point from           typical for many web services and social network plat-
a minimalist to a feature-rich platform. This negative           forms where the level of functionality offered by the
result not-withstanding, the model provides a frame-             platform determines how costs and benefits are shared
work for reasoning about the impact of introducing               by the platform and developers. In that context, we
more features to a platform. In addition, in cases               investigate how different factors affect the platform’s
where the costs of developing new features and their             decision to be minimalist or feature-rich. The results
benefits in lowering application development costs can            contribute to the literature on e-commerce intermedi-
be estimated, the model offers quantitative tools that            ary investments and platform design.
can assist decision makers. Section 3.5 reviews some                Two-sided markets: Two-sided markets are made
scenarios for which such estimation may be feasible,             of two interdependent groups of customers (e.g., sell-
and for each broadly characterize the “shape” of the             ers and buyers) and a platform intermediary. The
cost functions as the number of features that the plat-          platform facilitates interactions between these two cus-
form offers varies.                                               tomer groups and generates its revenue by charging
   The rest of the paper is organized as follows. Sec-           them a price for joining the platform. The focus of
tion 2 reviews prior works in two-sided markets and e-           most works on the topic has to-date been on how pric-
commerce platform intermediaries, which provide use-             ing and pricing structure affects the platform adoption
ful background on techniques of potential relevance              and its success, e.g., see [15, 24, 22, 14, 29] for rele-
to platform design. Section 3 casts the problem of               vant discussions and pointers to other related works.
platform design using a two-sided market model. Sec-             A few more recent works [9, 20] have relied on two-
tion 4 outlines a solution methodology, while Section 5          sided markets to investigate net-neutrality. Our work
presents a preliminary analysis based on this solution           builds on the existing literature, but rather than fo-
method, and uses its results to investigate the impact           cusing on pricing it uses a two-sided market model to
of different factors. Section 6 discusses possible ex-            explore the effect of platform functionality on its adop-
tensions to the preliminary results of the paper, and            tion. As mentioned earlier, the question is relevant to
more generally argues for the applicability of models            several contemporary plaforms from the Internet, to
from the economics literature to a variety of technol-           Facebook, to Amazon Web Services (AWS), etc. For
ogy design issues.                                               example, in the case of Internet, the question is cast in
                                                                 terms of whether or not it should depart from its orig-
2.   RELATED LITERATURE                                          inal minimalist design. A formulation as a two-sided
   The purpose of this section is two-fold. First, it            market can provide a quantitative handle on what is
offers a brief overview of two sets of works relevant             arguably a complex question.
to the type of models the paper considers. Second, it
seeks to position the approach used in the paper in the          3.   MODEL FORMULATION
context of these related works. The two sets of works               A platform provider attracts developers and con-
relevant to the paper are (i) platform intermediaries            sumers by creating value that entices them to join the
in e-commerce markets; and (ii) two-sided markets.               platform. This ‘value’ depends on a number of factors,
   As discussed earlier, the problem faced by the plat-          such as the platform’s intrinsic value, the subscription
form is that its costs and benefits are coupled through           fees to join it, the cost of developing applications for
cross-externalities involving its two customer types,            it, and externalities that affect the value that devel-
i.e., users and application developers. This has arisen          opers and consumers derive from joining the platform.
in other settings, and in particular in e-commerce mar-          When modeling a platform as a two-sided market, ex-
kets, which therefore boast a large body of relevant             ternalities are usually classified as same-side external-
works that we briefly discuss. Similarly, the modeling            ities and cross-side externalities. Same-side externali-
of the platform as a two-sided market with users and             ties arise in each side of the market from the presence
application developers as the two sides of the market,           of other users [19, 9, 29]. Cross-side externalities mea-
calls for at least a cursory review of works in that area.       sure benefits that one side of the market derives from
In both cases, the primary difference between this pa-            the other. These are usually positive, i.e., consumers
per and previous works is its focus on the trade-off be-          benefit from more applications offered by developers,
tween the platform and application developers costs,             and conversely developers benefit from being able to
and how it affects the platform’s design choice.                  target more consumers.
   Platform intermediaries in e-commerce mar-                       The adoption of the platform by either developers
kets: The bulk of the literature in electronic inter-            or consumers depends on the overall value they derive
mediaries has focused on how they lower search costs             from it. As commonly done, we measure this value
for buyers and increase price competition among sell-            through a utility function that incorporates the differ-
ers [2]. However, a number of works [3, 2, 29] have              ent factors that contribute to it. Similarly, the impact
explored the impact of infrastructural investments by            of the decisions that the platform provider makes, i.e.,
the intermediary platform on cross-network external-             pricing and selection of the platform’s functionality,
ities. For example, [3] shows that it is optimal for an          are also reflected through the platform provider’s util-

ity function. The utility functions for the platform,            spectively5 . These fees may be incurred as a monthly
the developers, and the consumers are described in               membership fee for consumers and as a licensing fee
Subsections 3.2, 3.3, and 3.4, respectively. However,            for developers.
before introducing these utility functions, we briefly              The revenue for the platform is, therefore6 ,
review a number of assumptions we make in the model
and their implications on its applicability.                                           pc xc + bd nd .
                                                                   As mentioned earlier, the set of platform features
3.1    Assumptions and Implications                              of potential benefits to application developers is as-
   As with most models, we make assumptions for ana-             sumed known to the platform provider. Embedding
lytical tractability and hope that the results offer qual-        more features in the platform incurs a greater cost,
itative insight applicable in practice. Following [3, 9,         and we denote as C(F ) the cumulative cost of incorpo-
22], the model considers only cross-side externalities3 ,        rating F features. We assume that the set of possible
as they typically impact adoption the most.                      features is large. Hence, when mapped on to an in-
   We also assume that developers generate revenue               terval [0, F max ], they result in a differentiable, mono-
from advertisements and not consumers purchases, i.e.,           tonically increasing function for F ∈ [0, F max ]. An
free downloads and minimal transaction costs. This is            integrality constraint on F is, therefore, not consid-
reasonable in many settings, e.g., when applications             ered explicitly. In Subsection 3.5, we discuss specific,
are offered for free and the bulk of the developers’ rev-         real-world examples to illustrate possible behaviors for
enue comes from location based and personalized ad-              C(F ), i.e., concave or convex.
vertising [17, 25], a trend that is expected to grow [10].         The profit (utility) of a platform with F built-in
The revenue generated by an application is further as-           features and fees of pc and bd is given by
sumed to be linear in the number of users4 .
   Two other important assumptions are that (i) ap-                           Up = pc xc + bd nd − C(F )               (1)
plications all make use of the same set of platform
                                                                 As discussed in Section 4, Eq. (1) together with similar
features; and (ii) the functionality embedded in these
                                                                 expressions for the utility of consumers and applica-
features can be built by either the platform or the de-
                                                                 tion developers will guide the decisions of how many
velopers, with possibly different costs but the same
                                                                 features to embed in the platform and how to price it.
quality. We briefly expand on both assumptions.
   Assumption (i) implies homogeneous development                3.3    Developer Utility
needs across applications (services). In other words,
they rely on the same platform application program-                Developing applications incurs a cost that depends
ming interfaces (APIs) or independent features cre-              on the level of support provided by the platform (num-
ated by developers. They can still be differentiated,             ber of features). A feature-rich platform will usually
but this clearly limits the range of their differences.           have higher subscription fees, but afford lower appli-
Assumption (ii) calls for the platform provider to know          cation development costs. Conversely, the revenues
application development needs ahead of time, and for             generated by an application depend on the number of
application developers to be able to independently de-           consumers of the platform, and grow in proportion to
velop features that the platform decides not to incor-           that number. Eq. (2) captures the combined effect of
porate. This is reasonable for many software products            these factors on the developers’ utility.
and services, where platform and applications share a                      Ud = αxc − bd − (K(F ) + τ φ)               (2)
common technology. However, it excludes hardware
features whose presence or absence determines the fea-           The first component of Eq. (2) represents the applica-
sibility (or not) of certain applications, e.g., a graphic       tion revenues generated from the xc consumers that
processor is mandatory for certain rendering effects.             joined the platform (the factor α is the marginal value,
Implicit in assumption (ii) is that the development              e.g., ad revenue, that a consumer generates for the
quality (and cost) of a feature by either the platform           developer). The second component of Eq. (2) is the
or the developers, is fixed and not a decision variable.          flat-fee, bd , a developer pays the platform, e.g., license
   In general, assumptions (i) and (ii) limit the model’s        fee for certification.
applicability to platforms that are software ecosys-                The last component of Eq. (2) accounts for develop-
tems, e.g., cloud computing, web services, OSes, etc.            ment costs. They depend on the number F of features
Next, we introduce the utility functions that drive the          provided by the platform, as captured by K(F ). The
decisions of the platform provider, application devel-           function K(F ) is assumed differentiable, and mono-
opers, and consumers.                                            tonically decreasing for F ∈ [0, F max ]. For a given
                                                                 F, K(F ) is the same for all developers, and can be
3.2    Platform Utility                                          interpreted as the base cost of developing applica-
  The platform provider’s goal is to maximize its profit,         tions on a platform with F built-in features. This
which depends on revenue from the two market sides               assumes comparable skill levels across developers, who
and the cost of the platform features it offers.                  can however exhibit heterogeneity in their overall de-
  We use xc and nd to denote the fraction of a large             velopment costs, e.g., because of different fixed costs.
population of consumers and developers who join the              This heterogeneity is captured in the factor τ φ of
platform. As in [3, 9], the platform charges flat fees of         Eq. (2), where as is commonly assumed [3, 9, 27, 29] φ
pc and bd to the consumers and to the developers, re-            is uniformly distributed on a unit interval7 , and τ is a
3                                                                5
  Appendix E.1 of [26] shows that the main results are             pc or bd can be positive or negative (subsidy).
qualitatively unaffected by same-side externalities.                See Appendix B of [26] for relabeling of parameters to
4                                                                account for consumer and developer population sizes.
  Non-linearity has a quantitative, but not a qualita-
tive effect.                                                        Results typically extend to other distributions [5, 12]

normalization constant. Section 3.5 provides again il-                 Amazon Web Services           IP Multimedia Subsystems
lustrative, real-world examples of possible K(F ) func-                         C(F)
tions. In particular, K(F ) can be convex or concave                                                                    C(F)
depending on how additional platform features trans-
late into marginal reductions in development costs.
3.4    Consumer Utility                                                            K(F)
   The value that consumers derive from joining a plat-
form depends on the subscription fees charged, and                             F                                F
on the number of applications and services accessible               (1) Concave C(F), Convex K(F)   (2) Concave C(F), Concave K(F)
through the platform. Consumers are typically het-
erogeneous, and this heterogeneity manifests itself in            Figure 1: Examples of different C(F ) and K(F ).
how they value the platform, applications and services
(cross-side externality), or both. For simplicity and
analytical tractability, we focus on a model where het-              The introduction of features on the AWS platform
erogeneity is present only in how consumers value ac-             proceeded in two steps. Between 2006-2007, Ama-
cess to applications. Appendix E.2 of [26] presents an            zon introduced a set of core features (EC2, FPS, Sim-
alternative utility function and its analysis, where con-         pleDB, etc.) that offered basic capabilities such as
sumers are instead heterogeneous in how they value                computation, database, and payment. Additional fea-
the platform. The results under both utility functions            tures (e.g., SQS, SNS, DevPay, etc.) that built on
are qualitatively similar.                                        these core capabilities were subsequently introduced.
   The consumer utility function is of the form:                     Each new feature came at a cost. Using API com-
                  Uc = θβnd − pc                       (3)        plexity9 as a proxy for the platform’s development
                                                                  cost, [13] observed that capabilities such as EC2, FPS,
The first component, θβnd , captures the cross-side ex-            and SimpleDB had a higher cost than follow-on en-
ternality benefits that consumers enjoy from access-               hancements such as SNS and DevPay. From this data,
ing applications available on the platform. Consistent            the feature development cost function, C(F ), of the
with earlier works [29, 3, 27], those benefits are as-             AWS platform can be inferred to be a concave increas-
sumed linear in the number of available applications              ing function of F . Conversely, the benefits of a feature
and, therefore, developers (nd ) under the assumption             can be estimated based on its “popularity” among de-
that developers are homogeneous in the number of                  velopers, i.e., presuming that more useful features are
applications they create. The factor β denotes the                more likely to be used. Using again [13], we see that
marginal externality benefit associated with each de-              most core features, e.g., EC2, SDB, FPS, are signifi-
veloper. The term θ ∈ [0, 1] is a random variable that            cantly more popular than enhancement features, e.g.,
accounts for heterogeneity in how users value access              SQS, SNS, DevPay. In other words, the features most
to applications. As with the random variable φ of                 costly to develop and incorporate in the platform are
Eq. (2), we assume that θ is uniformly distributed in             also the most useful to developers; at least based on
[0, 1]. The last element of Eq. (3) is the price pc , which       how often they took advantage of them. Hence, one
is a flat membership fee paid to the platform provider.            can conclude that while the development cost func-
                                                                  tion C(F ) of the AWS platform is a concave increas-
3.5    Representative Examples                                    ing function, the benefits that developers derive from
   Before presenting how the three utility functions              those features, as captured by the function K(F ), is
just introduced combine in the platform provider deci-            a convex decreasing function, i.e., the more expensive
sion process, we pause to introduce two examples8 (see            initial features are also the most useful.
Fig. 1) that illustrate possible combinations of the cost
functions C(F ) and K(F ). In both examples, there                2. IP Multimedia Subsystems (IMS) Platform:
is an inherent ordering of the features the platform              The IMS platform is meant to facilitate the develop-
provider is considering offering, i.e., from basic fea-            ment of new integrated multimedia applications and
tures to more advanced ones, with the latter building             services. Both applications developers and subscribers
on the former. The examples differ in the relative cost            (consumers of services) pay a fee to the IMS platform.
(to the platform) of more advanced features compared              The platform offers a number of built-in capabilities
to basic ones, and the impact of additional feature on            such as a registration mechanism, co-location of mul-
application development costs.                                    tiple IMS services, quality of service, etc. These capa-
1. Amazon Web Services Platform: Amazon                           bilities are exposed to developers through APIs using
Web Services (AWS) is a cloud computing platform                  Java specifications (JSRs). There are multiple “lay-
that offers functionality (features) which third-party             ers” of JSRs [16, 21], from low-level JSRs such as JSR-
developers can use to create services for clients (con-           180, to high-level JSRs such as JSR-186/187, to more
sumers). These features include Amazon EC2 (com-                  developer friendly APIs for Communication Services
putation), SimpleDB (database), Amazon S3 (stor-                  such as JSR-281+. Each layer builds on those below,
age), etc. Consumers and developers of services and               with the base layer that implements the core capabil-
applications on the AWS platform enjoy cross-side ex-             ities of the platform the most expensive to develop.
ternalities, for which they pay subscription fees.                Additional layers are typically “wrappers” meant to
                                                                  hide low-level details from developers, and therefore
that share with the uniform distribution the impor-
tant property of a non-decreasing hazard-rate function            9
                                                                    [13] measured API complexity using the number of
F (φ)/(1 − F(φ)).                                                 operations that the feature supports, as captured in
  See Appendix A of [26] for a third example.                     the data required in specifying WSDL.

typically easier for the platform to implement. The                          Similarly, the value φ of the marginal developer who
development cost function C(F ) of the IMS platform                          is indifferent between joining the platform or not is
is, therefore, again a concave increasing function of
the number F of features (JSRs) it offers.                                                φ = nd = αx∗ − bd − K(F ) .
                                                                                                    c                               (5)
   On the developer side, application development costs                      The parameters in Eq. (5) are normalized and rela-
are high when only low-level APIs are available, mostly                      beled following the procedure of Appendix B of [26].
because of greater programming complexity. As APIs                           At equilibrium, x∗ = xc and n∗ = nd , so that equilib-
                                                                                              c            d
that hide many of the platform’s low-level intrica-                          rium adoption levels satisfy
cies are made available, development costs decrease
rapidly. In other words, the function K(F ) is a con-                                         pc     =   (1 − x∗ )βn∗
                                                                                                               c    d               (6)
cave decreasing function, i.e., low-level APIs have lit-                                      bd     =   αx∗ − n∗ − K(F )
                                                                                                           c    d                   (7)
tle effect on developers costs, while higher-level ones
deliver significant benefits.                                                  4.2    Pricing Stage
   In the next section, we introduce the methodology                           Given a number of features F , the decision prob-
used by the platform provider to decide on the “opti-                        lem of the platform provider is to select fees pc and
mal” number of features to incorporate.                                      bd that maximize its profit, subject to constraints on
                                                                             the fractions of consumers and developers joining the
4.    SOLUTION METHODOLOGY                                                   platform. This yields
  The platform provider’s objective is to decide on                                  max Up =            pc x∗ + bd n∗ − C(F )
                                                                                                             c       d              (8)
the number of features to include in the platform, and                               x∗ ,n∗
                                                                                      c   d
what to charge consumers and developers to maximize                                           s.t.        0 ≤ x∗ ≤ 1; 0 ≤ n∗ ≤ 1
                                                                                                               c           d
profit. This can be realized through the three-stage se-
quential process of Fig. 2. In the first stage, the plat-                     Using Eqs. (6) and (7) in Eq. (8), optimal fees and
form provider chooses the number F of features built                         corresponding adoption levels are obtained. Propo-
into the platform. Given a choice for F , prices for                         sition 1 gives expressions for interior solutions, i.e.,
the two market sides are chosen in the second stage.                         0 < x∗ , n∗ < 1), which arise when α < β and 4βK(F ) <
                                                                                   c   d
Equilibrium adoption levels of consumers and devel-                          (α + β)2 < 4β(2 − K(F )), under which the second or-
opers are simultaneously realized in the third stage.                        der conditions of the Hessian also hold. Boundary so-
The three stages are referred to as the Design Stage,                        lutions, i.e., x∗ = 0, 1 or n∗ = 0, 1 solutions are given
                                                                                             c            d
Pricing Stage, and Adoption Stage, respectively.                             in Appendix D of [26]. Derivations can be found in
                                                                             Appendix C of [26].
        Direction of solution

                                                                                Proposition 1. Optimal price levels (p∗ , b∗ ) and
                                                                                                                       c   d
                                Platform decides
               Design Stage     functionalities level, F                     optimal adoption levels (x∗ , n∗ ) that maximize the
                                                                                                        c    d
                                                                             platform provider’s profit are given by

               Pricing Stage    Platform decides
                                user fee, pc , developer fee, bd
                                                                                    c    =    (β − α)((α + β)2 − 4βK(F ))/16β       (9)
                                                                                    d    =    ((3α − β)(α + β) − 4βK(F ))/8β       (10)
                                User adoption level, xc
             Adoption Stage
                                Developer adoption level, nd
                                                                                    c    =    (α + β)/2β                           (11)
                                                                                    ∗                    2
                                                                                   nd    =    ((α + β) − 4βK(F ))/8β               (12)
           Decision Timeline
                                                                                Proposition 1 reveals properties that are consistent
      Figure 2: Sequential decision process                                  with prior works in two-sided markets [3, 29, 6]. In
                                                                             particular, optimal pricing is typically asymmetric,
   This sequential decision process is solved in reverse                     i.e., different prices are levied on the two market sides,
order. Equilibrium adoption levels for users and de-                         and in some cases one market side may be subsidized,
velopers are first computed for a given choice of prices                      e.g., b∗ < 0 while p∗ > 0.
                                                                                    d             c
and number of built-in features. Next, given a number
of features, ‘optimal’ prices are computed based on the                      4.3    Design Stage
equilibrium adoption levels of the previous step. The                           Using the results of Proposition 1 in Eq. (8), the
results characterize the platform’s profit for any given                      platform provider can determine the optimal number
number of features. This can then be used to find the                         of features F ∗ that maximizes profits. Solving for
‘optimal’ number of features, F ∗ , that maximizes the                       ∂Up         ∗
                                                                              ∂F = 0, F can be shown to verify the conditions
platform’s profit. These steps are detailed next.                             of Proposition 2.
4.1    Adoption Stage                                                           Proposition 2. The optimal number F ∗ of fea-
   Consumers and developers both make rational and                           tures that should be built into the platform to maximize
incentive-compatible decisions, and join the platform                        profit satisfies
only if they derive positive utility. We let x∗ and n∗
                                                 c        d                                        C (F ∗ )   K(F ∗ ) (α + β)2
denote the expected fraction of consumers and devel-                                                    ∗)
                                                                                                            =        −             (13)
                                                                                                   K (F         2        8β
opers joining at equilibrium.
                                                                                                   C (F ∗ )
   Given pc , bd , and F , the value θ of the marginal con-                             ⇒                   = −n∗ (F ∗ )
                                                                                                                d                  (14)
sumer who is indifferent (derives zero utility) between                                             K (F ∗ )
joining the platform or not is                                                          and        C (F ∗ ) > −n∗ (F ∗ )K (F ∗ )
                 θ = 1 − xc = pc /βn∗ .
                                    d                              (4)                                       +(1/2)[K (F ∗ )]2     (15)

where Eq. (14) is obtained using Eq. (12) in Eq. (13).                                                             F ∗ and the optimal prices, p∗ (F ) and b∗ (F ). The de-
                                                                                                                                                 c           d
   Note that the condition C (F ∗ )/K (F ∗ ) = −n∗ (F ∗ )
                                                    d                                                              pendency of F ∗ on the relative rate of change of C(F )
of Eq. (14) implies that at F ∗ , the marginal increase in                                                         and K(F ) is captured in Eq. (13).
the cost to the platform of adding more features equals                                                               In general, note that the platform utility function
the marginal decrease in development costs across all                                                              of Eq. (1) includes product terms of the form pc xc
developers subscribed to the platform 10 .                                                                         and bd nd , which imply complex dependencies on the
   Note also (see Section 5) that selecting the optimal                                                            functions C(F ) and K(F ). Hence, the function Up (F )
number of features still calls for evaluating profits at                                                            that the platform provider seeks to maximize can ex-
all F ∗ that satisfy Eqs. (13) and (15), and at the                                                                hibit a wide range of variations, e.g., multiple max-
boundaries F = 0 and F max .                                                                                       ima/minima, even when C(F ) and K(F ) are individ-
   Using the above results, Section 5 explores how dif-                                                            ually “well-behaved,” e.g., concave or convex. Clearly,
ferent system parameters, i.e., externality benefits and                                                            the possibility of several F values satisfying Eqs. (13)
costs, affect the optimal number of platform features.                                                              and (15) complicates the platform provider’s decision
                                                                                                                   process. Furthermore, the optimal decision also de-
5.                   ANALYSIS                                                                                      pends on how profits at these local maxima compare
                                                                                                                   to “boundary” profits, i.e., for F = 0 and F = F max .
  In this section, we use Proposition 2 to explore prop-                                                              Numerical investigations easily produce combina-
erties of F ∗ and the influence of system parameters.                                                               tions of C(F ) and K(F ) for which the platform util-
We begin with Eqs. (13) and (15), which we use to                                                                  ity exhibits local maxima at different F values. In
characterize how changes in (cross-side) externality                                                               general small adjustments in the relative rate of in-
benefits affect F ∗ . The results are in Proposition 3,                                                              crease and decrease of C(F ) and K(F ) are sufficient
whose proof is in Appendix C of [26].                                                                              to yield drastic shifts in outcome. This is to a large
   Proposition 3. For interior solutions (0 < x∗ , n∗ <                                                            extent borne by Eqs. (13) and (15), which indicate
                                                c d
1), increases in the cross-side externality benefits α                                                              that the F ∗ value at which both equations are satis-
and β favor adding functionality to the platform. In                                                               fied can change substantially through small changes
                ∗             ∗                                                                                    in the functional expressions of either K(F ) or C(F ).
other words, ∂F > 0 and ∂F > 0.
              ∂α            ∂β                                                                                     The implications are that the optimal investment in
  Fig. 3 illustrates this behavior through a represen-                                                             features for a platform cannot be easily inferred from
tative example11 . It shows that F ∗ increases as de-                                                              general properties of C(F ) and K(F ), e.g., concavity
veloper’s cross-side benefits increase from α = 0.65 to                                                             or convexity. Instead, it calls for a fine-grain com-
α = 0.67. We note that Proposition 3 is consistent                                                                 parison of the costs of developing features and their
with arguments in favor of expanding the Internet’s                                                                benefits to application developers.
functionality at a time where the services it offers be-
come more valuable, and the providers of those ser-                                                                                            52
vices derive more value than previously feasible.                                                                                                       α=0.6; β=0.8;
                              24                                                                                                               48
                                                                                                                       Platform’s Profit, Up

                                       K(F)=0.4*e−0.194*F                                                                                                                                  z2=1.3
                                       C(F)=0.008*F1.15                                                                                        46


                                                                                       α=0.67                                                  44
     Platform’s Utility, Up

                                                                              α=0.65                                                                                                                  z2=1.03

                              19                                                                                                               40

                              18                                                                                                               38
                                                                                                                                                    0      0.5          1     1.5      2        2.5   3         3.5   4
                                                                                                                                                                              Number of Features, F

                                   0         0.5        1   1.5      2        2.5         3     3.5   4
                                   F=0                      Number of Features, F                     F=Fmax       Figure 4: Boundary solutions (F = 0 or F =
                                                                                                                   F max ) are optimal for concave K(F ) and C(F ).
                                          Figure 3: Impact of α on F ∗ .
                                                                                                                      The one instance for which the range of possible out-
                                                                          ∗                                        comes can be narrowed is when both C(F ) and K(F )
   Next, we investigate how F is affected by changes
                                                                                                                   are concave, e.g., the IMS platform example. In this
in the relationship between the cost of adding new fea-
                                                                                                                   case, the optimal number of features can be shown to
tures to the platform and the benefits that application
                                                                                                                   always be at one of the two boundaries, i.e., F = 0
developers derive from them. The platform develop-
                                                                                                                   or F = F max (see Appendix C of [26] for a proof).
ment costs C(F ) increase with F , while application
                                                                                                                   The optimal solution can still be either a minimalist
development costs K(F ) decrease. The relative rates
                                                                                                                   or a functionality-rich platform, but the number of
of these increases and decreases ultimately determine
                                                                                                                   alternatives to evaluate is considerably reduced. We
10                                                                                                                 illustrate this with a numerical example in Fig. 4. The
   Eq. (14) remains valid for boundary cases where ei-
 ther market sides is at full market penetration.                                                                  figure shows the platform’s profit as a function of the
   The parameters in all the figures of this section are                                                            number of features it offers for two different config-
 assumed to be normalized with respect to populations                                                              urations. In both configurations, the platform cost
 of size Nc = Nd = 103 , and maximum fixed cost for                                                                 grows like F , while application developers experi-
 developers, τ = $103 .                                                                                            ence a super-linear cost decrease in F parametrized

                                                                                                          slower decrease in the first case implies that more fea-
                                      α=0.4, β=0.6                                                        tures need to be added to realize a similar benefit.
                                                                                                          This would seem to suggest that a larger number of
                             80       K(F)= 0.25 e−g2 F
                                      C(F)=0.01 F0.7                                                      features would be preferable. The figure shows that
    Platform’s Utility, Up   75                                                                           the opposite is actually true, i.e., a minimalist choice
                             70                                                                           (F = 0) is preferred when K(F ) = 0.25e−0.35F , while
                             65                                                   g =0.35
                                                                                   2                      K(F ) = 0.25e−0.43F calls for a platform with a rel-
                                                                                                          atively large number of features. The reason is that
                                                                                                          when K(F ) = 0.25e−0.43F and costs drop fast, adding
                                                                                                          features ultimately yields a lower absolute value of
                                                                                                          K(F ), which encourages more developers to join and
                                                                                                          ultimately produces a higher profit. In contrast, the
                                  0       0.5        1    1.5      2       2.5    3         3.5   4
                                                                                                          slower cost decrease of K(F ) = 0.25e−0.35F is such
                                                          Number of Features, F                           that the smaller number of developers that join is not
                                                                                                          sufficient to produce a higher profit than when F = 0.
Figure 5: Multiple local maxima for convex                                                                   Finally, we should point out that while the scenario
K(F ) and concave C(F ).                                                                                  of Fig. 5 showed only one interior maximum, it is pos-
                                                                                                          sible to have more than one. This is illustrated in
                                                                                                          Fig. 7 in Appendix F of [26], which involves a con-
by z2 (see the legend). The figure shows that when                                                         vex decreasing K(F ) function and a convex increas-
z2 = 1.03 (the decrease is nearly linear), a minimal-                                                     ing C(F ) function. As in the previous example and
ist platform is more efficient, while when the decrease                                                     for essentially the same reasons, the choice of which
if steeper (z2 = 1.3) a functionality-rich platform is                                                    maximum yields the highest overall profit depends on
preferred. This is obviously intuitive, but the model                                                     the relative rates of change of the two cost functions.
offers a quantitative validation of this insight.
   For all other combinations of convex or concave                                                        6.   CONCLUSIONS
C(F ) and K(F ), more complex outcomes can arise,
                                                                                                             The paper applies models from the economics litera-
including instances where an intermediate number of
                                                                                                          ture to the problem of platform design, and uses them
features is optimal. We illustrate this with a numeri-
                                                                                                          to explore whether a a minimalist or a feature-rich de-
cal example in Fig. 5, which corresponds to a scenario
                                                                                                          sign should be used. The question is formulated using
similar to the AWS example of Section 3.5; C(F ) is
                                                                                                          a two-sided market model, with the platform as the
concave increasing and K(F ) is convex decreasing in
                                                                                                          market and service developers and consumers as its
F . As before, the figure plots the platform’s (profit)
                                                                                                          two sides. The model is solved using a three stage se-
utility Up (y-axis) as a function of F ∈ [0, 4] (x-axis).
                                                                                                          quential decision process, and results of a preliminary
The figure displays results for two different convex de-
                                                                                                          investigation are presented.
creasing K(F ), while C(F ) is kept equal to C(F ) =
                                                                                                             The investigation confirms a number of properties
0.01F 0.7 (concave increasing). The two chosen func-                                                      traditionally present in two-sided markets, e.g., the
tions for K(F ), K(F ) = 0.25e−g2 F ; g2 = {0.35, 0.43},                                                  benefits of asymmetric pricing, and the effect that
differ in their rate of decrease with F . The figure re-                                                    cross-externalities have in shaping the outcome. More
veals the following three interesting behaviors.                                                          importantly, it illustrates how the platform decision
   First, it shows that in this scenario the platform                                                     is highly dependent on the relative rate of change of
provider’s utility has two local maxima for; one corre-                                                   its own cost structure (how cost increases with the
sponding to a minimalist choice (F = 0), and the other                                                    number of features it offers) and that of application
to an intermediate optimal number of features F ∗ that                                                    developers (how they benefit from new features). An
satisfies Eqs. (13) and (15). Selecting the globally op-                                                   unfortunate corollary of this finding is that very mi-
timal solution calls not only for computing F ∗ , but                                                     nor changes in either cost structures can translate into
also for comparing profits at F = 0 and F = F ∗ .                                                          very different (optimal) outcomes. This argues that
   Second, it shows that a small change in the rate                                                       given the inherent inaccuracy in estimating cost struc-
of decrease in the developers’ cost K(F ) can produce                                                     tures, identifying a platform’s optimal (how feature-
drastically different choices for the platform provider.                                                   rich) design point remains challenging, and this in
In the case of K(F ) = 0.25e−0.35F , the provider’s op-                                                   spite of the analytical handle that the paper offers.
timal choice is a minimalist design (i.e., F = 0), while                                                     This limited success notwithstanding, the paper has
for K(F ) = 0.25e−0.43F , the provider should create                                                      hopefully illustrated the applicability of the model on
a platform with a large number of built-in features                                                       which it is based. Given the preliminary nature of the
(i.e., F = F ∗ ≈ 3). This illustrates the dependency                                                      investigation, there are obviously many directions in
of the decision process on the rate at which devel-                                                       which it can and should be extended. Empirical vali-
opment costs decrease as the number of features in-                                                       dations are obviously at the forefront, and exploring if
creases. A similar outcome can be obtained by keeping                                                     this can be done for one of the examples of Section 3.5
K(F ) constant, and changing the rate of increase in                                                      is of interest. Relaxing the modeling assumptions of
the platform provider’s cost (i.e., C (F )).                                                              Section 3.1 is also worth pursuing. In particular, ap-
   Third, the figure illustrates a behavior that may at                                                    plications should be able to use different “subsets” of
first seem counter-intuitive. Consider the two devel-                                                      the platform’s features, with the fraction of applica-
opers cost functions K(F ) = 0.25e−0.35F and K(F ) =                                                      tions to which a (new) feature is useful drawn from a
0.25e−0.43F . The rate of decrease of K(F ) is higher                                                     probability distribution. Similarly, some features may
in the second, so that the biggest benefits are real-                                                      be available only from the platform, i.e., developers
ized when adding the first features. In contrast, the                                                      cannot implement a substitute, and their availability

or unavailability would then determine the feasibility[14] A. Hagiu. Pricing and commitment by two-sided
of some applications. Finally, another “natural” ex-       platforms. The RAND Journal of Economics,
tension is to introduce multiple platforms and allow       37(3):720–737, 2006.
them to compete. In such a context, an attractive di- [15] A. Hagiu. Multi-Sided Platforms: From
rection is to explore possible combinations with mod-      Microfoundations to Design and Expansion
els from “evolutionary science,” as recently done in [1].  Strategies. Harvard Business School Strategy
Evolutionary behaviors could, for example, be incor-       Unit Working Paper No. 09-115, 2009.
porated to determine which features survive based on  [16] JSR: IMS Communication Enablers (ICE),
their usefulness to new applications, and how this af-     2010.
fects a platform own survival.                        [17] M. Maisto. Mobile app revenue soaring,
                                                           although most are free, 2010.
7. REFERENCES                                              /index2.php?option=content&do_
 [1] S. Akhshabi and C. Dovrolis. The evolution of    [18] K. Martin and I. Todorov. How Will Digital
     layered protocol stacks leads to an                   Platforms Be Harnessed in 2010, and How Will
     hourglass-shaped architecture. In Proc. ACM           They Change the Way People Interact with
     SIGCOMM Conference, Toronto, ON, Canada,              Brands? Journal of Interactive Advertising,
     August 2011.                                          10(2):61–66, 2010.
 [2] Y. Bakos. Reducing buyer search costs:           [19] M.L.Katz and C. Shapiro. Network externalities,
     Implications for electronic marketplaces. MIS         competition and compatibility. American
     Quarterly, 15(3):295–310, 1991.                       Economic Review, 75(3):424–440, 1985.
 [3] Y. Bakos and E. Katsamakas. Design and           [20] J. Musacchio, G. Schwartz, and J. Walrand. A
     ownership of two-sided networks: Implications         two-sided market analysis of provider
     for Internet platforms. Journal of Management         investment incentives with an application to the
     Information Systems, 25(2):171–202, 2008.             net-neutrality issue. Review of Network
 [4] R. Beaubrun, B. Moulin, and N. Jabeur. An             Economics, 8(1):22–39, 2009.
     Architecture for Delivering Location-Based       [21] U. Olsson and M. Stille. Communication
     Services. International Journal of Computer           services - the key to IMS service growth.
     Science and Network Security, 7(7):160–166,           Ericsson Review, 2008.
     2007.                                            [22] G.G. Parker and M.W. Van Alstyne. Two-sided
 [5] H.K. Bhargava and V. Choudhary. Economics of          network effects: A theory of information
     an Information Intermediary with Aggregation          product design. Management Science,
     Benefits. Information Systems Research,                51(10):1494–1504, 2005.
     15(1):22–36, 2004.                               [23] R. Reed. Facebook places: The de facto
 [6] B. Caillaud and B. Jullien. Chicken and egg:          platform for LBS, 2010.
     Competing matchmakers. Rand Journal of      
     Economics, 34(2):309–328, 2003.                       places-platform-lbs/.
 [7] J. Catone. eBay Launches Dev Platform - Too      [24] J.-C. Rochet and J. Tirole. Two-sided markets:
     Little, Too Late?, 2008.         a progress report. The RAND Journal of
     /archives/ebay_launches_ dev_platform.php.            Economics, 37(3):645–667, 2006.
 [8] K. Currier. Comparative Statics Analysis in      [25] E.I. Schwartz. Behind the surge in mobile
     Economics. World Scientific Publishing                 advertising, 2010.
     Company, August 2000.                       
 [9] N. Economides and J. Tag. Net neutrality on           /business/26648/.
     the Internet: A two-sided market analysis.       [26] S. Sen, R. Guérin, and K. Hosanagar.
     Working Paper no. 07-14, NET Institute, New           Functionality-rich versus minimalist platforms:
     York University, 2007.                                A two-sided market analysis. Technical report,
[10] K. Flanigan. $1.5 million ad revenue suggests         University of Pennsylvania, July 2011. Available
     free apps could be the future, 2010.                  at       [27] S. Sen, Y. Jin, R. Guerin, and K. Hosanagar.
     suggests-free-apps-could-be-the-future/.              Modeling the dynamics of network technology
[11] WPI Center for Wireless Information Network           adoption and the role of converters. IEEE/ACM
     Studies (CWINS). Location based applications          Trans. Netw., 18(6):1793–1805, 2010.
     are driving innovation in wireless               [28] I. Wilkes. Cloud platform choices: a
     communication industry, 2010.                         developer’s-eye view, 2010.
[12] D. Fudenberg and J. Tirole. Game Theory. MIT          /cloud-basics.ars.
     Press„ Cambridge, MA, 1991.                      [29] B. Yoo, V. Choudhary, and T. Mukhopadhyay.
[13] M. Garnatt. AWS by the numbers, 2010.                 A Model of neutral B2B intermediaries. Journal             of Management Information Systems,
     numbers.html.                                         19(3):43–68, 2002.


Shared By: