Product vs Platform: the Struggle to Make the Domain Boundaries
The importance of differentiating between what platform and what product to ensure the organization solving the right problem.
Hello 👋
It’s been a while since my last newsletter was posted. A lot of things happen in real life. 2024 is a crazy year. From the beginning of January 1st to the end of 2024, it’s a roller coaster life. It’s a good and bad year, good I learned so many life lessons. Bad year, I learned too many life lessons and didn’t have enough time to write new blog posts. Life update! I’m moving to a new company, and it’s been a few months now.
I want to share some thoughts on one of our many problems in this blog post. Please note that this is my personal opinion. I do not represent the company I work with or any group of people. But of course, I bring up this topic because of one of the problems we’re facing in my current job.
One of our most challenging problems right now is defining domain boundaries between the platform and the product in Software Architecture. Fortunately, our senior leadership is moving towards platformization. Simply, platformization means creating a configurable, well-structured system or process that will make it easy for any product team to integrate with each other and, possibly, build new products on top of the existing platforms.
From theory, it may seem easy to understand. A product is anything we sell, feature, or function—anything that solves the customer's problem. The platform is a tool we use to support our product.
Easy, right?
However, it is always difficult to establish clear boundaries between product and platform at the organizational level, where interests, collaborations, team capacity, and expertise will determine the domain boundaries.
Intro
I’m not a product expert, but I have more than four years of experience working on products and three to four years of experience establishing a platform to support company products.
From my point of view, a product is, in simple terms, something we sell to customers. It could be a service, an item, or anything else.
Let’s talk about Payment Gateway (PG). One of the PG products is, let’s say, payment with Direct Debit. In general, Direct Debit is a cashless payment method that will deduct or charge the customer’s bank account directly (Stripe’s explanation). The interface might be different; for example, outside Indonesia, it’s common to use Internet Banking, where the merchant will deduct the user's bank account directly through some validation (MFA, etc). In Indonesia, however, some banks allow Internet banking, and most only allow it through a debit card, which is also directly linked to a bank account (Xendit’s explanation).
From the explanation above, Direct Debit seems like a somewhat complicated product, depending on which country you’re referring to. It’s a customized feature that cannot be generalized globally, especially regarding how it works on the technical side.
Another example I can use is an identity verification service, like Veriff.com. I tried the product when I wanted to verify my document in Deel. Deel is a platform for freelancers that helps with HR and payroll. So, I used Deel for my fractional job. During my registration, I saw that they use Veriff for identity verification.
So, in general concept, Identity Verification works like as simple as:
Ask the user to provide a document
Selfie
Selfie + Document
Verify to Government Registry (if possible)
Get Verified
Done
Different countries may have various ways to validate the document — including different citizen registries. It’s something we can’t generalize globally.
However, the interesting fact is that, from Deel's point of view, Veriff is one of the platforms that helps them verify their customers to support their products. The same goes for Eccomerce or any business that uses a Payment gateway to accept payments from its customers. From Eccomerce's point of view, a Payment Gateway is just a platform. They can replace it with anything, e.g., self-build, change to another third party, etc.
From the words themselves, a Platform is a foundation—it’s the baseline. When we think of building a house, we can use the concrete base, wiring, etc., to compose and create rooms. At the same time, the rooms themselves are the product — which is the result of composing many platforms. It’s not our core product but a critical functionality to support our products.
Platform vs Product in Platformization Vision
Distinguishing between platform and product can sometimes be confusing. You could agree or challenge this, but for me, the simplest way to identify a platform and product in an organization (company/business) is to ask these questions.
Is this a business value that your customers paid for?
You are a business owner selling alcoholic drinks and shipping worldwide. Therefore, you need direct debit from any bank worldwide. Identity verification is also necessary for all people, and government documents and registries must be validated to determine whether the customer is of legal age.
So, from this, your customer pays for the alcoholic drinks you sell. They’re not paying for the Direct Debit feature or Identity Verification. They’re reaching out to you because you sell alcoholic beverages. So, the platforms in this example are the Payment Gateway and the Identity Verification. And your product is the e-commerce that sells alcoholic beverages.
The product is what the customer pays us for. The platform is what we, as an organization, paid for or built to support our product.
Can any products use this?
The next question I usually ask myself when defining the domain boundaries between product and platform in an organization is to confirm whether any product can reuse the component (a service or module, etc.).
For example, Notification. In SaaS companies, eg Payment Gateway or Identity Verification. It must have a notification module to send the notification (email, SMS, or Webhook). Payment Gateway has multiple products, e.g., direct debit, card payment, e-wallet payment, etc. All these products will always send notifications, e.g., payment initiated, succeeded, failed, etc. Even though all those products may have different configurations, it is all just a notification. So, from this example, we can extract the notifications and make them a single platform inside the Payment Gateway. It’s not a product we sell to customers, but it supports the payment products the Payment Gateway sells to their customers.
Here’s the catch: a Platform is not tightly bound to business logic but explicitly built to organizational needs. But if we want to be extreme idealists, a Platform could also be extracted like an external company. So imagine Twilio. It’s a Notification Platform, but it’s a big company. Not only one, but millions of companies are using it. But from the Payment Gateway organization's pov, the notification platform should be something that can be configured easily to all product needs, or worse, can be replaced easily when it’s not aligned with company policy, e.g., cost is too expensive, etc.
The platform is a component that can be reused by any product inside the organization with minimal configuration or changes.
Platformed Product
The Dreams
Okay, we now clearly understand the difference between product and platform. But now, a question may come: Is a product of one SaaS company somehow just a platform for its users? Is it possible to make our product work like a platform?
This is the challenging part. I think this confuses many people and causes them to have different expectations when we say “platformization.” It’s a direction to make the product more configurable and serve all customers’ needs. All business owners, leaders, investors, etc., dream of creating a product that can (magically) solve any problem and allow the organization to expand aggressively. When a product can do this, there’s no competition anymore. We can quickly solve everything in one day and expand aggressively.
Let’s take Direct Debit as an example from the beginning. Direct Debit may take a different approach depending on the bank, country, regulations, etc. So when we say “platformed product,” we mean making Direct Debit a platform that can onboard any new direct debit type and somehow make it configurable. Imagine what would happen if we could do this: We could expand direct debit payments to any country with fewer changes.
Moving in this direction requires much effort, trial, and error. It must not be too abstract, causing the context to be missing, yet not too specific, making it too complicated.
It also requires a lot of discussion and negotiation, including changes to the existing business flow.
It’s hard, but it should not be impossible — at least with fewer changes.
Working in both product and platform areas surely gave me a lot of experience in thinking in a “platform mindset.” I used to think it was impossible to make a product really configurable and solve any new incoming problems because software eventually changed depending on market needs, regulations, etc. So, it’s impossible until I see a perfect example of how a platform works.
An example we can use is how Operating Systems work, both on Mobile and Desktop: Windows, MacOS, iOS, and Android. These are the peaks of the platform. They allow any product to run on top of them, yet they have core OS features. We can write software or plugins to serve our needs on top of them. But it might be possible because it only does a platform job: an Operating system. An OS cannot browse the internet; it needs an application to do that. Or it can’t make a presentation slide; it needs Ms Powerpoint to do that. It extracted all unnecessary functionalities from the core OS and made it possible for everyone to create an application running on top of it. This is a perfect example of what a Platform should look like.
Another example is that let’s see how Kong Gateway or any API Gateway Platform is in the market right now. What I like about them is that they allow everyone to make their own “plugins” on top of the Kong gateway. They also support a configuration-based system for the API registry. People only need to change the kong.yaml config and register a new API for the public API.
The diagram above shows what a platformed product should look like. The product is an “API Gateway,” but it allows everyone to configure it, including adding a plugin to serve a specific use case. So with this, let’s say the company wants to add a new product payment method, e.g., Crypto Payment. Then, they won’t need to add new code to the API gateway; instead, it will be just simple configuration changes, e.g., YAML file changes.
The Challenges
From the beginning of this article, I’ve discussed platforms, products, and platformed products. In my eight years of professional experience, I've encountered challenges, such as people who are confused about what they want versus what others understand.
Some people want the platform to be a support and just an extra tool, a baseline that works like an OS, support plugins, etc. Some say a platform is a configurable product that can solve customer problems with fewer changes. Some say the platform is like a buffet. When I want to build my product, I will pick the building blocks (platform) and compose my product based on customers’ needs on top of all those building blocks.
In my opinion, there is nothing wrong with all those statements. Everyone has a glimpse of what a platform should be capable of, which is “configurable.” But again, we still need to ensure everyone has the exact expectations of how configurable they want in for the system itself.
Are they expecting a platform that works like a generic tool, such as an API Gateway, Authentication, or Notification that is not tightly coupled with the product’s logic? This will help them build new products quickly on top of the existing tools and platform. Or are they expecting their product to be configurable for their customers' needs? For example, when expanding to SEA, the product must be capable of X features, while when expanding to LATAM, the product must be capable of Y features.
So, these two expectations must be explicitly aligned. What does the leadership want? What does the organization direction? When everything is aligned, it will be easier to draw a line between the domain boundaries where the Product and Platform are located. It will also help to focus a group of teams on their domain.
First, it’s essential to understand the difference between a Platform and a Product. Then, when we have clear expectations, we can start to make the product be platformed—here, I call it a Platformed Product.
Platform vs Product vs Platformed Product Breakdown Examples
1. Direct Debit Payment
If I want to make a diagram showing the location of the platform, product, and platformed product, it will look something like the one below. For example, let's use our previous example.
If we grouped them into three categories, they would look like these
Platform:
Gateway Platform
Auth Platform
Notification Platform
Products:
They sell Direct debit with Debit Cards. In the early phases of the startup/company, they might have a dedicated microservice for this, which is totally fine. It’s a phase for validating the market, so there is no need to be idealistic.
Later, in a few months, they identified another way for Direct debit with Oauth+OTP, so they created another Direct debit service for Oauth + OTP with web interface login payment.
…and later with SmartID
…and later with Giro
…etc
Of course, this is unhealthy, it only increases the complexity and cost of maintaining the products.
Platformed Products:
One Direct Debit platform/service, but with a configurable service to add a new Direct Debit type. Or at least allow plugins to support new direct debit types that are onboarded.
The goal is to allow fewer changes when onboarding new product types for the direct debit.
It’s still a product. If a team owned this, I would still call them a Direct Debit product team even though they’re making their product become a platform.
2. Identity Verification
To give more examples, let’s take Identity Verification products, like Veriff.com, which I mentioned above.
On their website, there are 4 top products
Identity Verification
KYC
Biometric Verification
Fraud Mitigation
Where each product also has sub-products. But the essence is still the same for each group.
Based on that, I can imagine these are the structures of the product vs. platform inside Veriff.
But one thing to note is that all three actually have similar features. For example, ID verification requires verifying the document and a person's face. KYC also uses ID Verification and maybe some other validations with the fraud registry, etc. Biometric Verification focuses on facial recognition, eye recognition, and other related features.
So, let’s imagine this company from the early stage. They obviously built the ID verification first— let’s assume it’s built-in one service. At the same time, maybe they got a new request for KYC that requires the user to also be validated for their government records, eg, AML (Anti Money Laundering) records, etc. Then, they also need to build it. For faster iteration, they build all independently — Again. This is just an assumption for a better example of how the transition from product to platformed product.
So, with this example, we can draft the three categories like the Direct Debit example above.
Platform:
Gateway Platform
Authentication Platform
Notification Platform
Products:
ID Verification service that contains all the core functionalities, e.g. Document verification, government registries, Age Validation, Face Recognition, etc
KYC Service that contains core functionalities for KYC, Document Verification, government registry validation, etc
Biometric Verification Service
Platformed Products:
Now, we can extract all the reusable stuff and make it a platform, for example, Document Verification, Government Registry validation, Face Recognition, Age validation, etc.
All these platforms can be combined to create new products and support existing products that they sell to customers (KYC, ID Verification, Biometric verification, etc.).
Conclusion
Alright, that’s all my thoughts about Platforms and Products. I wrote this based on my experiences. It is an opinionated topic, yet it’s an interesting one to discuss. It tests our craftsman skills to make configurable software that can adapt to most new use cases. It’s not 100% adaptable to new use cases, but at least we should aim to make fewer changes whenever a new use case comes up.
Some takeaways,
It’s essential to understand how to differentiate between products and platforms. The platform is the foundation for composing or configuring customer-facing products. Moving forward, we should make our product work like a platform — easy to configure based on new markets or customer needs.
Investing in a platform movement has never been wrong, but expectations must be carefully aligned. Some people love to oversell the “platform” buzzword, but we engineers know the struggle to match expectations. I strongly advise aligning with all stakeholders when your team or organization starts overselling “platform” words in a meeting.
Having a clear line between platform and product helps us establish clear domain boundaries, which might affect the organization's structure. This is especially true in the microservices world, where we can group services based on domain, following a Domain-driven design approach. Unclear boundaries will create chaos and communication overhead and eventually affect productivity, issue resolutions, and feature developments.