About a year ago I found out I was going to be taking on a brand new role inside of my company. I would be leading a department of three (me, myself, and I) on a quest to help our still young company to “grow up” a bit in the way that we approached building our product. This department, called Product Strategy, would be responsible for developing the frameworks that we used to decide what our product would become, and to evangelize that vision within our company.
The very first challenge we had to tackle was making sure we were all on the same page with where this company was going. We were going through a pretty rapid expansion, experiencing above average growth in customer base and headcount. This increase in headcount included growth in our leadership team. As our leaders grew in their respective roles, so did the number of opinions on what it is we needed to do next.
This isn’t a bad thing — these opinions all highlighted areas of improvement that needed to be made in our company and our product. But before we were going to resolve any of these issues and move forward as a more mature company, we would need to make sure we were all speaking the same language.
The first question — is this a Product or a Platform?
Building a Product
So first off, let’s talk about Products. These are conceptually simpler than platforms, and therefore simpler to develop. You already know intuitively what a product is — it’s something that was created to serve a limited purpose, a specific solution to a specific problem.
Holiday API is a perfect example of this. This is a one-off solution to a problem for anyone who’s had to contend with calendars before. This product provides you with a list of public holidays for just about any country in the world. It solves the problem beautifully too, giving you not only the actual holiday, but the observed date as well. It makes working with any date-based functionality that much easier.
Products are often some of the most pleasant types of software to work with. Because the scope is so small, the developers can focus on making the interaction with that product perfect. However, because the scope of the solution is so limited, it also makes the impact that product can have limited as well.
As great and amazing as Holiday API is, it’s reach can only extend to users who are creating software that require some sort of date based functionality that needs to know when public holidays are occurring, and the end user needs to know how to code. Because I fit that criteria exactly, my experience with the product has been amazing. But the second I lose one of those, the product is worthless to me.
That’s okay though, not every product is going to be useful to every person. It just means that my reach as a business is limited.
Building a Platform
A platform is software that connects products. These are more complex to work with, but the number of problems they can solve becomes broader. This is an important concept, because we shift away from solutions being product-led and towards solutions being user-led. Because of this, we’re not limited to a strictly defined user with a strictly defined problem.
Zapier is a great platform example. It’s a platform with a sole purpose of connecting OTHER products together. Their webpage shows an example of this. When your sales team gets a lead on Facebook, post a notification in Slack, and finally add that person to our CRM. Zapier’s platform isn’t part of any of those products, but it can connect all of them together.
Platforms can be a little more challenging to work with, because of the user led solutions model. This puts some of the problem solving back on the user. However, if the platform connects functionality appropriately, then it means the user can solve many more problems that with a product.
I’ve used Zapier myself, and while getting all of the API’s to work flawlessly can sometimes be a little bit of a challenge, it’s always been due to user error (i.e. yours truly) and not the platform itself. It just took a little more effort on my end. In exchange for this extra effort, I get to automate a near infinite number of workflows and solve an infinite number of problems. The platform can be useful to nearly anyone.
Keep in mind that while this is in theory more useful to more people, it is harder to pull off.
Which to do?
As with most questions, it’s not that straightforward. You can imagine the Product-Platform Continuum as existing on a spectrum, like this:
We have pure products on one side, with pure platforms on the other. In reality, most software applications fit somewhere in the middle.
Think of a product ecosystem. Apple products all work together seamlessly in order to get you to buy other Apple products. If you have an iPhone, you can iMessage on your Mac or iPad as well, making you more likely to buy those products over a competitor’s. Google’s ecosystem is software based instead of hardware, but it’s intent is to keep getting you back to Google search and clicking on those sweet, sweet ads. The most popular phone OS in the world by a wide margin is Android, which defaults you to Google as it’s search engine. Chrome, the world’s most popular browser by far, also uses Google as it’s default search engine. This ecosystem is meant for you to keep using Google search and clicking on Google ads.
Each one of those products above isn’t a pure product or a pure platform, it’s something in between. They all exist as independent products, but they’re also all interconnected into an extended platform.
If you run cloud-based software, it’s almost inevitable that you will find that you have created some sort of limited platform, even if it’s not your intent. It’s difficult to create a standalone product that creates a significant amount of value all on its own.
The Product Evolution
Generally speaking, almost no platforms start life as a platform (they do, but those are rare). Instead, products tend to evolve into platforms, settling somewhere in between each pure state.
Our application is the same. We started life as a well-defined singular product, that over time has morphed into platform of products. Some of the products we’ve created ourselves, and others are 3rd party products.
I want to stress that you shouldn’t equate Product = Bad and Platform = Good. They each have their benefits. Sometimes you just need a holiday api — something that solves a very specific need really, really well. Other times you just need a platform to connect all of your other products together. Most applications just naturally end up being somewhere in between.
P.S. Aristotle
The Ancient Greek philosopher, Aristotle, is often credited with saying, “The whole is greater than the sum of its parts”. As it turns out with a lot of clever sayings from the past, this isn’t entirely true. The actual quote¹ reads,
“In the case of all things which have several parts and in which the totality is not, as it were, a mere heap, but the whole is something besides the parts, there is a cause; for even in bodies contact is the cause of unity in some cases, and in others viscosity or some other such quality.”
In light of what we’ve discussed above, I like this version better. When you’re building your software application, having a platform isn’t better than having a product. After all, since platform is something besides the collection of products, not necessarily better than them.
[1] Aristotle’s Metaphysics, Book VIII, 1045a.8–10, 1908 translation by W. D. Ross
If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.
