The 333 Platform Product Launch Framework
The “333” framework we applied on the Marketing API Platform Partnerships team at Facebook is more relevant today than ever.
I joined Facebook’s Marketing API platform team in the days after its 2012 IPO. Soon after, I dialled into a pretty important company all-hands meeting.
Zuck was calm (as ever) but clear - we were a newly public company, our revenue mix wasn’t optimal, and our mobile products were less than ideal. We needed to fix it, fast.
Everyone at Facebook was tasked with addressing an urgent challenge: rapidly scale new advertising products while navigating a mass migration to mobile devices and growing competitive pressure from companies like Google, Twitter and Pinterest.
Facebook - now Meta - always had a “partner and platform-first” mentality and approach. It launched an early developer platform at f8 2007 and open sourced dozens of internal projects now used by millions of developers, including React and PyTorch.
Partners helped make Meta the $1 trillion+ platform it is today.
So it’s no surprise we turned to our nascent Marketing API ecosystem to help us solve our most urgent post-IPO growth challenges.
3 partner types, 3 examples
To breach the mobile growth and revenue gaps, our Ads product teams - led by Fidji Simo - created a comprehensive roadmap that would solve all our problems at once.
Rather than launching new advertising products in isolation, we systematically engaged three distinct Marketing API partner types to quickly validate product-market fit, accelerate product adoption, and scale revenue.
We also relied on a pretty simple framework - I like to think of it as the “333 framework” - to prioritize and co-ordinate platform product launches with partners.
It’s a framework applied beyond Facebook - I’ve seen versions of it applied as a partner of Google, Twitter, and Microsoft. It can be applied to almost any type of “platform” launch, including AI/LLM platforms, SaaS, and everything in-between.
This framework enabled the successful partner-led launches of Custom Audiences (2012), Lookalike Audiences (2013), Dynamic Product Ads (2015), and Lead Ads (2015), products that set a strong foundation for Meta’s $100+ billion advertising business.
It was pretty simple. Every Ads platform product launch would involve three audiences and partner types:
Market makers (3): established SaaS platforms and technology companies that integrated new advertising capabilities into their existing products
Examples: Salesforce, Adobe, NanigansCustomer developers (3): companies or agencies with in-house development teams willing to and able to integrate new advertising products into custom stacks
Examples: Zalando, Dentsu Aegis, Booking.comIndie developers (3): early stage, often bootstrapped developers building niche Ad-Tech products atop Facebook’s Ads platform
Examples: Driftrock, StitcherAds, Kit
In a “best launch” scenario, we would - at launch - share three integration examples and case studies which spoke to or through each of the three partner types. Each should be unique in its own way, based on customer size, vertical, or geo.
Questions and CTAs
Examples and case studies would help answer these questions for advertisers:
What is this product, what problems does it solve, and how does it work?
How can I start using it today - through clicks or code?
Will it work with the other products, data, and creative solutions already I rely on?
How should I think about measuring success?
The call to action for advertisers, to/through each partner type, was simple:
Market makers: “New Facebook Ads product X is available through the platforms you already use, today”
Customer developers: “It’s easy to integrate. Here’s sample code and documentation to start building, today”
Indie developers: “Check out these innovative, vertical specific solutions unique to Facebook’s platform ecosystem. Available today”
Today was key.
Facebook’s platform was evolving so quickly, customers didn’t care if something was “coming soon” - they wanted to get an early edge on their competitors by extracting as much value from the platform as they could, as quickly as they could.
And if partners weren’t ready for the launch? They weren’t included. Simple.
We scenario-planned around this by typically creating a pipeline of 10+ partners in each cohort, knowing well that many of them wouldn’t be ready for launch - which usually happened less than 12 weeks from initial outreach. Often much faster.
If they were included, partners would benefit from the go-to-market might of Facebook at the time: press/PR, global and in-market sales enablement, inclusion in launch events and in-region events. Some even earned mentions in earnings calls - always a fun, usually unexpected outcome.
Partner selection and qualification
Here’s how the 8-12 week process was typically managed:
Market makers
We typically identified and prioritized partners based on: complementary customer bases, existing integration capabilities, and strategic alignment with the platform and new product. We always considered:
Previous partner performance: did they move fast, commit early, follow through?
Customer size and overlap: how quickly can they activate customers on the new product?
Technical sophistication: are they “self-starting” or do they need to be hand-held?
Co-marketing potential: do they have dedicated product and partner marketing teams?
Mutual strategic value creation: can they commit the platform for the long haul?
Customer developers
If a customer had significant in-house development capabilities, substantial advertising budgets or commitments, and were willing to serve as reference customers, they typically earned our attention. We always considered:
Ability to validate enterprise use-cases: can they build deep integrations and experiences (vs “light” integrations)?
Previous collaborations and feedback: have they already productively partnered with our Solutions Engineering team?
Scale potential: will this colloration keep their spend static, expand it a little, or grow it a lot?
Potential for a compelling case study: can this collaboration be truly transformative for their business?
Indie developers
These were very much “innovation bets” and offered us the ability to co-tell platform opportunity and innovation stories. The priority was rarely revenue growth - the main focus was to help customers understand they could “grow into” Facebook over time. We always considered:
Technical sophistication: can they move fast, with little support from us?
Clear market positioning: is their proposed solution truly unique?
Growth potential: if we include them in the launch, can they quickly capitalize on it to become “market makers” of the future?
Market intelligence: can they help us quickly understand edge use cases, verticals, etc, that can be applied across the ecosystem?
These criteria defined a long list, and then a short list of 10+ partners in each cohort.
Launch coordination and managing timelines
This encompassed all the aspects that make the launch possible - it’s a product launch after all. Which typically included:
Pre-launch preparation
Marketing alignment, ensuring every aspect of the marketing org was primed, ready, and bought-in to each partner selected
Agreements and (rarely) contracts shared and signed, typically high level alpha/beta agreements which were standardized across partners
Coordinating technical integration planning with partners (and Solutions Engineering)
Integration support
Providing early access to API documentation (often a Word doc!)
Access to dedicated Facebook Groups/email support aliases
Weekly or bi-weekly check-ins with each partner to ensure timelines were being adhered to and partners were not blocked
Performance monitoring and optimization
Health signals like error rates, latency, overall integration performance
New product performance, is the our product performing well, and is their implementation of it adding incremental value?
Are there any early trends emerging based on customer size, geo, vertical, etc? Can our product teams learn and act on them?
Success metrics
Ultimately every Ads platform product launch - this was an Ads platform play after all - came down to two key metrics: revenue and adoption.
Revenue was obviously the “north star” for all things Ads.
It’s a lagging indicator of the success of and the impact of platform partners, but an incredibly important one. Every new advertising product had to grow revenue fast, or get killed faster - there was no in-between. There’s a limited amount of real-estate in every platform, and every partner product. If it didn’t work - it had to go.
One product, search ads, launched and died within a matter of months.
Adoption was just as important. We couldn’t always measure the true revenue impact of every partner, all the time. Custom audiences was one great example. Yes, we worked with partners that included it in their ad-buying interfaces, so attribution was easy for them. But others simply sync’d hashed, segmented CRM data with Facebook.
That’s where adoption metrics came in - if we couldn’t track partner-influenced revenue, we focused instead on partner-influenced product adoption.
“333” is still relevant today
In so many ways the “333” framework we applied at Facebook (and others applied elsewhere) is more relevant today than ever. Platforms like OpenAI, Anthropic, and Perplexity are growing faster than ever - and their product launch cadence isn’t unlike Facebook’s Ads platform circa 2012. A lot of value is being created, very quickly.
The three cohorts of launch partners are just as important today as they were in 2012.
Customer developers are as eager as ever to integrate new LLM capabilities to get an early edge on competitors.
Market maker platforms like Salesforce and Shopify are just as eager now to integrate LLM capabilities as they were to integrate marketing platforms.
And indie developers will always be a presence in every ecosystem - creating unique “built for platform” value that offers a growing number of customers a growing amount of choice.
If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.