If you think the thing you are building is both an “app” and a “platform” you will fail. Oh, and if you think it’s going to be a just a platform, you will fail too.
(Update: April 6, 2012 – I updated this post with some typo fixes and minor tweaks).
A recent story on Hacker News gave me an excuse to write down my thoughts on this subject. I’m reposting here in order to elaborate a bit more.
The story I’m referring to was on cnn.com: Your startup probably isn’t a platform. In it, the author says a few things I happen to agree with, such as:
Simply having an API doesn’t make your company a platform. Similarly, simply having a piece of software that gets embedded in other products doesn’t make your company a platform; that just means your product is usefully extensible or perhaps your a dev tools business.
I have two points to make on this subject:
- A startup building a product or service that tries to be both an “app” anda “platform” will fail.
- There are very few (if any) examples of successful platforms that started as a platform.
Point #1 – Be an app. Or a platform. But not both!
In my experience, when building a new software based product, teams need to make a choice very early on whether they are building something that is all about end-user value (“an app”) or all about 3rd party value (“a platform”).
Endeavors that attempt to do both lack focus. They don’t do a great job building a great user experience and they don’t do a great job enabling 3rd parties because these two things are in tension. Example: enabling a 3rd party plug-in model requires the creation of UI that is often complex from a user’s perspective. The investment in that UI to make it great (especially at an early stage when you don’t really know what or how many 3rd party extensions will get built) could be better spent on building great end-user-valuable functionality in the core of the product.
You have a limited number of resources that can work on any endeavor. Call it headcount. People who are excellent at creating user experiences, working with design, and polishing pixels are almost never excellent at building easy to use, scalable, and flexible APIs. And of course the reverse is even more true: plumbers can’t paint worth beans. If you choose to be both an app and a platform you will have half the great plumbers and half the great painters you’d have otherwise.
Building something new implies we really don’t know what we’re doing. If we did, it wouldn’t be new. For the engineering of this new thing, we’re going to start with a plan and then dive in and start building. As soon as that thing we’re building gets exposed to a customer we all know that the plan goes out the window.
“No plan of battle ever survives contact with the enemy” – Heinz Guderian
Once that plan is out the window we need to iterate/pivot/refine. Quickly. Both user experience and APIs are difficult to change once coded (APIs are harder). Changing both simultaneously will kill you. Been there. Done that. Got the T-shirt.
This point is all about focus. To be successful startups need extreme focus and choosing to do two things that are in such obvious tension with each other is a recipe for disaster.
Point #2: Don’t be a platform!
Go ahead. Name a few successful “platforms”.
Before you do, for the sake of argument, agree with me that “successful platform” implies the platform has a vibrant set of independent partners who both contribute to and “profit” from the platform. I could also use the term “virtuous platform” which has come to mean a platform composed of a multi-sided market where each side of the market derives value in a symbiotic or virtuous cycle with the others.
The “virtuous platform cycle” that most people use as the prototypical example is the Windows ecosystem. The market sides were: Windows, Intel, OEMs (e.g. Compaq, DELL), IHVs (e.g. ATI, SoundBlaster), ISVs (e.g. Lotus, Adobe, Office), retailers & channel (e.g. Egghead), and of course, end users.
All of these “market sides” drew great value from one another as part of the Windows ecosystem. They all made money, hand-over-foot, because the “virtuous platform cycle” snowballed.
There are many examples of other platforms with a virtuous cycle today. Google’s search engine, Amazon.com, Apple’s iOS, and on a smaller scale something like Minecraft (although that’s a nascent example).
For each example YOU come up with, ask this question: What came first, “end user value” or “developer/3rd party platform”? I struggle to find examples where the platform STARTED as something that was entirely focused on developer/3rd party value. You might argue Java, but then I’d say “in what way did the creator of that platform make any money off the platform?”.
With very, very few exceptions, the existing “platforms” we all know and love started out being primarily about end-user value. Extensibility, APIs, plug-ins, and embed-ability all became important later in the life-cycle.
I turns out the best way to build a platform is to build something that end-users love and add “platform” later. So do that.
Don’t walk away from this with the idea that you can’t do a little platformy stuff as you build your “app”. If you believe extensibility, APIs, plug-ins, and embed-ability are something you want in the future, or if you have a very specific extensibility feature then do it. But do it as a feature. Something that you can cut.
Here’s a personal example. When we built Windows Home Server we explicitly choose to “be an app”. Delivering on our core end user value proposition was the highest priority. But our OEM partners really wanted some extensibility so they could differentiate. So we added to our list of features a simple plug-in model that would allow those partners to have a little bit of configuration UI hosted within the Home Server Console. It was treated as one feature among dozens and was prioritized in such a way that if, push came to shove, we could cut it in order to ship.
“Shipping is a feature too” – A lot of great engineering leaders
Only a small part of the team worked on it for a time-boxed amount of time. Nobody on the team was confused: We were an app, not a platform.
Developer Tools Are Not Platforms
I get a a lot of people asking if something like .NET, Java, Ruby on Rails, or Node.js are examples of platforms that were created standalone. They are not. Because they are not platforms. They are developer tools. In my mind, a developer tool is an app for the developer customer.
This post is about focus. Here are some other posts I’ve written on how to build ventures that are focused:
RSS - Posts
I think the Visual Studio LightSwitch team is doing a good job. They are concentrating on making a product end-users (people making LightSwitch apps) love. The people making plug-ins are slowly showing up…
One example of an incredibly successful platform and app that started as a platform would be Excel.. but I imagine that by ‘platform’ you’re talking more about the extensibility features that only developers would find attractive.
Excel started as an app.
I’m building an PlApp-form.
How about SharePoint or O365?
I think one of the reason SharePoint is generally despised by end users is that the team that created it tried to do both at the same time. Sure MS is printing $$ with Sharepoint, but nobody would say that it makes end users really happy.
I can’t believe you actually asked about O365. Clearly an app.
You’re posting a lot of good stuff lately. Leading up to this weekend’s event, or something else?
The platform exercise is interesting. Just going through the various apps on my phone, none disprove your points, but Dropbox and Twitter stick out to me.
Dropbox has been famously called a feature rather than a product, but it definitely prioritized user experience from the start. If being a great sync platform was the key, Microsoft’s Mesh (or foldershare, or skydrive, etc) would have won. But it’s always _felt_ like a platform to me. It’s just something I use to make all my other apps work more seamlessly, it’s not about the dropbox app(s) themselves.
Twitter is arguably the other way around. They were originally about being a mechanism for mass texting. Their 1st party apps have always sucked compared to the 3rd party stuff. It seems it was their platform strategy that really drove their success.
The best example I can think of that has been both a success as an App and as a Platform is Google Maps. Seven years ago Google Maps was an application only – a Web application for finding things nearby and getting driving directions to them. This was before Google managed their own mapping – they licensed 3rd party technology to power it. It wasn’t until after they launched the Web-based application with success that they exposed an API and javascript for other partners and developers to benefit from.
Charlie, I just referenced your blog in response to Aetna’s rolling out of a platform called Carepass which is supposedly going to enable ease of data transfer among a bunch of third party health and fitness apps to improve the health of members/patients (http://mobihealthnews.com/19311/aetna-to-launch-carepass-for-mobile-in-2013/). Your post is so dead on. They’ve never built anything that the consumer has been in love with but now they want to launch a consumer oriented platform and expect a different outcome. I don’t get it.