Becoming a Platform

By Paul Young March 04, 2010

Making a platform play is hard, and most companies fail – how many of us have added “API” or “SDK” to our roadmaps and been unsatisfied with the results? Let’s explore what makes a product succeed or fail as a platform, and the decision criteria you can review with your business as you decide to commit resources to a platform project.

I have led platform building projects at several companies, including my current role. At each, we had an in-market product with an established customer base, and some number of interested 3rd party developers who wanted to extend our product with their own ideas. Some of those projects failed, and some are (or will be) very successful.

Why Be a Platform

The allure of becoming a platform is easy to understand: your product gets the benefit of other companies investing time and treasure in extending its functionality for you. Platforms are even more interesting when you factor in their positive feedback loop – as more developers add their products to your platform, the value of your platform increases to customers and attracts new customers, which increases the value of the platform to developers, in turn attracting even more developers. Eventually, your platform has such a rich set of unique applications and services available through it, that customers have a hard time imaging getting the same experience through any other source. They’re effectively locked in, not through force, but by choice.

Planning a Winning Platform

As you build a platform, you quickly understand that you have a new set of customers with new problems you need to solve: your development partners. The brass ring that every company reaches for with a platform is OPM and OPT: Other People’s Money and Other People’s Time. Some have made it work. Others have failed miserably.  Many just fade into obscurity.

Platforms grow up in two ways: out of existing products, and as developer-to-developer programs. Platform programs are dangerous because they are usually under-stated in time and resource commits – they have the potential to touch every part of your existing spaghetti code. The urge in the development team to re-architect during a platform build is irresistible. Product Managers: talk to potential partners, understand their needs and desires to work with you, find out which objects they want to interface with, and facilitate discussions between their developers and your development team.

Just as important when planning your platform is to understand your business strategy. Me-too platforms almost always fail. Look at your platform from your potential development partner’s eyes:

The value of your platform to a partner and the likelihood of their developing to it is directly proportional to the amount of business the partner is able to capture through the platform.

Questions to Answer

  • Are you building a platform as a competitive blunt, or to extend your core product?
  • Does your company have the development resources to build a strong and deep API and SDK?
  • Does your company have the development resources to support partners with integration questions
  • Does your company have the marketing resources to publicize your platform?
  • Can your product management team handle a massive increase in communications to partners whenever you make platform revisions?

Strategic Decisions

Business Model

Companies build platforms for two reasons: to increase sales of existing products (e.g. iPhone), or to make money on applications sold through the platform (e.g. Steam) – sometimes both. One of the first decisions you need to make is will your platform be for free or for fee?

Free usually doesn’t mean that all partner apps are free, otherwise they’d have no incentive to develop, rather that the developer has the option to offer free functionality through the platform. You can see this model in action today in the App Store, with free apps vs. their “pro” upgrades. The advantage to free is that end users get functionality at no cost, which entices them onto the platform. If you sell the platform, like, you can use free partner services to add value to your core app and sell more at no direct cost to you or your customers.

Another common model is revenue sharing. In this model, the partner sets their own pricing and the platform owner takes a share of the top-line revenue. For example, Apple takes 30% of all apps sold through iTunes. You have to strike a delicate balance between the amount of sharing you demand from partners and the incentive for partners to develop through the platform.

Packaged resale is a model that we are using at Dell. In the packaged resale model, we purchase apps in bulk from our partners to provide them with stability. We setup volume tiers, much like a traditional distribution model with price breaks as we move up. Then we turn around and repackage partner apps to our customers, pricing them as we see fit to be competitive. The advantage of this model is that you get more control and flexibility with the pricing of apps through your platform. The downside is that partners may fear losing control of their pricing models.

How open will your platform be? Will you adopt a model of being an “open field,” meaning that there is a relatively low bar a development partner must pass in order to offer their application? Or will you model your platform after the “walled garden” that is Apple’s iTunes App Store – and require that partners meet certain guidelines for functionality? Or will you be more restrictive still and have an invitation only “planned community” approach?

The open field model means that you want a high volume of partners and you want to offer them low-to-no touch. Salesforce has used this model to great effect, attracting thousands of independent developers to their platform.

The walled garden approach raises the bar for partners to enter your platform. It may mean setting guidelines about what applications can or cannot do, like Apple has done. Depending on how strict the guidelines you set, you can throttle partner demand – just be consistent in your application of the rules.

A planned community is another approach to platform building. In this model, you go for quality over scale. It may mean setting very strict requirements that partners must meet in order to play on your platform, such as security or functionality requirements. The tradeoff is that you as the platform owner have more control over what is offered through the platform, and can stand behind any partner offering. This model may be appropriate for co-delivered services or SaaS.

Customer Ownership and Branding
By virtue of owning the platform, you are bringing customers to the table. Depending on the model you choose above, you may allow developers to use their own brand, co-brand, or re-brand partner apps as your own.

If you are co-delivering a service through your platform with partners, co-brand or re-brand works well. This model is popular with telecommunications companies who use their broadband platforms to offer re-branded partner services such as online backup or anti-virus.

Factors for Success

As you consider launching a platform, there are key metrics you should consider. Number of partners, number of applications or services, revenue derived from the platform are all good starts. Even before you set metrics, there are some key success factors that you can whiteboard that will let you know at a high level if your platform will fly. The most important consideration that will make your platform succeed or fail is how much business a potential partner can capture from the platform. All of your other strategic decisions must line up to the reality of this number.

Next is the strength of your target partners. Depending on the platform model you choose, you may be targeting anyone from individual developers to large, established ISVs. The key is that you match your target partners with the level of investment required by a partner to develop to your platform.  You can’t ask independent developers to operate a service out of SAS70 Type II data centers, for example.

Consider the problem that end customers solve by buying partner applications or services through your platform. If there is marginal added value to buying through you, your platform will not be sustainable and you will churn customers, and eventually collapse. Remember when every new PC you purchased had an AOL icon preinstalled on the desktop?  There was no value to customers in purchasing AOL this way, in fact it annoyed most people to see it there, and created a negative perception of the “platform (the PC).” You don’t see that as much anymore. You have to add something other than a channel to the customer – Apple adds a great user experience, Saleforce adds great analytics to hard-to-manage data, Steam offers digital gaming management so you never have to find a CD again.

Finally, if you have created value for the customer, value for the partner, and settled on a model that makes sense, you are ready for the last analysis: how will you and your partners make money? Is there enough margin to revenue share – or are you willing to forego revenue sharing and offer your platform for free to partners in order to get more apps or services in order to move more of your core product? This analysis is hardest and will require talking to lots of potential partners and field testing your pitch.

Good luck, and let me know how it goes.  Happy platforming.

Categories: Strategy
Paul Young

Paul Young

Paul Young oversees the strategic development of Pragmatic Institute’s portfolio of products and leads the executive team in the evaluation of new product opportunities. He also manages the instructor team. Paul began his career as a software developer and has worked in startups and large companies across B2B and B2C industries, including telecommunications and networking, IT and professional services, consumer electronics and enterprise software. He has managed P&L lines for products with hundreds of millions in revenue, and faced difficult choices about which products in the portfolio to retain and which to kill. Reach him at

Looking for the latest in product and data science? Get our articles, webinars and podcasts.