What’s in a name?
I think we use the word ‘platform’ because it feels like it hints at some deeper value, suggesting that the product goes beyond the standard value exchange of an app. What we’re saying is “buy into my platform and you can fundamentally improve how your business works. Not only that, but the value you see from our platform will grow over time proportionally to the amount you invest.”
So what does it mean to be a platform? Does the word carry a strict definition in enterprise software, and if so, what is it? Are we all cheating ourselves and our potential customers by calling ourselves platforms when in fact we’re just another ‘product’?
Characteristics of a product
To be clear, ‘Product’ is not the perfect opposite of ‘Platform’. If a product — broadly speaking — is something that can be manufactured or created and sold:
…then a software platform falls under that same definition: a platform is simply a product with some specific characteristics. But for the purpose of illustration, in this article I’ll use the term ‘Product’ to refer to “a product that’s not a platform”.
Rather than clutching at the straws of the language of definitions, let’s look at some products that I think are quite clearly Products — not of the platform flavor:
- Apple Macbook
- Adobe Photoshop
- Spotify
- Tesla Model S
- Super Mario Run
All of the above are products that can be bought for a sum, and are consumed by the user in a value exchange that’s relatively simple. I open Spotify, play some music, receive some enjoyment. I get in my Model S (wishful thinking…), drive somewhere, receive value.
You’ll notice that most of the above examples are considered consumer products. The reason I chose them as examples is because things get a little more cloudy when you try to make the distinction between Product and Platform for business software…
Defining a platform
What comes to mind when you think of a platform? For me it almost always includes a suite of tools, probably some API-based, and a much more complex exchange of value between vendor and consumer. Let’s take a look at some different opinions on the definition of a platform in the software world:
”In construction, a platform is something that lifts you up and on which others can stand. The same is true in business. By building a digital platform, other businesses can easily connect their business with yours, build products and services on top of it, and co-create value.”
”Products are something you can sell or buy, make or lend. Platforms are ways of enabling one product to work with other products.”
(Quora)
“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”
(Bill Gates)
“A product is something you sell. A platform is common infrastructure that you build products on.”
(Quora)
“Platforms are structures that allow multiple products to be built within the same technical framework”
Some platform examples
- Microsoft Windows
- Apple iOS
- Salesforce (App Cloud)
- Amazon Web Services
- Shopify
You’ll notice that many platforms are closely tied to product counterparts. Nike+ – a running & fitness platform is tightly integrated into Nike trainers. the iOS platform is inextricably tied to my iPhone 7.
Components of a healthy platform
Co-creation of value
A succesful platform has the vendor and partners (those building on the platform) working hand-in-hand to create value for consumers. Microsoft works hard to drive value and adoption of the Windows platform, shipping features and updates that will (hopefully) attract consumers. At the same time, developers build on the Windows platform to provide additional value in the form of added functionality, software and media.
Ease of technical integration
A good platform offers a way for developers to build on it, through documented APIs, SDKs and other technical points of communication. A great platform is one that developers enjoy working with, and where any integration friction is minimal.
A healthy ecosystem to service the value chain
Platforms can support a complex economy which must be refined and balanced over time to allow the best value for all parties — the vendor, partner and consumer. Apple’s mobile platform ecosystem is massive in scale and logistically complex, but has been optimized over time to ensure that developers can build healthy businesses for consumers.
In the cloud, everything can seem like a platform
A major reason why a solid definition of ‘Platform’ seems so hard to reach is the nature of could-based computing, or more specifically, SaaS. At first glance, most B2B service-based software looks like a platform. The rise of API-based SaaS has led to an increasing number of services offering integrations with other services, along with APIs to integrate deeply into your own infrastructure. The mere presence of an API and set of integrations sounds like a characteristic of a platform. But is that accurate?
It depends on your definition.
- Slack offers integrations with a huge number of services. Some products are even built on Slack entirely. Is it a platform?
- ChartMogul has a set of APIs for complete unfiltered access – both input and output. Is it a platform?
- Intercom integrates deeply into your customer support process, changing the way you build business. Is it a platform?
During my research for this article I’ve spoken to people answering on each side for the above questions. Here are some of the finer points of debate:
- “It’s not a platform if it can easily be replaced with another product (i.e. it’s not painful for a customer to de-integrate).”
- “It’s not a platform if other businesses can’t make revenue in building on it.”
- “It’s not a platform if it’s part of an existing product.”
What do you think? Please drop a comment at the end of this article!
Why platforms are so attractive
For the platform vendor, there are a number of key benefits in offering a platform over a traditional product.
Flexibility
Where a product supports a reasonably fixed set of use cases, a platform is open-ended from the outset. This allows a multitude of companies to leverage the platform for their (often very different) use cases, opening the door to a much wider market segment. It also allows the vendor to re-use the platform for their own benefit.
Longevity
People buy products, use them for some time, and discard them when they’re no longer a good fit. The narrower your supported use case, the less likely you’re able to keep customers long term. Conversely, platforms are often deeply integrated into the infrastructure of businesses. Integration requires a greater commitment up front, but deep integration means that the pain of leaving is greater as well. Platforms are sticky. This, added to the flexibility mentioned above, means that businesses can generally stick around and adapt the platform to their needs over time.
Network effects
In many cases, the value of a platform is directly proportional to the number of people who use said platform. For example: Facebook. Facebook’s platform — the part of the business that deals with advertising, app building, etc. — relies on a large number of consumers actively using a Facebook account. The more people using Facebook, the more valuable their advertising platform, for example.
Becoming a platform: What it takes
Transitioning to a platform business is fairly common, especially in the SaaS world. It’s not surprising that nearly everyone wants to do it, given the massive benefits of owning the building blocks of other businesses. However, it’s deceptively hard and requires a well-thought-out strategy from day zero.
Harvard Business School outlines three key components to a successful platform strategy:
- Connection: how easily others can plug into the platform to share and transact
- Gravity: how well the platform attracts participants, both producers and consumers
- Flow: how well the platform fosters the exchange and co-creation of value
Which comes first: Product or platform?
There are two very different approaches to building a platform business:
- Platform-first: Build a platform from scratch, without having a product in the first place.
- Product-first: Start with traction for an initial product, expand the scope of the business by transitioning to a platform.
Number 1 is insanely hard. Number 2 is hard, but much more common.
1: The platform-first approach
There’s a reason why most platform businesses start out with a product, which then expands in scope to become a platform for other businesses to build upon.
Platforms are vast in scope, and difficult to produce an ‘MVP’ or ship an early version that covers just a small set of use cases. This means that the upfront cost involved in developing such a system is huge — along with the risk of not shipping anything until you’re done building it. Or if you do ship something, it’s going to feel unfinished, perhaps even messy to your early adopter customers.
Example: Agorapulse
Emeric Ernoult, Founder of Agorapulse, recently published a year in review for the social media management company. Amongst some very candid observations and metrics (it’s a great write-up and definitely worth a read), one part under “Why did it take us so long to be profitable?” stuck out for me:
“Second, we faced the tool vs. platform issue. Take @buffer for example. They started with a simple tool to publish social content without the hassle of manually scheduling each piece (the now famous Buffer “content queue”). It was a very targeted tool just doing one thing great.”
“The tool approach Buffer took was an infinitely smarter way to start a bootstrapped business. As for us, we went straight for the platform vision: build an all-in-one platform for all social media needs — not only publishing, but also listening, managing engagement, reporting metrics, and user management. This was much harder and longer to build. Admittedly, we had a half-baked product for a looooong time.”
We can replace the term “Tool” with “Product” here – what Emeric is describing is a narrow-scoped product that simply solves problems for one or two use cases. The points is the same: Emeric and his team at Agorapulse set out to build a platform from the beginning, with all of the many features expected by its customers. The result was a product that was rough around the edges, or as Emeric puts it, “half-baked”.
Note: If you want to hear more from Emeric on his social media strategy and the story behind Agorapulse, read his interview on our SaaS Open Mic podcast.
2: The product-first approach
From almost every angle, this route makes the most sense — from a business, product, and technical perspective.
As a startup with limited resources and time, you need laser-sharp focus on shipping the most refined, stripped-down version of your product that still delivers enough value for consumers. If you build this ‘v1’ smartly however, you can lay the foundations for what ends up being the ultimate plan for your business: the platform. On the technical design level, this requires a commitment to separation of product business logic from the infrastructure parts of the system, often using APIs to facilitate communication around a very modular system. With this achieved, the next steps to a platform are far less painful — no rebuilding or tearing down existing components.
Example: Amazon
In 1995 (yes, I had to double check too) Jeff Bezos launched Amazon.com as an online bookstore. The bookstore itself played a big part in popularizing online shopping across the U.S. and globally, but as I’m sure you’re aware, this was not the biggest achievement for Bezos and his now-public company.
In order to build such a large-scale bookstore, Amazon required some serious infrastructure which at the time was not easy to provision, manage, or scale to meet traffic demands. So they built it. And this is where the platform comes in. Today, Amazon Web Services boasts over a million active customers, powering a significant proportion of the internet and allowing businesses to generate value worldwide.
Amazon was able to ease themselves into building such a large-scale successful platform by first of all shipping a product. I daresay that building and shipping AWS by itself at that time was simply impossible given the effort of such a project.
Apple’s difficult transition
There are some obvious changes required to make the jump from product to platform – technical architecture, integration support, etc. However, when you dig deeper, it’s clear that such a transition touches every corner of a company, requiring processes, team structure and even culture to take a fundamental shift.
Apple is probably the biggest example of a company that initially defined itself as a product company. Everything in Apple was organized around:
- Developing product ideas in complete secrecy
- Working with project teams to push projects through a rigorous design process
- Working towards a ‘big bang’ surprise launch, coordinated with laser-sharp Marketing
- Supporting products through retail and online channels
- Releasing a new version of the product, a year or more later
*Note: If you want to read more on Apple’s design process, Ashlee Vance’s book on Johnathan Ive contains more detail than I’ve seen anywhere else.
Successful platforms require:
- Open standards and developer-friendly access
- Constant, iterative improvements
- Transparency on almost every level
- Outstanding developer support & documentation
None of the above are things that Apple was historically good at! In fact, they didn’t even want to be good at these things because many of them go against the nature of designing and shipping hit consumer products. Clearly, the company has come a long way since introducing modern developer platforms like iOS. But Apple is still structured as a Product company — it’s in their DNA.
As Ben Thompson articulates so well on his Stratechery blog, regarding the iPad (any emphasis is mine):
“[Tim] Cook’s conclusion that Apple could best improve the iPad by making a new product isn’t quite right: Apple could best improve the iPad by making it a better platform for developers. Specifically, being a great platform for developers is about more than having a well-developed SDK, or an App Store: what is most important is ensuring that said developers have access to sustainable business models that justify building the sort of complicated apps that transform the iPad’s glass into something indispensable.”
“What’s fascinating to consider is that it’s arguable the iPad would actually be in a much better position were it owned by Microsoft: the company is at its core a platform company that has long bent over backwards to accommodate its developers even at the expense of the user experience. That, though, is the rub: in consumer markets the only way to gain the prerequisite scale to be a platform is to first have a superior product, like Apple. More than ever each has what the other needs.”
Steps you can take today
Documentation, documentation, documentation
If you want developers to adopt your platform and businesses to integrate you into their own stack, the onboarding friction needs to be as low as possible. The bar is high when it comes to excellent technical documentation, and the best platform companies out there have whole teams dedicated to this. Onboarding in the developer world usually starts with documentation, so don’t leave this out.
The biggest mistake people make with documentation? They produce it, and neglect to update it. An out-of-date doc is often worse than no doc at all.
Hire a Solution Engineer
Many businesses call them Solution Engineers, or Integration Engineers. Whatever the name, you’ll need a crack-team of technically capable individuals on standby around the clock to solve technical issues and give guidance. It’s a tough role to hire for — these people are a rare breed, often with skills in engineering and software development, yet focused on support. If your SDK breaks or your API returns an unexpected error code, these folks need to dig deep to solve the problem.
Hire a developer evangelist
Developer evangelism can range from publishing developer-focused content about your platform, to hosting a “worldwide developer conference”. It almost always involves handing out free t-shirts at some point. Developer evangelism is built around one premise: If you can convince developers of your product’s value, they’ll promote you internally when the time comes to make a decision on a solution. Developers are your best friend, and your brand needs to build a rapport with them to succeed as a platform.
Restructure your Engineering teams
In the pre-platform world, your product was probably treated as a fairly monolithic entity. You plan and add features to it according to a roadmap, and fix bugs. Not any more! In a platform environment, the product becomes a consumer of the platform, in a similar way to how customers will integrate and leverage the platform. The two things should be as loosely coupled as possible — not only in code, but in team structure. Your platform should have a separate roadmap to your product. Having a different team work on each entity is definitely not a bad idea, if you have the resources.
When it’s time to reap the rewards
With everything above said, the word ‘platform’ is thrown around more often than it actually applies. It’s a buzzword we’re all guilty of using at some point as startups, to position our products with a forward-looking spin and nod toward aspirations for the future.
True platforms are both hard to achieve and require constant nurturing from every angle – product, development, marketing, sales… everything.
If you can get there, what you’ve created is something that carries far more value than a product that solves a single use case. You’ve built something that facilitates whole new businesses to be created, and old ones transformed.
…now get back to work because your API doesn’t have feature parity, and developers are revolting.
