MAD SQUAR DRAFT

[FAILING…TO UNDERSTAND THE CHALLENGE]

What was once simply regarded as the ambition to found a business has
now become utterly fetishized by startup culture. New terms such as
‘Wantrepreneur’ have emerged as a response by those who feel the act of
building a business has been commoditized into so many podcast series,
ebooks and methodologies geared towards the challenge of defining an
idea and getting it to market with as little cost (and perhaps even effort)
as possible.

“Fail fast”, “fail well” and “fail forward” are prescriptions for
procrastination: Getting a business off the ground is but a matter of
pulling together the bare minimum requirements and ‘testing’ on end
users. You gather feedback, consider it carefully and plan your next
iteration. The pragmatism of this approach fails to address the lived
realities of individual stakeholders and the fact that there are real costs
associated with failure, whether they be direct or indirect externalities.

For example:
 Failure can diminish your trust within an industry and among peers
 Failure can erode relationships among early backers
 Failure can lead to alienation from the community you aim to serve
 Failure can implicate other businesses, generating costs or loss of
value thereby foreclosing any possibility of further collaboration

This is not an argument against the principle of iterating towards a goal.

Agile coaches quote the scientific method when talking about iteration
and testing – indeed, the approach should be rigorous, accountable, well
executed and documented. Rather this is a call for closer consideration of
the impacts of your early actions on future iterations of your project.
There are certain design challenges that can and should be addressed in
advance of engaging with end users or partners. This is especially so if
your ambition is to launch a platform-based business.

[BUILDING PLATFORMS]

It is said that everything and anything that has potential to be made into a
platform soon will be. Building platforms is a tricky business. You may be
familiar with some of the challenges – most have heard of the idea of
network effects, for example. You may also be familiar with winner-takes-
all scenarios that have played out between operating systems, social
networks, cloud services and digital media. Some businesses become
market leaders in a flash, leaving others scrambling to keep up with the
accelerating evolutionary clock-speed of their industries.

For incumbents there is the promise of the open enterprise, which centres
on the idea that established businesses will begin packetizing certain
services, products and functions, adding interfaces that allow plug-and-
play or arms-length relationships with complementary businesses. Some
businesses, particularly those selling Saas solutions, may even pursue a
hosting strategy whereby they enable customers to purchase and
integrate with competitor services from within their own platforms. This
turns competition for markets into competition within markets, increases
the value of the overall ecosystem and reduces search costs for
customers.

Whether you are a founder or leading your business’s digital

transformation, the idea that you can simply iterate away until your
platform concept sticks is at best optimistic. But why, you may ask? The
founders of Alibaba, JD, Tencent, Bytedance, Apple and Facebook all had a
vision, started with an idea and grew it into the complex multi-sided
platforms we see and use today. Well they had to overcome certain
challenges (actually these are yet to be resolved):

 Conflicts between open sharing and data privacy

 Failure to apply effective quality control on marketplace goods
 Difficulty moderating and censoring user behaviors
 Allowing self-serve ad tools to be used to politicize content
consumption
 Creating tensions between network complementors (developers,
merchants) via uncompetitive or prohibitive pricing policies

Whether it be Tencent being pressured into capping the duration a child

can enjoy its mobile games, micro video services being forced to censor
videos of women eating bananas provocatively or WeChat disabling
content tipping following complaints from Apple of embezzling the
proceedings of ‘in app payments’, the world of big platforms has created a
number of big problems that would surely be unsurmountable by a startup
or crack team with limited resources, time, data and experience. Also
consider that a platform’s decisions will be scrutinized against precedents
that have already been set by these first-movers.

[PLATFORM STRATEGY – FROM TOP TO BOTTOM]

To get a grasp of the strategic challenges of platform-based businesses,

we first need to define what a platform is and to consider the different
ways we can strategize for platforms.

A platform is a software-based system that provides a range of functions

and resources to enable exchanges of value between users. These users
interact, supply and consume value across a multisided network.

The world of platform strategy can be divided into three interlocking

layers:

Business & Brand Strategy (Market layer)

The logic by which your platform-based business operates in the market.
how you partner or compete for market dominance and make use of funds
to invest, divest, acquire or merge with other entities.

Governance Strategy (Interaction Layer)

Platforms grow when people use them to transact, exchange and build
value on top of shared resources. There need to be controls in place to
steer, or “orchestrate” participant behaviors in a way that generates
mutual value. There need to be incentives in place to get complementors
involved (developers, game designers, drivers, couriers).

Most challenges relating to scale can be tied back to an oversight or

conflict in governance.

Architecture Strategy (System Layer)

Architecture enables business strategy. This point is often overlooked – it
can be hard for founders and non-technical individuals to understand how
nuts and bolts enable or undermine the ability to pursue certain paths as
the platform grows (or the ability to grow in the first place) but the reality
is architecture is not a purely technical concern.

[GRAPHIC 3 TIERS OF STRATEGY]

…

It is vitally important that these three layers of strategy are accounted for
at the earliest possible stage of the project roadmap. The reason for this is
because they need to interlock. It doesn’t matter what your business
proposition is, if your architecture is out of whack you will end up in a
position where you either need to rearchitect and destabilize the entire
business, or make a significant pivot. If you don’t have house rules, a clear
incentives and pricing structure in place, you won’t attract users or
complementors and growth will stall.

Before looking at how considerations of architecture and governance

influence platform business and brand, let us get more familiar with the
basic decisions and levers one can draw on.

[ARCHITECTURE STRATEGY i.e. “Loosely Coupled”]

Platform architecture is the fundamental design blueprint of the platform,

it is the sensemaking aspect of a complex system, whereby one can
understand how each system, interface and data flow interacts. Aside
from the description of the platform itself, there are of course the objects
of the architecture plan, the actual ‘stuff’ in the platform. It is equivalent
to architecture in that there is a plan, and the thing the plan describes,
but the big difference with digital platforms is that some things are very
stable, and some things may change on an annual basis (it’s not likely you
would want to start tearing down the walls of a new office block, but a
multipurpose space would be designed from the outset to allow for the
easy rearrangement of room partitions).

The most stable aspect of a platform is its interfaces, known as application

programming interfaces (APIs). These allow a platform’s core systems
(shared resources) to be drawn upon by complementors (app developers,
merchants, game designers). Interfaces allow platform owners to keep
their internal workings obscured. Likewise, complementors don’t need to
disclose the workings of their systems to the platform owner (who may
attempt to appropriate their creations turning them into platform
features). APIs enable quick, efficient plug-and-play relationships to be
maintained – all you need to know is how to format the request and
receive the output.

There are 4 desirable properties in any architecture. The architecture

should be:

SIMPLE
Comprehensible and conceptually decomposable into its major
subsystems. It is possible to clearly identify dependencies and explicitly
show which elements are able to be reused/drawn upon by different
parties.

RESILIENT
A failure in one part of the platform should not cascade to bring down the
entire system. Systems and third-parties drawing on platform resources
should be ‘loosely coupled’ with the platform.

MAINTAINABLE
Changes to the platform are cost-effective, and do not disrupt the
functioning of complementors or other internal platform sub-systems.

EVOLVABLE
It is possible to add new systems and functionality that wasn’t originally
planned for. The platform is stable and extensible. Consider how WeChat
introduces new functionalities without disrupting the core social
messaging experience (there is a specific sub-set of strategies for
effectively launching new feature sets including blue-green deployment
and a/b deployment).

[GRAPHIC EVOLVE]
…

These four desirable traits amount to a microservice-based architecture in

the majority of cases. In a traditional enterprise architecture, services are
coupled (‘entangled’ may be more precise) to each-other making it
difficult to understand dependencies and maintain the system.
The principle of a microsystem-based architecture is that key services are
neatly partitioned, with each owning its respective data. When one service
fails, the overall system isn’t compromised. Taking an ecommerce
platform as an example, the [customer order] service, [payments] service
and [inventory] service would be separate – if the payment service fails,
data from orders and inventory would continue to be updated
uninterrupted.

[GRAPHIC ECOMM SYSTEM]

APIs allow systems within a platform-owner’s architecture to talk to each

other. As mentioned previously they act at the interfaces through which
complementors will gain access to shared, highly-reusable platform
resources.

For non-technical readers APIs are important in so much as not having

them in the right places in the right format will undermine certain
business strategies. They are also important as a productizable
component of the system, and there is a growing body of literature on API
strategy that covers how to bring a product mindset to an API, how to
redeploy internal-facing APIs as external-facing (monetizable) services and
how to improve developer experience through well-designed user
interfaces and documentation among other things.

A simple metaphor will help to explain the role of an API. When you go out
to eat, you don’t walk directly into the kitchen, open the fridge to see
what is there and then make a request to the head chef. What you do
most often is sit down at a table. A menu is presented to you. You make a
selection from the menu and convey the choice to the waiter. They waiter
takes this information and passes it onto the chef. If you’re unlucky the
chef will tell you they’re all out of ceviche. In this scenario, the API is the
waiter. Your order is a single API call, and it is appropriately formatted for
the chef to interpret and provide a response (your meal).

There are other decisions that impact platform architecture including

whether to use on premise, cloud, or hybrid cloud solution to maintain and
run your platform systems. There are also some important technologies
including containers, which are essential for implementing microservices
with reduced overhead. More technical considerations are beyond the
scope of this article.

[GOVERNANCE STRATEGY i.e. “Highly Aligned”]

Governance encompasses the formal mechanisms and soft power/cultural

influences that the platform owner establishes to guide – or ‘orchestrate’ –
ecosystem complementors’ actions. Without governance and alignment, it
is hard to manage the user experience and value exchanges that takes
place across the platform. Architecture enables platform-based value
creation from a technical standpoint, but whether participants exercise the
opportunity to innovate and create value is something that will only be
determined by governance.

The ideal governance structure is one that is:

SIMPLE

Easy for all to understand

TRANSPARENT

Explicitly documented and accessible

REALISITIC

Can be enforced by the platform owner

FAIR

Is consistently applied to all platform participants regardless of status or

agenda

[THREE KEY LEVERS OF GOVERNANCE]

There are three key sets of decisions that can be made relating to
governance:

DECISION RIGHTS
The division of authority and responsibilities between the platform owner
and its complementors.

CONTROL MECHANISMS
A portfolio of mechanisms that are used to filter what kinds of apps,
services, content etc. can be distributed.

PRICING
How revenues are collected and how proceeds are distributed between
the platform owner and complementors/creators.

[GRID 3 ICONS]

[DECISION RIGHTS]

A platform – much like a business – has a strategy, a roadmap that

includes a range of executable instructions relating to what gets built, how
the value proposition should be delivered, and to whom it should be
delivered under what circumstances. These same decisions also apply to
platform complementors, for example, app developers. An app has its own
roadmap and a commercial agenda to pursue.

While you may assume that “the person who builds it should decide what
happens to it”, decision rights are not set by default - they are to be
defined by the platform owner.

Platform Strategic Decision Rights:

The authority and responsibility for specifying what the platform must
accomplish.

Platform Implementation Decision Rights:

Decision rights representing how a platform actually accomplishes given
objectives.

Complementor Strategic Decision Rights:

The authority and responsibility for specifying what the individual
developers or platform contributors must accomplish.

Complementor Implementation Decision Rights:

How a developer or platform contributor should go about it i.e. technical
execution decisions

The decision rights for an OEM-controlled connected car platform will sit in
sharp contrast to the decision rights for a blockchain platform. The OEM
will assume total control over platform strategic and implementation
rights, perhaps allowing developers some control over their own strategic
decisions (monetization and pricing in particular), but again probably
controlling how mobility apps are implemented in the system.

Blockchain platforms were originally conceived as decentralized

organizations where strategic decisions were made based on consensus
between platform participants. This has changed somewhat with ‘voting
rights’ being granted in proportion to the individual’s stake in the
platform. In principle, the decision to fork a project, or make any
significant change to the roadmap is decided by the community.

[GRAPHIC]

[CONTROL MECHANISMS]
Control mechanisms can be formal or informal and relate to how the
platform owner exercises control over platform participants to steer
activities towards positive outcomes for the platform and end users.
Control mechanisms are an essential suite of tools in the orchestrator’s
toolbox, providing a means to distribute penalties and rewards based on
specified set of guidelines or house rules.

These mechanisms include:

• Gatekeeping
 • Metrics-based moderation
• Process standardization & compliance
• Brand & culture

GATEKEEPING

The extent to which predefined criteria must be met in order to participate

in a platform:

• Applied to end-users & complementors e.g. developers, advertisers,

merchants etc.
• Participants must submit proof of meeting criteria via an approval
process
• Decisions may be final or reversible e.g. one may ‘reapply’ once
criteria are met or lose their status if they fail to meet the
requirements

Requirements:
• Criteria are clearly documented
• Criteria are considered to be fair/acceptable by platform participants
• Approval process is efficient and consistent

METRICS-BASED MODERATION

How the platform owner uses data to manage activities and contributions
made on/to the platform:

• More likely to apply to complementors e.g. developers or

service/content creators
• Quality control could be manual, automated or a mix of approaches
• Complementors can be penalized or rewarded

Requirements:
• Performance targets must be explicit and objectively measurable
• Participants must have visibility of their performance via open data
dashboards

PROCESS STANDARDIZATION & COMPLIANCE

The extent to which the platform owner administers explicit instructions

and guidelines to which complementors must adhere:

• Could be geared to users or complementors e.g. procedure for

refunds in a marketplace
• Often used in self-serve ad tools – preserve end user experience
• Key for app stores/mini programs – submitting new experiences to a
platform

Requirements:
 • Clear documentation
• Not prohibitive to developers’ freedom to pursue own goals –
time/complexity

BRAND & CULTURE

The extent to which the platform depends on shared values, norms and
vision to guide actions/behaviors:

• Can be informed by branding/messaging

• Often requires close alignment with a specific audience or
community
• Not possible to prescribe – grows over time through showcasing and
reinforcing positive behaviors

Requirements:
• Consistency in messaging
• Cases/reference points and showcasing of contributions

[PRICING]

Pricing is an important strategic lever as it is the way in which a platform

owner incentivizes participation from third parties. There are a number of
decisions that fall under pricing:

• Whether pricing should be symmetric or asymmetric for each side of

the platform
• If asymmetric, which side should be subsidized and for how long?
• Is pricing based on usage or access?
• Are revenues split between complementors (merchants, app
developers) and the platform?
• Are contributions fixed or based on a sliding scale?
• To what extent are complementors able to set their own pricing?

PRICING SYMMETRY

The decision to monetize one side, multiple sides or no sides in a platform.

Duration is also an important consideration.

• Includes both monetary and non-monetary subsidy in the form of

developer tools, SDKs or access to third-party services at a discount.

Requirements:
• The platform may decide to keep subsidized pricing discreet or
market subsidy as a specific time-bound onboarding campaign
• Changes in pricing must be clearly communicated to the user base
• Subsidies are more of a requirement in competitive markets where
such behaviors are already in play
PRICING SCHEDULE

Whether pricing is based on fixed term access, or usage

• Very common in the B2B SaaS space where a platform may address
the needs of a variety of user profiles e.g. freelancers, SMEs and
enterprises.

Requirements:
• Tiered pricing schedule with the respective benefits of each
• A way for users to measure usage/subscription status
• Option to purchase as an annual package or pay-as-you-go
(monthly)
REVENUE SPLITS

How are complementor revenues distributed with the platform owner? On

the other hand, are platform profits redistributed to complementors?

Requirements:
• Clear schedule for which fees are levied and how payments are
made
• Revenue statements for transparent reporting
• Determine key thresholds for when the distribution is altered e.g.
sliding scale, or benchmarks for when performance bonuses are
triggered.

COMPLEMENTOR PRICING

Are complementors free to determine their own pricing schedules? Are

they able to offer in-app purchases or add-on service upgrades alongside
payment for access to the product/service?

Requirements:
• Balance the trade-off between enabling competition and
undermining the experience for end users, especially if the platform
is intended as a value-added service.
• Consider how to moderate pricing for third party apps/services that
directly compete with platform-owner offerings

[TYING ARCHITECTURE AND GOVERNANCE BACK TO BUSINESS

AND BRAND STRATEGY]

In the lifecycle of a platform-based business there are going to be three

major phases through which the team must pass:

Launching
Broadly speaking this includes establishing the core value proposition,
effectively conveying the proposition to the market and testing it with a
series of beta users across key target audiences (for example businesses
or individual end-users), iterating and eventually, going public with the
offering.

Architecture Influence on Launching:

Given the degree of uncertainty, in the early days of your platform
initiative you will want first and foremost to get it working, and secondly
to do so while maintaining as much flexibility and independence between
systems as possible. If there is an issue with a certain sub-system or you
discover a better way of doing things, you can swap and switch without
needing to refactor or start from scratch.

Governance Influence on Launching:

If your project is being launched within a notable organization you may
have some negotiating leverage and an ability to attract complementors
despite the nascence of the proposition (e.g. OEMs have large addressable
markets). As a startup, governance is really a question of talking to
potential complementors (developers, professional content creators,
service providers), understanding their needs and reservations, and
creating a framework for participation that is equitable and lowers risk on
their side. For example, as a developer you wouldn’t want to create for a
new platform unless the incentives to do so were high (perhaps an upfront
advance of revenue) and/or it is feasible to build with technology that
makes it easy to multihome between platforms, thereby protecting
against failure of the platform to get traction and grow.

Scaling
Once you have some confirmation that your proposition is connecting with
an audience (market fit) your goal is to increase the size of the user base.
That doesn’t necessarily mean your platform must reach billions of
people. Rather it is a matter of ensuring that an average user is able to
derive the proposed value (there are things to buy and people to sell to in
the case of a marketplace), and that the platform owner is able to manage
costs such that

1) the addition of new users approaches zero marginal cost and

2) the fixed costs of the platform can be amortized against platform

revenues. In reality the second scenario is an ideal as there are marketing
costs that add substantial overhead (new user acquisition, ongoing
subsidies and reactivation incentives to name a few line items). In many
cases it’s a matter of attracting investors to bank roll the platform until it
is acquired or expands into an adjacent market by redeploying the same
systems, as in the case of Luckin which could branch out into convenience
foods and urban lifestyle sundries.

Architecture Influence on Scaling:

A neatly partitioned architecture based on microservices that are
implemented with containers will ensure your platform and scale up – and
importantly, down – as and when needed. The main challenge here is
reducing over-provision of computing resources (which can be expensive)
while provisioning for spikes in demand.

Digital media apps are susceptible to downtime from runaway success, as

seen in the case of Korean avatar app Zepeto, which could barely handle
the traffic being generated from Chinese users who went mad for the
selfie-taking possibilities afforded by projecting personalized avatars into
the offline world.

Governance Influence on Scaling:

Platforms are complex systems, and that complexity increases
exponentially as you add more participants. It can be difficult to manage
platform activities by retrospectively applying rules and regulations,
though in some cases platform owners will allow a certain degree of
openness and interpretation of rules to ensure the platform can grow,
then tighten controls at a more mature stage. The point is that the ground
rules need to be set from the start so even with increased enforcement,
there is consistency and accountability. Readers with experience in China
will be familiar with the one-eye-open-one-eye-closed approach.

Surviving
At the most basic level survival is determined by the evolvability of the
platform. It means being able to deliver the intended value proposition but
not foreclosing other opportunities to grow as new needs and ideas
emerge. It means continuously investing in new innovations and reducing
innovation outflows, most often in the form of competitors copying your
feature set. This is why platform-based initiatives require an entirely new
way of working and culture. Once shipped, you need to keep pace with the
market. Developers call it continuous delivery but at the level we are
talking, it simply means that if you launch the platform and sit back, it will
soon enough become redundant – especially if the initiative uncovers a
solid market demand and lacks any sort of proprietary IP or patentable
technology.

Architecture Influence on Surviving:

Architecture is fundamental to evolvability as the extensibility (ability to
add new functions and services) of the platform is dependent on how
services are structured, how easy they are to switch in/out (maintainability
of the platform) and the stability plus availability of interfaces (APIs). If
internal systems and integrating complementors are loosely coupled then
new modifications (and their associated teething issues) are unlikely to
cause too much trauma.

Governance Influence on Surviving:

Surviving means lasting in the market for years – perhaps even decades.
Governance in platforms draws many parallels to governance in
businesses – it’s a matter of keeping people committed to a clear
direction. It’s about knowing when to enable freedom and autonomy, and
when draw the line. A platform lives or dies based on its ability to build
relationships with end users and complementors who contribute value in
unique ways. A thriving, well-governed platform ecosystem is something
no amount of billboards or subsidies can buy. A final important note to
make is that in most markets, the rules are still being defined at the level
of government for how data, openness, transactions and content should
be managed. Platform-based governance is a proxy for an evolving
system of checks and balances that are being articulated at the level of
nations. Many things are still up for grabs, but at the least one should
have an opinion, and learn from the precedents set by other platform
businesses.

SUMMARY

Platform businesses require strategic thinking across three levels: the

level of the business and brand (market), the level of platform governance
(interactions) and the level of platform architecture (systems).

One cannot successfully launch a platform-based business by following a

low-calorie lean “try and see” approach. There are real costs associated
with “failing fast” so where possible, important, potentially irreversible
decisions should be thought out in advance. A range of options exist for
how to enable growth and nurture positive outcomes for end users and
platform complementors however without knowledge of such options,
platform founders may end up accepting defaults which ultimately have a
debilitating effect on the platform, prohibiting future scalability and
survival.