Two-sided marketplaces have a challenge:
How to provide enough value that leaving the platform isn’t an option
We have a lot of marketplaces that have to balance the offer with the supply, while creating an added value for either or both sides to ensure people use the platform.
Here is a list of common marketplaces you might be used:
Airbnb: Short-and-long-term homestays marketplace
Fiveer: Freelance marketplace
Amazon: Third party sellers can use Amazon as a platform to sell their products
Uber: Drivers provide rides to passengers.
JustEat: Restaurants deliver food to consumers
LetGo/Wallapop: List and discover second-hand items near you.
And a lot of them have a common business capability, the chat.
Chat: Business capability facilitate the communication between both users to ensure they don’t leave the platform.
Churn is always a problem when people leave the platform and start a direct relationship, and more when the CAC is higher than the LTV for a single transaction within the platform. When you need recurrence, which it is almost always nowadays.
So, the chat has become a critical capability as the whole product experience to ensure we keep the users within the platform, and not bypass it.
The chat: Core or supportive capability?
The chat capability isn’t a business differentiator anymore.
It lives within the supportive, and still quite tailored to the business domain that using a generic off-the-shelf solution might not be an option.
But the chat capability have a huge rival. WhatsApp.
The constant upgrades on features on WhatsApp, like reactions, reading status, last time read, multimedia messages, stickers, the real time capabilities … All those features that people are used to, you don’t have the scale of Meta to invest on them. But you are expected to move into that direction (Red Queen effect on Wardley Maps).
So, you are in a though spot:
Should we use an off-the-shelf solution that costs a lot of money that doesn’t adapt enough to our user needs?
Should we invest into a custom solution, acknowledging that we will have to keep investing as the messaging apps keep evolving?
Is “not developing a chat” an option? People will bypass our platform anyway.
Wardley Mapping a Chat
Based on how I understand the landscape, visualized using a Wardley Map and a Core Domain Chart, suggests to us that custom-building it isn’t a good strategic decision.
Either relying on existing tools, or adopting an off-the-shelf solution, looks like the right decision to make.
Yet, the devil is in the details.
Any B2C marketplace has million of conversations and messages per month. And based on the current pricing models, it can cost millions per month to outsource this to a third party.
So, we have a business capability that’s cost of doing business, it is not a business differentiator, and we are in macroeconomic that makes it tougher to compete on margins that are shrinking.
It is valid to ask:
AI is accelerating development, we can do more with less, our competition is doing it, shouldn’t we internalize this, and save us the cost of this external tool?
Let’s assume we decide to build-it in house
Building an in-house copy of WhatsApp isn’t viable nor realistic. You won’t have the same requirements as WhatsApp in terms of million of concurrent users, for example.
But there is something that we can use in our advantage when we need to build internally a commodity. It is a well known domain:
Certainty: Commonly understood (in terms of use)
Market: Mature market
Market perception: Ordered / trivial
User perception: Standard / expected
Understanding: Believed to be well-defined / stable / measurable
On the other side, those properties make this domain to have higher expectations of usage.
So, in this case we aren’t experimenting, and aiming to reduce the cost of learning. We are developing a well understood domain. So, we need to focus on a methodology like 6-sixma or Lean to develop this business capability.
We can “know” how much it will cost us, and often it is a lot.
How do we build it?
We know the chat capability has specific business needs, but we also have a tech stack, and people skilled with certain tools, and methodologies.
So, how do we develop the chat?
Using existing tech like Ruby on Rails and Postgres, or we opt for a known technology to work for chat-like systems like Elixir?
Do we invest in new talent to develop this system? Do we train existing talent, and take advantage of AI? Do we leverage existing tech stack instead?
All decisions are about trade-offs.
And on those decisions, we need to add the domain specific knowledge we have about our users behaviors.
For example, in a B2C about selling second-hand items near you. You can have million of messages per month, but you also know that:
Conversations aren’t long, and they have a short duration.
Conversations are co-located. A person in Spain won’t be talking to a person in South Korea to sell a second-hand item.
Understanding this domain specific behaviors, we can shape our custom-build solution more tailored to our needs without reaching the level of WhatsApp for example.
My decision-making path
and how AI influenced how I would run experiments to verify the most viable solution.
I would externalize as much as possible. There are a lot of hidden costs on internalizing commodities and products beyond the invoice and the end of the month.
In case I need to custom-build it. I would:
Do a deeper research of viability using industry known approach.
In case it is needed and viable to be on specific tech, like Elixir in the chat example, I would experiment with this approach to fully understand the consequences. And I mean also in production.
Otherwise, I would default to current tech stack, and do our best to fulfill customer needs.
This will help us to leverage existing talent and keep the tech stack as homogeneous as possible in case it is important for the company.
Why AI is changing this decision-making process?
Because AI is trained on known data, known products, and everything that’s already present in the web. And generic and supportive subdomains, products and commodities fulfill these criteria.
AI can help us a lot on what’s not a business differentiator but cost of doing business. The LLMs can help us to extract those decisions made in the past that are relevant for our use case.
But this will also have consequences:
Using LLMs will be about the past, not the present, nor the future. We will also be behind of the rest if we only rely on the LLMs.
Custom-building has a lot of hidden costs, a lot of them aren’t public, therefore LLMs cannot help us to anticipate those.
We might end up in a sunk-cost fallacy, where we keep investing instead of decide to go for an off-the-shelf solution.
So, for one side, I consider that LLMs might be opening a space where more big companies will internalize those generic external services to reduce external cost. At the same time, this will start to increase all the hidden work to support those services.
Why internalizing everything isn’t viable
I provided this example for the chat, but you might consider applying the same decision to all third party services. That survey tool, that analytics tool, the CRM, …
And the truth is, those domains are huge, and I don’t consider reasonable to expect that a LLMs will be able to:
Understand all the domain specific knowledge required.
Support you maintaining the systems.
Support you on those edge cases, and industry changes that will force you to keep investing on those systems.
So, why do I consider a chat to be in the messy middle of the decision process to consider custom-building it?
Because, even though, from a capability point of view, I do consider it is a supportive one. In terms of the long term product strategy, you aim to reduce people moving to an external provider, and that’s why, in this case, it can make sense to make it internally, with all the consequences.
You might be investing millions, but you also can reduce the churn and increase the LTV enough that it makes sense. Remember that B2C are economies of scale, and at scale, the numbers can work.
