Building platform products
Crafting durable policies with imperfect information
Building a platform is fundamentally a different exercise than building a specific product. Having been at the ground floor of two platforms in their infancy (Roblox ‘16, Meta ‘21-’25), I wanted to share a few lessons!
To start, here’s a thought experiment: should the government allow mediocre restaurants to exist?
Most reasonable people would agree that restaurants shouldn’t serve food that makes people sick, but what about restaurants that serve safe but mediocre food? What if these mediocre restaurants make people less willing to visit restaurants, depressing revenue for the entire city? What policies might you enact to increase the number of Michelin star restaurants in your city?
Platform decisions are similar to crafting great government policy. These tough questions have less clear cut answers, which is what makes these decisions so interesting. Here are some things that are unique to platforms:
Crafting great policies require tradeoffs based on imperfect information
Policies require long time windows to verify
Learnings don’t translate well from one platform to another
Tradeoffs all the way down
Building platform products is about managing a set of complex decisions that we’ve made with imperfect information, with which the cause and effects are still hard to parse years later.
How much should we fund the ecosystem in its early days, and who should get these funds? How do we balance the app submission friction with downstream user experience? Do we optimize for engagement or monetization? Do we continue to roll out self-serve tools even if some developers use it in ways we didn’t intend, or in ways that regress ecosystem metrics?
To build a platform product is to accept that developers might “hack” the system in unintended ways. The output is non-deterministic, which, in this case, is a highly desirable feature in a creative system; I am constantly delighted by the things that our developers build! Yet, there are times when we see developers make sub-optimal decisions, so there’s always a tension between stepping in to stop these behaviors or letting the market sort itself out.
A few years ago, we saw developers creating and distributing promo codes with 99% off. Initially, we thought this was a mistake – why would developers forgo 99% of their revenue? Then, we learned that developers used this tactic to boost their apps to the top of “Top Selling” rankings with the idea that they will get more incremental sales from being at the top of the list than what they lose out in short term revenue. This threatened to create a downward pricing spiral (users might get used to low prices), and reduce trust in our ranking system. Ultimately, we decided to let this continue, and developers soon realized that this was an unprofitable long term strategy.
Good platforms provide choices. Some of these choices might result in developers making sub-optimal decisions, but it’s up to developers to make these decisions. Everyone should have the option to open a mediocre restaurant. But, it’s important to keep the organization aligned on these principles, while remaining flexible enough to make necessary adjustments. Too rigid, and the platform is slow to respond to changing user and developer trends; too flexible, developers might feel disempowered to make long term commitments. There are the tradeoffs all the way down.
Term limits
In politics, term limits are formal guardrails designed to prevent the concentration of power. In tech, our “term limits” are self-imposed – shaped by curiosity, ambition, and the pull of new tech like AI. This fluidity is part of what makes the industry exciting, but building platforms requires something more: the patience to play long-term games with long-term people.
There are incredibly rich benefits for those with patience! At Meta, I’ve witnessed several phases of our platform: “inorganic growth”, “open store”, and the “beyond gaming” eras, each of which challenged me to think differently. In the open store era, we went from hundreds of apps to thousands overnight, which made our previously manual processes less sustainable, and resulted in a set of new self-serve tools. In our “beyond gaming” era, we had to be much more rigorous in our prioritization among build frameworks as we wanted to support existing gaming developers, while ensuring that there’s sufficient tooling to drive innovation for Android, spatial, web, and Horizon Worlds devs.
Because platform-level changes need time to bake, we make some tactical adjustments. We run fewer a/b tests, and rely more on long term holdouts, user research, and sentiment surveys. We host in-person developer events to get direct feedback on our roadmap. Our data science teams focused more on reporting ecosystem health versus the efficacy of any specific feature.
On a feature level, developer adoption can take 12-18 months, often at odds with Meta’s performance cycles. To account for this, I’ve challenged our product teams to shift our launch strategies to earlier in the year. Even then, developer teams don’t always get full credit for the long term impact. This is a continued organizational challenge as we want our best and brightest to feel like they are making meaningful progress.
Platforms don’t repeat themselves, but they do rhyme
There are few playbooks to draw from when it comes to building platforms. While comps exist, they rarely fit the exact conditions and constraints. To make things worse, there is frequent retroactive rationalization that happens with successful products and startups. It’s always amusing to me when someone uses Roblox as an idealized platform example. To replicate Roblox, first spend 8 years building developer tools without any meaningful traction…
Another common fallacy is to bring in people with specific domain experience to build a platform. “Why doesn’t Meta just hire experienced game developers to build their platform?”
Meta has a very talented team of game developers in our first person studios and other parts of the company, but there are too many differences between running great studios and crafting durable platform policies for everyone else. For example, our studios push the envelope on performance and live ops tooling that’s not applicable for our long tail devs.
Of course, we still do deep dives on other platforms to meet and exceed expectations for developers familiar with other ecosystems. I want Meta’s analytics products to be best-in-class, but when it comes to growing and evolving the platform, we still need to rely on our own hard-won lessons.
Much will be written about Reality Labs in years to come. Few companies in history have pushed the boundaries in consumer tech as much as Meta has done. After 4 years, there’s still so much left to do, and I’m still excited to see what our developers build next!