62
IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/04/$20.00 © 2004 IEEE
Not all marketplace issues (for example, sales
channels) strongly affect software project
planning and decision-making, but the deci-
sions we discuss here do. Rather than discuss
contracted software development for specific
customers or open-source software efforts,
we’ll emphasize the uncertainties and strategic
issues that suppliers encounter in selling or li-
censing software in the general marketplace.
3,4
We categorize these issues by the standard
ROI measures of revenue, cost, and risk.
Revenue
Revenue is affected by many factors, in-
cluding pricing strategies and unit sales. All
these factors strongly depend on design deci-
sions affecting customer-perceived value and
customer-incurred costs, as well as the status
of competition. Factors deserving careful con-
sideration include the customer’s costs of
switching to competitors, the value of com-
patibility with complementary products, and
any value associated with more widespread
adoption.
Companies can increase revenue by charg-
ing higher unit-license or subscription fees, by
increasing the number of units licensed, or
both. Total revenue is proportional to the
product of market share and market size, and
many revenue maximization strategies in-
crease one at the expense of the other.
focus
Marketplace Issues
in Software Planning
and Design
S
oftware management and project decisions must consider many
factors.
1,2
The most recognized return-on-investment drivers in-
clude the value to users; the cost of development, maintenance,
upgrades, and customer support; and the risks of project failure,
budget overrun, and revenue shortfall. This article focuses on other ROI is-
sues related to positioning software in the marketplace, which serves as an
intermediary between a software supplier organization and its customers.
return on investment
Strategic decisions in planning and designing commercial software
often arise from marketplace issues related to the ROI measures
of revenue, cost, and risk. These issues should influence ongoing
project planning and design decisions and should not be left to
business managers alone.
David G. Messerschmitt, University of California, Berkeley
Clemens Szyperski, Microsoft Research
Increasing market share requires taking cus-
tomers away from competitors or attracting a
disproportionate share of new sales; the latter
is especially effective in rapidly growing mar-
kets. Economic theory suggests that, assuming
equally effective marketing and sales efforts,
customers gravitate toward the products with
the largest consumer surplus—the difference
between value (willingness to pay) and total
cost of ownership, including recurring opera-
tional and acquisition costs. Software design
should therefore focus on both increasing value
and reducing the customer’s total cost. In all
cases, the focus should be on the paying cus-
tomer (often an organization), not just the soft-
ware’s users. Although usability is obviously a
significant source of value, the customer often
has a larger agenda. For example, the customer
might want to increase productivity, which can
reduce the number of users. Moreover, the cus-
tomer has many costs other than software ac-
quisition—for example, provisioning, deploy-
ment (including process changes and training),
and administration and management of the
software installation. Systematically reducing
recurring operational costs and the costs of
business process changes and training offers
considerable leverage because these costs often
dwarf the cost of software acquisition. Reduc-
ing customer costs allows increased prices
(more revenue) and leads to increased surplus
(competitive advantage and more unit sales).
Increasing the overall market size often re-
quires cooperation with competitors,
5
yielding
an explicit compact to reduce market share for
each competitor while increasing aggregate
revenues. Here, we discuss each of these
strategies, emphasizing the important issues in
designing and developing software.
Increasing value
Increasing value and satisfaction for cus-
tomers is critical for remaining competitive but
often isn’t sufficient to take market share away
from an established competitor. The reason is
that software has high first-copy costs and low
replication and distribution costs, creating sub-
stantial economies of scale (unit cost decreasing
with volume), although some recurring costs
such as distribution and customer support do
increase with unit sales. Suppliers should avoid
creating direct substitutes for other vendors’
products, partly because the economies of scale
for software strongly favor the supplier with the
larger market share: Established suppliers have
higher revenue with comparable costs. Obvi-
ously, substantial differentiation from competi-
tors in many possible dimensions—features, us-
ability, provisioning, and operations costs—is
crucial.
4
Conversely, there are considerable ad-
vantages to being first to market with a new
product category or a significant enhancement.
Software design should therefore focus heavily
on useful, customer-valued innovation.
Network effects.
In the presence of network
effects, the total number of adopters typically
increases a software product’s value.
4,6
These
effects can be positive (for example, the value
of instant messaging to each user increases
with the number of participating users) or
negative (the value of the Internet at a fixed
capacity decreases if it becomes congested due
to more users). They can also be direct (prod-
uct instances are directly dependent) or indirect
(value depends on some complementary com-
modity such as the number of programmers
facile with a given language or the available
content in an information access application).
Network effects have become more pervasive
in post-Internet software because, within a dis-
tributed system, the components often have a
direct mutual dependence. They can stifle a
new product in its infancy or enable its adop-
tion to take off explosively once it reaches a
critical mass of adopters. A virtuous cycle, in
which success feeds upon success by reinforc-
ing network effects, can increase market size—
for example, the rapid adoption encountered
by the original Napster.
A software development can account for
network effects by either expanding the base
of adopters, often at the expense of market
share or unit prices, or consciously minimizing
the dependence of value on market size.
Choosing proprietary interfaces for similar or
overlapping products might fragment the base
of adopters, whereas choosing an open inter-
face can let the product tap into an existing
network. For example, with Web services,
competitors have mutually benefited from co-
operating on a common platform for distrib-
uted applications.
A distributed application’s architecture can
strongly affect the network. For example, at-
tracting many adopters to a peer-to-peer archi-
tecture is crucial. A client-server architecture,
on the other hand, offers first adopters full
May/June 2004
IEEE SOFTWARE 63
Software
design should
focus on both
increasing
value and
reducing the
customer’s
total cost.
value (with notable exceptions, such as a site
that tries to create a collaborative community).
For instance, Napster depended on rapid adop-
tion for its value, whereas iTunes offered essen-
tially full value to its first adopter. Capabilities
such as software downloading with automatic
installation or mobile code help overcome the
early-adopter challenges of direct network ef-
fects (witness Napster or Skype) and enable the
establishment of applications that would oth-
erwise be impossible.
Extracting value through pricing.
Pricing is the
strategic business process for converting value
into the greatest revenue,
4
and it drives many
design decisions. Pricing alternatives such as
negotiating a selling price directly (typical of
outsourcing firms), licensing fees for each ma-
jor upgrade, or basing ongoing subscription
fees on usage measures have direct design im-
plications.
3
For example, selling software capa-
bilities as a service limits deployment platform
options, thus simplifying design and mainte-
nance. Each pricing scheme demands a different
design philosophy, and some require explicit in-
tegral monitoring and billing elements, license
servers, and so on.
In software, large first-copy costs make
unit cost loosely dependent on unit sales, so
costs offer little insight into pricing. Thus,
suppliers should try to base price not on costs
but on customer surplus, considering cus-
tomer costs as well as value. This is more prac-
tical if a product is strongly differentiated from
those of competitors, because direct competi-
tion drives unit prices toward unit marginal
costs, which are below average costs given the
economies of scale. A corollary is that it’s ad-
vantageous to drive down customer costs for
complementary products from other suppliers
by choosing cheaper options or by encourag-
ing competitive options. For example, through
design and support, an operating-system sup-
plier should encourage both a diversity of ap-
plications and competitive options for each
application. In this case, choice and lower
prices for applications both work to the OS
supplier’s advantage. The OS supplier can en-
courage applications through attention to the
application suppliers’ needs with good docu-
mentation and support.
Basing pricing on consumer surplus rather
than costs has a fundamental challenge: Will-
ingness to pay is different for different users.
To maximize revenue, value pricing implies
price discrimination (basing unit price on
something other than the marginal unit costs
incurred on a customer’s behalf). Approaches
include segmenting customers into groups and
charging different prices (for example, student
discounts) or negotiating prices directly (for
outsourced development or large site licenses).
A common approach with strong design impli-
cations is creating different product variants,
all available for sale at the same time, and let-
ting customers self-select on the basis of their
willingness to pay. To support this, the design
must explicitly allow different combinations of
feature and performance sets that are not user
configurable. For example, the lower-price stu-
dent edition of some applications doesn’t make
use of a floating-point unit, thus lowering per-
formance. Of course, designers must trade this
flexibility against long-term maintenance and
support costs, which grow with the number of
variants and perhaps even the number of com-
binations of configuration options.
Another value-pricing strategy is bundling,
or packaging different software products or
feature sets to sell as a unit. The dispersion in
value attached to the bundle is often less than
that of its constituents because different cus-
tomers place the highest value on different con-
stituents. So, there can be a higher bundled
price relative to its constituents. If the bundler’s
constituents are composable—the whole is func-
tionally greater than the sum of the parts—the
value increases further. An example of this
would be the exchange of information and its
formatting among the components of an office
suite. In anticipation of bundling, the design of
individual products—both internal and exter-
nal—should anticipate opportunities to com-
pose its constituent products.
Reducing customer costs
Reducing customer costs (other than for
software acquisition) is generally desirable. In
choosing a software vendor, customers will
consider many factors besides features and us-
ability. Some factors, such as the cost of hard-
ware maintenance contracts, are largely sepa-
rable from the software design, but most
interact strongly with the design. For example,
the design of software targeting an organiza-
tional user often presumes internal processes,
either limiting market share or causing cus-
tomers to make costly modifications to busi-
In software,
large first-copy
costs make
unit cost
loosely
dependent
on unit sales,
so costs offer
little insight
into pricing.
64
IEEE SOFTWARE www.computer.org/software
ness processes. Thus, to match variations in lo-
cal needs, it’s important to focus on processes,
process-change costs, and flexibility to meet
process differences across the customer group.
An example is the modular options provided
by enterprise-resource-planning vendors such
as SAP.
Another category of costs is switching
costs, which customers encounter in moving
from one vendor’s product to that of a com-
petitor. Switching costs are a form of lock-in
that let the original supplier charge a higher
price for upgrades, maintenance, and sup-
port.
4
An example might include a customer
who must replace complementary products and
infrastructure or else incur costs in losing or
transforming data. (Of course, locking in exist-
ing customers has the unintended consequence
of discouraging new customers, who will likely
notice switching costs consciously incorporated
into the design by the supplier.) All else being
equal, a design should maximize switching
costs for customers moving to competitors and
minimize them for customers moving from
competitors. An example is providing transla-
tions from (but not toward) the data formats of
competitors’ products.
Customers are aware of lock-in; they are
concerned not only with competitive options
but also with being stranded with a supplier
who abandons maintenance and upgrade or
goes out of business. Presenting a credible
roadmap for future product evolution is help-
ful, especially when the customer perceives
considerable switching costs. Such a roadmap
should be an integral part of product planning
for marketing as well as for internal purposes.
Customers increasingly resist large mono-
lithic applications, which minimize a cus-
tomer’s integration costs and the need for sup-
port from the supplier but which also constrain
available functionality and incur greater switch-
ing costs. The alternative is modular solutions
with options for mixing and matching prod-
ucts from different suppliers, or modules from
the same supplier (the reverse of bundling).
For example, enterprise-resource-planning ap-
plications typically provide many configura-
tion options as well as the ability to choose ca-
pabilities or interoperate with other vendors’
products. A major strategic-planning issue is
thus whether or not to embrace or resist cus-
tomer-configurable modularity, open inter-
faces, and complementarity.
Increasing vendor cooperation
Encouraging complementary solutions from
other vendors increases value, although with
little differentiation from competitors who can
exploit the same complements. Two ways to
encourage complementary solutions with seri-
ous business implications are standardization
and APIs. A standardized interface can open
competition on both sides of an interface,
whereas an API encourages complementary
extensions while trying to maintain a propri-
etary position on one side. Choosing whether
to offer an API or participate in standardiza-
tion is a technical choice with serious business
ramifications.
Architecture.
This phase of project planning
determines the boundaries of competition and
complementarity.
7,8
This is also the stage when
most economic considerations arise.
9
Because
the boundaries of firms must align with recog-
nized interfaces, these architectural boundaries
must also be consonant with the organization
of firms in the software industry. Does indus-
trial organization determine large-grained ar-
chitecture, or vice versa? Large firms tend to
define the architecture, whereas small firms
position themselves within an architectural
niche. Architectural control can be a competi-
tive advantage, so the way a supplier acquires
and retains it is an important strategic issue.
At the coarsest grain, software has a layered
architecture, as Figure 1 shows. At the top are
various applications, and at the bottom are
various technologies, each evolving fairly inde-
pendently because of homogeneous, integrative
middle layers.
3
Moving down the layers, prod-
ucts become less application-specific but more
technology-dependent; strategy depends on the
May/June 2004
IEEE SOFTWARE 65
Integrative layers
Application components and frameworks
Applications
Processing Storage Communications
Technology-specific stacks
Figure 1. Top-level
software architecture.
supplier positioning within this stack. Those
near the top and bottom can more readily dif-
ferentiate products from competitors because
of the diversity of user needs and the diversity
of technology possibilities. Homogeneous mid-
dle layers offer higher value (network effects
again), so differentiation of features or function-
ality within them is a challenge. Structurally, no
supplier provides a total solution, but composi-
tion and integration with other layers are neces-
sary to provide value to customers, and coordi-
nation is essential.
Composability is also established architec-
turally. This requires both interoperability (shar-
ing data and participating in shared protocols)
and complementarity (having functionalities
that work together). Composition can be ex-
plicitly built into the design—for example, in
integrating infrastructure layers—or can be
opportunistic at deployment (making compo-
nents capable of assembly but still designing
them independently). The latter is far more
challenging technically and organizationally
but offers considerable value.
APIs.
Open APIs invite extension through
complementary products or context-specific
add-ons by the user. However, they also cede
market share in the interest of encouraging in-
novation, broader choice, and customization.
Openness refers to documentation and right of
use without explicit business arrangements or
encumbrance by intellectual-property rights.
An API creates an implicit, long-term obliga-
tion for customer support. For example, Mi-
crosoft’s VBA extensions to Office include an
effective obligation to maintain and support
that capability for the product’s life.
Standardization.
Open interface standards usu-
ally arise from industry standardization or de
facto from market success followed by broad
industry acceptance. An open interface is usu-
ally two-way, creating mutual dependence and
supporting competitive options on both sides.
A third approach to composition is explicit in-
tegration of components that a supplier or in-
termediary acquires in the marketplace.
Proprietary solutions offer greater opportu-
nity for innovation and differentiation from
competitors but can cause customer concern
about both lock-in and fewer complementari-
ties. Adherence to standards makes market
success more predictable, particularly in en-
suring interoperability with complements, and
is popular with customers. However, such ad-
herence gives the customer an opportunity to
mix and match solutions from different sup-
pliers, thus increasing competitive pressures.
Standardization processes have become an in-
tegral industry-coordination aspect of soft-
ware engineering.
Cost
A customer’s costs indirectly affect a sup-
plier’s revenue through unit sales or feasible
pricing, but the supplier’s costs directly reduce
margins. These costs include first-copy devel-
opment and testing, distribution, customer
support, and recurring development (mainte-
nance and upgrade), all strongly impacted by
the software’s design. Marketplace factors—
such as the chosen distribution platforms and
methods, reuse strategies, and make-or-buy
decisions—strongly influence these costs as
well. There are trade-offs between supplier
and customer costs; for example, increasing
expenditures on support and maintenance can
reduce the customer’s internal administrative
or user-support costs. The effect on margins
depends on how reduced customer costs trans-
form to higher revenue, either through higher
unit prices or increased unit sales. There are
also opportunities to minimize supplier costs
at the organizational (as opposed to project)
level through resource sharing, software reuse,
and buy-or-make decisions. Three important
market-related cost factors are platform and
distribution, recurring costs, and reuse and
multiple use.
Platform and distribution
Any software distribution defines the scope
of potential customers by targeting an infra-
structure platform (a set of capabilities assumed
to be available and static) and complementary
software assumed available.
3
Porting and main-
taining software for more platforms can in-
crease revenues but can also increase develop-
ment, maintenance, testing, and support costs.
Portability through language and platform
choice can mitigate some costs. However, it also
demands more of each platform (assuming a
built-in virtual machine) and homogenizes the
infrastructure, making it more difficult to
promulgate new infrastructure capabilities. Re-
moving dependencies on assumed complemen-
tary software increases reach, but correctly in-
66
IEEE SOFTWARE www.computer.org/software
An open
interface is
usually
two-way,
creating mutual
dependence
and supporting
competitive
options on
both sides.