You know the story. Someone identifies a potential partner with millions of users, impressive brand recognition, or both. The next steps seem obvious: build an integration, get listed in their marketplace, and watch those lovely leads pour in.

The executive team gets excited. Engineering resources get allocated.

Then reality hits.

The integration gets built quickly, often by engineers who lack the proper context to understand either the partner’s platform or the actual customer use case. It gets shipped to meet a conference deadline or marketing launch. And then... nothing.

Or worse than nothing - a steady stream of one and two-star reviews from frustrated customers who installed an integration that promised much, but delivered little.

I’ve seen this happen time and time again. Sure, the integration served its marketing purpose. But it failed customers, by not creating any meaningful utility value for them. And, in failing customers, it ultimately failed every stakeholder.

These are vanity integrations - integrations driven by perceived distribution opportunities rather than genuine customer needs.

In the age of AI, they’re not just ineffective. They're dangerous.

What makes a “vanity integration”

First, vanity integrations are opportunity-driven rather than problem-driven. They start with someone identifying a potential distribution channel - “If we integrate with Salesforce, we’ll get access to their entire customer base!” - rather than starting with a clearly defined customer benefit in mind.

Second, they’re built with minimal customer research or validation. Because the focus is on the distribution opportunity rather than the customer need, teams often skip the hard work of understanding how customers might actually use it. They release the integration, but don’t test it. The integration is a means to a marketing end.

Third, they’re launched with great fanfare but minimal ongoing investment. Once the integration is live and the marketing milestone is achieved, it often gets relegated to maintenance mode. Bug fixes are slow, feature requests are ignored, and the integration slowly dies as both platforms evolve around it.

Finally, vanity integrations are measured by vanity metrics. Success is defined by the amount of press coverage, or the number of leads generated at launch - not by customer satisfaction, retention, or actual business value created.

This creates an unhelpful incentive structure where teams are rewarded for shipping integrations that look great on paper but don’t actually work well in practice.

Subscribe now

Why AI changes everything

The rise of AI assistants and agents fundamentally changes the stakes for integration quality, trust and safety. What was merely ineffective in the traditional SaaS world becomes actively harmful in the AI era.

If a customer tries a poorly built Slack integration for your project management tool, they might leave a bad review and uninstall it. Annoying, but fairly contained.

If an AI assistant tries to use a poorly built integration to access your data, and fails to answer the user’s question or successfully complete a task, the user doesn’t just think poorly of your integration - they potentially lose trust in AI altogether.

When someone asks ChatGPT or Claude to “analyze my sales pipeline and suggest next steps,” they're not thinking about which specific API endpoints the integration might need access to to answer their question. They just expect it to work. If the MCP connector fails or provides incomplete data, the entire AI experience feels broken.

AI assistants use unstructured inputs - prompts - and relevant context to generate answers or artefacts for users. Context is delivered through integrations, but if integrations aren’t built, configured, or tested with a variety of potential prompts and tasks in mind, customers will feel let down by the AI assistant, not the integration.

Even worse, if integrations with AI assistants aren’t scoped properly, or the right data access controls aren’t in place, sensitive data could be exposed to users that might not have the right to access it. Example: a front-line employee might inadvertently access sensitive financial information about the publicly-listed company they work for.

Non-technical users shouldn’t need to learn about MCP connectors, OAuth scopes or data sync delays. They just want questions answered and tasks completed. If your integration can’t help deliver that, it’s not just a poor integration - it’s a broken promise.

Your customers are not morons

David Ogilvy once wrote, “The customer is not a moron, she is your wife.” It's a fantastic reminder that we should never doubt the intelligence of our customers, because our customers are our friends, colleagues, and family - and ourselves.

It’s a reminder that’s never been more relevant than in the AI era.

Customers today are savvier than ever before. They understand the difference between well-thought-out experiences and those that are clearly rushed to market.

They spot vanity integrations a mile away - and they’ll tell you about it in their reviews.

For too long, partnership teams tolerated a culture where integrations were treated as marketing exercises rather than product experiences. Companies would rush to build connections with high-profile partners, ship barely functional integrations to meet conference deadlines, and then abandon them to accumulate negative reviews.

AI changes this dynamic completely. When integration quality directly impacts AI reliability, and AI reliability directly impacts customer trust, there’s no longer any separation between integration quality and business success. Companies that ship poor-quality AI integrations won’t just miss out on distribution opportunities - they could actively damage their brand and relationships with both customers and partners.

This shift forces all of us to take integration quality more seriously.

Partnership teams should invest more time and energy in customer and partner research, and integration testing. Engineering teams should build integrations with the same care and attention they give to core product features. Product teams should measure integration success by customer satisfaction - not press mentions.

But for customers - and for the industry as a whole - this shift represents a massive improvement. Better integrations mean better AI experiences. Better AI experiences mean more customer value. More customer value means faster - and better - AI adoption, and more sustainable business success for everyone involved.

AI is killing vanity integrations, and we should all be excited about that.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

In the early days of Facebook’s Ads API ecosystem, most partner-built products were essentially “wrappers” built upon our nascent Ads API.

At the time, our native ad buying interfaces were under-invested and not fit for purpose for large advertisers. Facebook offered a “power user” tool, Power Editor, which large advertisers used - but it came in the form of a brittle Chrome plugin.

It had half an engineer working on it, and you could tell. It crashed a lot.

Advertisers even had to “download” their ad accounts into their browser before they could use it - it was that basic. Advertisers often forgot to “upload” changes back to Facebook before they closed their browser. Many, many tears were shed as a result.

So, early Ads API partners pursued the lowest-hanging fruit - everything Facebook should have built, but hadn’t yet. Tools to upload bulk creatives, quickly duplicate ads and campaigns, and access insights to improve budget allocation and targeting.

These Ads API “wrappers” added value. Something was better than nothing.

But, as a newly-listed public company reliant on advertising revenue, that reality wouldn’t last long. Our product and engineering teams were already planning better ad products, and better “built by Facebook” interfaces to buy them through.

We shared this new reality with our partners. Many listened, but many didn’t.

The partners who didn’t listen became builders and sellers of similar - commoditized - ad buying interfaces. And each of them was now competing with another similar - and free to use - ad buying interface offered by Facebook. It was a race to the bottom.

Many of these partners, unfortunately, didn’t survive.

Those that did listen became some of our most successful Ads API partners. Over the next few years companies like Salesforce, Smartly, and StitcherAds “touched” tens of billions of dollars of Facebook ads revenue, became hugely profitable businesses, and generated multi-million dollar outcomes for their employees and investors.

The difference between partners who listened, and those that didn’t? Context.

The context gap

The partners who listened survived and thrived because they looked beyond the walls of Facebook’s own Ads API to create utility value for customers. Salesforce integrated their Social AdTech product with their CRM, enabling advertisers to reach existing customers - and find new ones - on Facebook, through custom audiences.

Partners like Smartly and StitcherAds integrated feeds from ecommerce platforms, turning static product images into dynamic video ads. They helped merchants use offline data to target campaigns effectively online. They offered server-to-server integrations to feed signals to Facebook’s auction engine, improving performance.

They turned latent data into meaningful context, which produced much better results.

If context was important to Facebook’s advertisers then, it’s even more important today to drive adoption of AI in every function in every business. AI can positively impact every business, if it’s implemented and integrated in the right ways.

78% of respondents to a recent McKinsey survey said they use AI in at least one business function, up from 55% a year before. That’s impressive - but one business function is one of many. AI has a long way to go before it’s as ubiquitous as email.

Depending on the organization - and functions within it - we spend much of our day creating and consuming content across multiple modalities. We create and share presentations, charts, and dashboards. We snap photos of receipts and hunt down PDFs to file expense reports. We collaborate in folders, repos, and Slack channels.

Yet, most people still use AI assistants like ChatGPT, Claude, and Microsoft's Copilot for simple research tasks. And most output from these tasks is still in text form.

To scale adoption across multiple organizational functions and move beyond simple text outputs, we need to provide LLMs with the right tools and knowledge to understand and create content across modalities. Building simple "wrappers" around LLMs isn't enough anymore. To move beyond text, LLMs need context.

Hence the emerging demand for “context engineering.”

Subscribe now

From prompt engineering, to context engineering

Most of our early interactions with LLMs - or AI assistants built upon them - happened through prompts. Better prompts, better results. The process of refining prompts to extract high quality responses from LLMs was quickly coined "prompt engineering."

But great prompts are never enough. LLMs don’t know everything about your business.

When you give LLMs access to relevant context, you go much further, much faster.

Enter context engineering, an emerging discipline of providing AI systems with precisely the right information, tools, and data - at the right time.

Tobi Lutke, CEO of Shopify, recently captured the importance of context engineering:

Andrej Karpathy, co-founder of OpenAI, built on Tobi’s tweet, illustrating concrete examples of tasks an "LLM app" needs to take to create high quality outcomes:

“On top of context engineering itself, an LLM app has to:
- break up problems just right into control flows
- pack the context windows just right
- dispatch calls to LLMs of the right kind and capability
- handle generation-verification UIUX flows - a lot more - guardrails, security, evals, parallelism, prefetching, ...”

Karpathy describes LLMs as functioning like a new operating system where the model serves as the CPU, and context windows act as RAM - but with finite capacity.

Context engineering is a delicate art of curating what fits into this "working memory."

Too much context overwhelms the system. Too little context produces generic, unhelpful responses. The wrong context at the wrong time leads to hallucinations or irrelevant outputs. To get the best outputs, you need to give LLMs the best inputs.

Is it any wonder, then, that Forward Deployed Engineers are emerging as an in-demand role in AI platform companies? They’re integration specialists - context engineers - who also understand how to bridge gaps between enterprise data and LLMs.

Context engineering, at enterprise scale

Andreessen Horowitz captured the importance of Forward Deployed Engineers in “Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups.” They argue AI companies achieving massive scale are embracing complex implementation work to deeply integrate with customer systems of context.

Margin is being “traded” by a growing number of AI startups who are investing upfront in deep - often custom - AI integrations. Smaller near-term margins will translate over time into revenue that retains better and grows faster.

Forward Deployed Engineers co-ordinate the integration of APIs. But they also think about and understand business workflows, data relationships, and decision-making processes to give AI systems the context they need to be genuinely useful.

They turn latent data into meaningful context, producing much better results.

When your AI system is deeply integrated with specific context, workflows, and data relationships, switching to a competitor becomes exponentially more difficult.

Ashu Garg and Jaya Gupta of Foundation Capital recently touched on the same trend in “The $4.6T Services-as-Software opportunity: Lessons from year one.”

In their words:

“When every company can ship the same primitives using the same models, what you build is no longer your moat. How you integrate, embed, and operate becomes the moat.”

This should be music to the ears of every partnerships professional.

When AI capabilities rapidly commoditize, implementation and integration becomes the lasting differentiator - exactly the complex, relationship-driven work that partnerships teams excel at.

Foundation Capital’s research revealed that in enterprise AI, “integration is not a post-sale activity. It is the product surface.” This is a massive shift from “traditional” SaaS partnerships, where integrations were often an afterthought or nice-to-have features.

Subscribe now

How context engineering maps to context partners

The most successful AI implementations orchestrate multiple context partners to create rich, multi-dimensional understanding.

A customer service AI solution might combine customer history from Salesforce, product documentation from Notion, conversation context from Slack, and real-time system status from monitoring tools to create comprehensive support responses.

Context engineering includes a variety of context types (which I previously covered in An MCP Primer for Platform Partnerships Teams):

• “Tools” - functions the AI can call (example: HubSpot’s “create_contact” or Linear’s “create_issue”)

• “Resources” - data the AI can read (example: SQL databases, GitHub repository files)

• “Prompts” - templates that help the AI interact effectively (example: “Generate a sales email using this contact's interaction history”)

So, with that in mind, how can partner teams align with and rally around the right types of partners to scale the impact of context engineering?

There are many potential ways to group “context” partners, but I like LangChain’s general categories of context engineering.

LangChain’s categories - Write, Select, Compress, Isolate - help us map partners into a simple architecture. Instead of building point-to-point connections between individual systems, partnerships teams can orchestrate comprehensive context ecosystems that enable AI systems to understand and act on complex business scenarios.

In LangChain’s grouping, context engineering operates across four distinct layers, each of which can be mapped to specialized partnership opportunities. Rather than viewing these as separate categories, partnerships teams should approach them as an integrated ecosystem where different types of partners work together.

Write context partners

Save context outside the context window to help an agent perform a task.

Write context partners provide persistent memory that extends beyond single interactions, including the ability to store intermediate thoughts, build institutional knowledge, and maintain conversation history across sessions.

Examples:

• Zep - dedicated context engineering for AI agents

• Mem0 - universal memory for AI agents

• DuckDB - structured memory management

Select context partners

Pull context into the context window to help an agent perform a task.

Select context partners fetch and load relevant information into the context window, including Retrieval-Augmented Generation (RAG), dynamic tool selection, and just-in-time information delivery.

Examples:

• Pinecone - fully managed vector search

• Contextual.ai - enterprise grade RAG deployment

• Glean - enterprise knowledge discovery

Compress context partners

Make it easy to retain only the tokens required to perform a task.

Compress context partners optimize limited context window space through summarization, trimming, and linguistic compression for maximum information density.

Examples:

• LangChain - compression retrievers and LLM-based filtering

• Orq.ai - context optimization and LLM management

• Portkey - request optimization and context management

Isolate context partners

Split context up to help an agent perform a task.

Isolate context partners separate different contexts to prevent negative interference, including multi-agent systems with specialized context windows and sandboxing.

Examples:

• CrewAI - specialized agent co-ordination

• Stack AI - no-code agent isolation

• Beam - agentic automation with isolated workflows

These are just examples - but there is a growing number of context partners in the market. A growing number integrate or partner with each other, and are building out their own capabilities, to offer interoperable solutions across all four context types.

Many are building their own ecosystems of Systems Integrator (SI) and ISV partners.

Subscribe now

Building context partnerships that scale

The growth in demand for context engineering creates immediate opportunities for partnerships teams. Here’s some actionable next steps to get started:

1. Audit your current partner ecosystem through a context lens

   Map your existing partners to LangChain’s four categories: Write, Select, Compress, and Isolate. This could reveal immediate gaps and partnership opportunities that align with your customers’ context engineering needs.
   

2. Develop context partnership criteria

   Traditional partnership criteria focused on market size and technical compatibility - context partners require additional evaluation. Can partners handle enterprise data with appropriate trust and security controls? How well do their context formats integrate with your customers AI systems? Questions like these will help you identify partners who can truly scale the impact of context engineering.
   

3. Enable Systems Integrators and Global Systems Integrators (GSIs)

   SIs and GSIs already deeply understand customer workflows and data relationships - exactly what context engineering requires. Train your SI/GSI partners on context engineering principles and create joint playbooks for common scenarios. Example: when an SI identifies a need for better memory management, they should immediately think of your Write context partners.
   

4. Create context partner ecosystems, not just integrations

   The most valuable context implementations orchestrate multiple partners working together. Create and share reference architectures that show how different context partners can complement each other, and facilitate introductions between your Write, Select, Compress, and Isolate partners.

Context partnerships also require strong technical foundations - high-quality APIs and seamless integrations become even more critical when AI systems need to orchestrate multiple data sources and tools in real-time. I’ll explore the API and integration requirements for successful context partnerships in a future post.

The future of context partnerships

Unlike “traditional” integration partnerships, which can often focus on once-and-done integrations to unlock go-to-market opportunities, context partnerships require deep ongoing collaboration, flexibility, and the ability to react quickly to market pressure.

This creates a fundamentally different partnership dynamic.

Partners need to understand each other’s roadmaps and releases, share insights about customer needs, and collaborate closer than ever before. They need to develop new skills around data governance, AI trust and safety, and context engineering.

Those that do can capture a meaningful slice of a multi-trillion-dollar transformation.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Back in 2016 I published a post on the Intercom blog that trended in the top 5 on Hacker News, sparked heated debates on Twitter, and divided readers into two camps: those who thought I was a complete fool, and those who thought I had a point.

“Browsers, not apps, are the future of mobile” argued that messaging apps like Facebook Messenger, Slack, and WhatsApp were actually web browsers in disguise - a new way to discover and interact with the content and services you cared about.

I argued:

“Facebook is our browser for the social web. It makes it easy for us to browse through and discover the friends, businesses, and content we’re most likely to enjoy. Instead of having to ‘pull’ content through traditional browsers, Facebook ‘pushes’ content to us based on our interests and those of our friend networks.”

I even included a screenshot of Facebook’s iOS app to prove my point. It contained an address bar, a save button, and buttons to browse backwards and forwards. Features of most mobile browsers then, and most mobile browsers today.

I also - naively - predicted that bots were “the new way to browse” and that we’d book rides and buy products without ever leaving messaging apps.

“Instead of going into the address bar, typing a URL, and waiting to receive content every time, bots can push us the content as we need it. They can learn the content we’re most likely to engage with, and serve us more relevant content over time. They curate content for us.”

Yep, that one didn’t age well.

A decade later, I cringe at how bad some of my predictions were. But it wasn’t all bad.

I was wrong about bots. I was right about browsers.

Facebook Messenger bots never became the web browsing nirvana I (or Meta) hoped for. Most people still don’t book Ubers through messaging apps or buy holidays through them (though WeChat’s success in China suggests the potential was real).

But I didn’t get it completely wrong. I just had the wrong timeline - and the wrong technology. The “bots” I predicted weren’t Facebook Messenger chatbots.

They were AI assistants, orchestrating AI agents for us.

When ChatGPT reportedly hit one billion weekly users this year, it became the fastest-growing consumer app in history. But it also became one of the world’s most popular web browsers - though most people don’t recognize it as such.

Traditional browsers like Chrome and Safari “pull” information for us - they fetch and display whatever we explicitly request. But AI assistants like ChatGPT and Claude are more intelligent and independent. They understand context and intent.

And, powered by products like Browserbase and Browser Use, they enable agents to do our internet browsing for us.

Think about how you use ChatGPT today. You ask it for help, and it doesn't just return links or answers. More often than not it browses the web, synthesizes information from multiple sources, and creates curated, contextually relevant responses.

This is browsing. It’s just not the kind of browsing we’ve been used to.

When I wrote about Facebook being a “browser for the social web” in 2016, I was hoping for something similar - an intelligent system that curates and presents information based on your interests and context. Sure, Facebook’s algorithm understands you, filtering billions of posts down to dozens that appear in your feed.

But Facebook was limited to the content and information within its own system.

Today’s AI agents can access and browse the entire web.

Subscribe now

Agents, the new way to browse

Here’s what one potential future of mobile browsing looks like in practice. Through their Android app, I ask Manus to “Find me the highest rated smoothie maker, and order it for me on Amazon.”

What happens next isn’t traditional mobile browsing. It’s something entirely different.

Instead of opening Amazon’s mobile app and struggling with a bunch of review sites on my small screen, Manus starts desktop browser sessions in the cloud.

While I continue using my phone (or, put it down to do something more productive), an AI agent navigates full desktop versions of review sites and Amazon on my behalf - accessing and reading detailed reviews, comparing specifications, and evaluating the best options. Something that might take me hours on a mobile device.

The magic isn’t that the agent can browse. It can browse better, and faster, than I can.

It’s doing the kind of comprehensive research that I’d want to do but rarely have the patience for - on desktop, or on mobile. If I want to intervene or provide additional guidance, I can - but I don’t have to. The agent understands my intent well enough to make intelligent decisions on my behalf.

When it’s done, it searches Amazon’s complete product catalog and orders the highest rated smoothie maker for me.

This is the “We can book things and buy things” future I hoped for in 2016.

But instead of happening through clunky chatbots in messaging apps, it’s happening through intelligent agents that navigate rich desktop web experiences while presenting me with a simple, mobile-optimized interface for oversight and control.

The agent becomes my browser, handling the complexity while keeping me informed and in control of the outcome. It buys me the most precious commodity of all - time.

Subscribe now

The new browser wars have already begun

Browserbase and Browser Use are building new types of browsers for AI agents, but web browsers for humans are evolving, too.

Built on Google’s open source Chromium project, Perplexity’s new Comet browser is attracting rave reviews. And, it seems, their ambitions don’t stop there - Perplexity appear to have ambitions to create a new, AI-first operating system.

Unlike traditional browsers that often add AI features as an afterthought, Comet is designed from the ground up as an 'agentic browser' that can pull information from multiple open tabs simultaneously, and help users complete tasks.

Building on their release of Operator, OpenAI’s rumored web browser also looks like a play to become the next, AI-first operating system of choice. And Anthropic have been experimenting with Computer Use, a beta feature that enables Claude to interact with desktop environments.

Google - owners of almost 70% of the browser market - are also on the front foot.

Google is integrating Gemini AI directly into Chrome, providing context-aware assistance using current page content, summarization, and question-answering without tab switching. And Project Mariner already powers autonomous AI agents that can control Chrome, navigate websites, fill forms, and complete tasks.

For these browsers, context will be the new competitive advantage.

Traditional browsers treat every session as independent. AI-first browsers maintain context across interactions, building a persistent understanding of user needs and preferences. Products that provide rich context to agents - about user behavior, preferences, and history - will have a significant advantage over those that don’t.

I know what you’re thinking. The examples I just shared are focused on desktop.

But eventually, inevitably, they’ll appear on mobile. Google is, for example, already “combining” Chrome OS and Android - integrating AI assistants and agents into that unified OS is a next, natural step.

The Manus example I shared earlier is a taste of what’s to come.

The future I hoped for is late, but it’s here

The companies investing in our browser-first, agent-first future have been quietly positioning themselves for the next phase of the internet.

Just as mobile forced every company to rethink their products for touch interfaces, AI is forcing every company to rethink their products for agents and browsers. The companies that recognize this shift early and adapt their product and partnerships strategies accordingly will have massive advantages over those that don’t.

The platform shift is happening now. And the stakes are enormous.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Earlier this year I quickly created and launched something I wish I’d had when building HubSpot’s App Partner Program: a self-serve tool for partners to evaluate the quality of their listings in the HubSpot App Marketplace.

HubSpot App Marketplace Listing Grader has completed over 10,500 runs with a 4.4/5 rating from 1,130+ reviews. It’s simple, but it works. The best bit? I built it in the same amount of time it took to drink a Venti Americano at Starbucks - it really was that easy.

What we’re actually building

HubSpot App Marketplace Listing Grader is built on Dharmesh’s Agent.ai platform, but it should be be just as easy to build it with other agent builders like Zapier or n8n. Much of this could also be built as an OpenAI GPT or a Claude-powered app.

And, before we dive in, let’s be clear: I’m calling this an “agent” but it’s more like a workflow that calls multiple LLMs. It’s not super agentic by Anthropic’s well defined standards, but it’s a solid foundation for becoming properly agentic in future.

Here’s how I built this agent, and how to approach building yours.

Step 1: Define your problem (and keep it simple)

When building AI agents, the most important step happens before you touch any code or agent builder. First, you need to clearly articulate the problem you’re solving and resist the urge to build something overly complex.

In this case, the problem is straightforward: HubSpot’s 1,200+ App Partners lack 1:1 guidance on listing their apps effectively in the marketplace. They build great apps and integrations but create sub-par listings that don’t convert into usage or revenue.

The solution needed to be equally straightforward: a simple grader that takes their HubSpot App Marketplace listing URL, crawls it, evaluates it against best practices and benchmarks, and returns actionable recommendations for partners.

It’s a holistic evaluation that includes content quality, review responsiveness, certification status, plans and pricing completeness, and tracking/attribution setup.

Step 2: Map your inputs and outputs

Once the problem definition is clear, think through the user journey and technical flow. You’ll need to understand the context you’ll need, the LLMs you’ll use to analyse and interpret that context, and the output format of the agent.

It’s important to provide relevant, high quality context to agents and LLMs so they answer or act in helpful, factually correct, coherent and complete ways.

For the HubSpot App Marketplace Listing Grader, the input is super simple: a HubSpot App Marketplace listing URL. That’s it. No complex forms, no multi-step wizards, no prompts. Paste a URL, hit submit, and get recommendations.

The routing logic is basic - checking first if the URL actually resolves to a valid listing. You could get much fancier here later with conditional flows based on app category, certification status, etc, but starting simply helps validate the core concept first.

For triggers, I chose manual submissions through Agent.ai’s interface, but most agent builders support webhooks, scheduled tasks, etc. It’s usually best to lay foundations to support multiple trigger types without over-engineering the initial version.

The output of the agent is a graded analysis with specific, actionable recommendations. Future versions of the agent could start to act on these recommendations for you - like drafting review responses, drafting new content, etc.

Subscribe now

Step 3: Grab and prep your data

This is where the technical setup really starts. In this case we’re grabbing data from the web (by crawling the HubSpot App Marketplace listing) but - depending on the agent you’re building - you might want to connect to other data sources too.

Crawling the HTML of the URL extracts the raw text content, meta tags, structured data, and basic page elements. But HTML parsing alone isn’t always enough - pairing it with a visual screenshot of the listing provides a more complete view.

That’s why the agent takes a full-page screenshot of every URL. The screenshot captures what users actually see when they visit the listing, including visual hierarchy, broken images, and multimedia content that might not be evident from HTML alone.

For the initial data extraction, I used OpenAI o3-mini - it’s fast and cheap for simple tasks like extracting structured content from unstructured blobs. This is the prompt:

In this crawled page, find:

- Total installs ('total_installs') formatted with a comma e.g. 17,000
- Average rating ('average_rating') which is the number that appears just before the 'Based on ___ ratings' text
- Number of reviews ('number_reviews')
- If this is a 'HubSpot Certified App' ('certified')
- If there is a case study linked to from the page ('case_study')
- Languages this app is available in ('languages')
- Number of languages this app is available in ('number_languages')
- Number of images ('number_images') e.g. '1/6' represents 6 images
- Number of pricing plans on the page ('pricing_plans')
- Number of times the text 'Helpful (' appears in the review section of the page ('review_count')
- Number of times 'Reply from' appears on the page ('reply_count')
- Number of links to the partners' website with UTM tracking ('utm_count')

Prepend the relevant field name (e.g. total_installs). Do not append or prepend any other text.
Binary choices like certified and case_study should be "True" or "False."
If average_rating is not available return 0.

{{video_present}}
{{crawled_pages}}

The simple prompt instructs the LLM to extract specific elements like total installs, average rating, certification status, number of images, number of pricing plans, and whether or not reviews have been responded to.

The more structured the data, the better the analysis and recommendations will be.

Next, I used Claude Sonnet 4’s multimodal capabilities to analyze and extract structured content from the screenshot. This is the prompt:

From this screenshot of a listing on the HubSpot App Marketplace, identify if a video is embedded in the listing.

A video is embedded in the listing if the large image at the top of the screenshot includes a centered orange circle with a white 'play' icon.

Your response should be "True" or "False."
Prepend the answer with 'video_present' in this format:

- video_present: RESPONSE

Do not append or prepend any other text.

{{screenshot}}

Specifically, it identifies whether or not a video is embedded in the listing - a signal that’s harder to extract from the raw HTML.

Subscribe now

Step 4: Generate analysis and recommendations

This is where the real value gets created. I use Claude Sonnet 4 to generate analysis and recommendations - it’s fantastic at recognising patterns in tabular/time series data, has a long-context window, and can toggle into deeper reasoning when required.

The analysis happens in three steps that could be parallelized simultaneously, but are in a step-sequence in this example.

First, a comprehensive evaluation of listing content and performance data against marketplace best practices and benchmarks. The prompt includes specific criteria for install growth, content completeness, ratings and reviews, and more. Here it is:

You are a Partner Manager for the HubSpot App Marketplace who specializes in helping HubSpot App Partners manage their App Marketplace listings to maximise engagement and reach. 

Using the extracted data and crawled text provided below, create a comprehensive evaluation of their app marketplace listing.

In each section, summarize areas of high performance in this exact order and structure and append the grade (EXCELLENT, GOOD, etc) underneath section heading:

- Number of installs ('Install Growth'). If 'total_installs' is 10 or less it's not good. 100 is better. 1,000 is good. 5,000 is great. The median number of installs in HubSpot App Marketplace is 80 and the average is 1145.
- Number of images, video and case studies ('Content'). If 'video_present' is 'True' the listing has a video which is a plus. If 'number_images' is 3 or less it's not good. If 'case_study' is True, it's a plus.
- Number of ratings and reviews, and average rating ('Ratings and Reviews'). No reviews is bad, 10 reviews is ok, 20+ reviews is good. An average rating of 4+ is good, 4.5+ is great. The median number of reviews in HubSpot App Marketplace is 3 and the average rating is 3.9.
- Response rate to most recent 10 reviews ('Review response'). If 'reply_count' is less than 'review_count', recommend that the user replies to reviews. Do NOT include the 'reply_count' and 'review_count' metrics in the response - just say they have reviews that lack a response. If 'reply_count' is the same or more than 'review_count' it's EXCELLENT. 
- Languages the listing is available in ('Internationalization'). One language is standard, 3+ is good, 5+ is great.
- Certification status ('Certification'). If the 'certified' value is false, recommend the user submits their app for certification.
- Completeness of plans and pricing ('Plans and Pricing'). If the 'pricing_plans' value is 1 it's bad, 3 plans is good, 3+ is great.
- Link tracking setup ('Tracking and Attribution'). If 'utm_count' is 0 it's bad, 3 links is good, recommend all links are tracked.

Guidelines:
- Use specific numbers from the data throughout
- Keep recommendations ordered as above
- Focus on concrete, actionable insights
- Base recommendations on HubSpot App Marketplace listing guidelines
- Separate each result with a horizontal line for visual clarity
- Don't include an overall header in the response
- Keep all font sizes the same, bold header text only
- Format the output as markdown

This is the extracted data:

{{video_present}}
{{crawled_data}}

This is the crawled text:

{{crawled_pages}}

It also generates specific recommendations to improve listing quality. These aren’t generic suggestions - they outline steps to take, and why to take them. Each section and recommendation is graded from ‘POOR’ to ‘EXCELLENT’ - super simple.

Second, a separate call to Claude Sonnet 4 calculates a numerical score out of 100. This might seem arbitrary, but partners love having a concrete number to track improvements. Scoring considers all the factors mentioned above. This is the prompt:

Calculate a grader score out of 100 using the following criteria based on the results included below:

- Number of installs ('Install Growth'). If 'total_installs' is 10 or less it's not good. 100 is better. 1,000 is good. 5,000 is great. The median number of installs in HubSpot App Marketplace is 80 and the average is 1145.
- Number of images, video and case studies ('Content'). If 'video_present' is 'True' the listing has a video which is a plus. If 'number_images' is 3 or less it's not good. If 'case_study' is True, it's a plus.
- Number of ratings and reviews, and average rating ('Ratings and Reviews'). No reviews is bad, 10 reviews is ok, 20+ reviews is good. An average rating of 4+ is good, 4.5+ is great. The median number of reviews in HubSpot App Marketplace is 3 and the average rating is 3.9.
- Response rate to reviews ('Review response'). If 'reply_count' is less than 'review_count', recommend that the user replies to reviews. Don't include the 'reply_count' and 'review_count' metrics in the response - just share the advice. If 'reply_count' is the same or more than 'review_count' it's EXCELLENT.
- Languages the listing is available in ('Internationalization'). One language is standard, 3+ is good, 5+ is great.
- Certification status ('Certification'). If the 'certified' value is false, recommend the user submits their app for certification.
- Completeness of plans and pricing ('Plans and Pricing'). If the 'pricing_plans' value is 1 it's bad, 3 plans is good, 3+ is great.
- Link tracking setup ('Tracking and Attribution'). If 'utm_count' is 0 it's bad, 3 links is good, recommend all links are tracked.

Guidelines:
- Do not append or prepend any text to the score. Return the score /100 only.

Results:

{{crawled_data}}

The key to good recommendations is being specific enough that a partner can take immediate action without needing additional research or interpretation.

As I mentioned earlier, future versions of the agent could invoke other agents to act on each recommendation.

Subscribe now

Step 5: Package and deliver results

The final step presents the analysis in a format that’s immediately useful and shareable. In this case, the output is simple - but future versions could include charts, screenshots of specific areas of the listing to improve, etc.

The entire process takes about 30 seconds from URL submission to final report - fast enough to feel instant but thorough enough to provide genuine value. The results are shareable through the Agent.ai interface, which has been crucial for adoption since partners can easily forward reports to colleagues and partner managers.

What makes this particularly effective is that partners get immediate feedback instead of waiting weeks for human review. They can iterate on their listings in real-time and rerun the analysis to track improvements.

This creates a feedback loop that drives actual behavior change rather than one-time recommendations that get forgotten.

Quick tips for writing better prompts

The prompts I’ve used are far from perfect, but they’re more than good enough. Here’s some tips based on what I’ve learned building hundreds of LLM-powered workflows and AI agents.

1. Keep agents and tasks focused. Tell agents and LLMs your desired outcomes, and what you want to achieve. Set clear limits, including response length, format, etc.

2. Use LLMs to write better prompts. Seriously. Ask specific Claude or ChatGPT models how to help you craft better prompts they’ll interpret and understand.

3. Structure everything. Use roles, step-by-step thinking, and markdown/XML tags to organize, optimize and manage your prompts.

4. Set boundaries. Define constraints upfront - what the agent should and shouldn’t do. Some models don’t perform better if they’re told what not to do (others don’t).

That’s it!

This simple agent has saved partner managers of hours of manual app reviews and has given partners instant feedback instead of waiting weeks for human review.

Next time you’re manually reviewing partner submissions or answering the same partner questions repeatedly, think through how you can delegate these tasks to your own custom-built fleet of AI agents.

They’re super easy to build - and it’s getting easier by the day.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Most partner-first companies initially prioritize revenue-generating partnerships, like channel partners, affiliates, and system integrators. This makes strategic sense - revenue will always be the fundamental driver of business growth and sustainability.

But there’s another, complementary, partner opportunity hiding in plain sight, often underutilized by startups, scale-ups, and platforms alike. In addition to co-marketing and co-selling products with partners, what if you co-build new products together?

Bundling innovation and distribution

Wiz is the perfect example of a platform company that figured out the “co-build” opportunity early. Founded in January 2020, Wiz scaled from a $0 to $32 billion market cap within five years, before Google’s acquisition announcement in 2025.

Co-building was a big reason Wiz scaled as quickly as they did.

Wiz started with revenue-focused partnerships - channel and affiliate - oriented around scaling adoption of existing products through partners. But Wiz also created a product partnerships team, reporting to their CPO, focused on co-building products with partners, including AWS (Amazon), GCP (Google), and Azure (Microsoft).

In concert with those partners, Wiz’s product partnerships team set about understanding customer problems, building solutions, measuring engagement - and building products that created new distribution and revenue opportunities for them.

This bi-modal approach, complementing revenue-focused channel partnerships with innovation-focused product partnerships compounded into a reported $500 million ARR business by 2024. And, of course, that $32 billion - all cash - exit.

Subscribe now

Co-build

But Wiz weren’t the first - and won’t be the last - to take this bi-modal partnerships approach en-route to a phenomenal market cap. Co-building with partners spins up a variety of innovation, distribution, and revenue flywheels that quickly compound to make customers, partners, and companies more successful.

I’m lucky to have had the opportunity to “co-build” products with partners in a variety of roles over the years. Here’s three co-build approaches I’ve seen work well.

Product partner management

The first approach is simple: create well-defined product partnerships roles and teams focused on co-building with partners. These are slightly different from other partnerships roles in that there often aren’t well defined revenue goals or targets.

My first role at Facebook in 2012 was my first experience of working in this “product partnerships” capacity. I was very much focused on “co-build” opportunities with partners, acting as an external-influencing product manager.

It was a hands-on role, and I would often embed with partner product and engineering teams to co-build with them for days or weeks at a time - whether it was in London with Salesforce and Experian, or with Wix in Tel Aviv.

It was my responsibility to guide and influence their product roadmap as best I could.

And how did we mutually measure success? We focused on the creation of utility value - tracking near term engagement and long term, product-led, revenue growth.

For example, when co-building Facebook Ad buying capabilities with Wix’s ShoutOut product, we didn’t focus on a revenue target. Instead, our goal was to increase the ad create flow completion rate which was - in our standard ad buying tools - around 1%.

Ultimately, through co-building a deeply integrated Facebook Ad buying solution that leveraged assets and targeting data within Wix’s existing platform, we increased that completion rate to around 3% within a matter of months. Revenue quickly followed.

Product accelerators

Accelerators are another, semi-scaled way to “co-build” products together with partners. Often the best candidates are existing service-focused channel partners - agencies with lots of talent but no sources of recurring product revenue.

“Facebook Accelerate” solved a well-defined problem. Facebook’s advertising revenue was growing quickly in markets like Central and Eastern Europe, but there were no localised AdTech products to help clients scale their advertising spend efficiently.

Our big global partners weren’t building for these markets - the needs were too niche.

The application process was pretty simple. Partners would pitch us solutions to customer challenges we’d shared with them. Those that put in real effort - thought through potential solutions, committed time to co-build with us - were accepted.

It was a multi-month commitment for everyone involved, including Facebook’s fantastic solutions engineers who allocated time and code to partners.

But it paid off handsomely. Products “co-built” through these accelerators contributed billions in advertising revenue to Facebook in the intervening years. One company “born” out of the accelerator, ROIHunter, now employs over 85 people.

Based on lessons learned at Facebook, we spun up a product accelerator at HubSpot, to solve similar problems. We had a fast-growing customer base, in a fast growing number of markets. But our own products didn’t serve those unique market needs well.

Meanwhile, one of our largest competitors, Salesforce, offered thousands of niche, partner-built, solutions through AppExchange. Our ecosystem of “market maker” integrations was tiny in comparison. The HubSpot App Accelerator would fill that gap.

We brought cohorts of HubSpot Solutions Partners together, shared customer challenges with them, and supported them to build “for HubSpot” products. The approach worked, helping us scale from 150 partners in 2018 to over 1,200 in 2022.

Product accelerators can simultaneously create utility value for customers, revenue value for platforms, and new sources of recurring revenue for partners.

Innovation hacks

Innovation hacks are different to product accelerators, in that they help existing platform partners add value to their existing products based on well-defined customer needs. One example: a “Nielsen Hack” I organised during my time at Facebook.

At the time Nielsen and Facebook had a shared problem. Brand advertisers were spending more on Facebook but hadn’t yet adopted Nielsen's brand measurement solution - Online Campaign Ratings. So they couldn’t prove the value of their ad spend.

Tagging OCR campaigns was a very manual process. Reporting was cumbersome.

And, inadvertently adding more friction, Nielsen had demanded a five-figure API access fee from our Marketing API partners before they could even attempt to build solutions with it. Partners needed a strong incentive - and support - to even consider it.

It was classic chicken-and-egg. Nielsen needed partners to build OCR solutions before brands could adopt it. Facebook needed OCR to prove the effectiveness of brand campaigns. Partners needed support from Nielsen and Facebook before committing.

The solution was simple. In exchange for partner commitments, we organized a hack day to co-build OCR integrations with partners. Nielsen waived API access fees and put up financial incentives for winners. Facebook provided advertising credits.

Through the innovation hack format, partners like Adaptly and Makemereach co-built effective solutions to automate tagging and reporting of Nielsen OCR campaigns. Which put them in a unique position to win new, high spending brand advertisers.

Subscribe now

How to make co-building with partners work

The specifics of co-build approaches are different, but the fundamentals are the same.

• Start by identifying customer problems that neither company can solve alone. This may sound obvious, but most failed partnerships start to fail here. Point to a specific customer pain point that co-building will solve, and prioritize partners based on this.

• Know how you’ll measure success before you start. User engagement growth, revenue growth, or something - decide this upfront, and link it back to the problem you’ve identified. When asked about the impact of these partnerships, have an answer ready.

• Commit real resources - including product and engineering - or don’t bother. Co-building isn’t a side project. It needs dedicated people and time from everyone involved. Half-measures produce half-baked products that help nobody.

Where to start

Most platforms already have strong foundations to co-build with partners. If you're running channel or affiliate programs, you already have relationships with a growing number of partners. Co-building expands the scope of those existing partnerships.

Here’s how to get started:

1. Based on co-build goals, pick the most relevant 3-5 partners. The ones where you already have working relationships and aligned incentives. Ask them a simple question: “How can we co-build solutions to these customer problems together?”

2. You’ll be surprised by how great their answers will be. Partners already talk to your shared customers every day. They often already see clear gaps that neither company is addressing. They often already have products and features in mind - great ones.

3. Start small, with one co-built feature or product and a handful of partners. Something small enough to ship quickly but meaningful enough to measure the impact of. Prove co-building works, then scale what’s successful - and operationalize it.

Companies that figure this out - combining product co-building with traditional partnership motions - can quickly separate themselves from competitors who only think about partnerships as distribution channels.

Wiz already proved it works. Now it’s your turn.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

If you’re managing platform partnerships, you’ve probably already heard about MCP (Model Context Protocol). You’ve also probably wondered what impact it might have on your strategy, partnerships, and day-to-day. So I thought it might be helpful to break down what MCP is, what it isn’t, and what it could mean for partnership leaders.

What MCP is

MCP is Anthropic’s relatively new open standard that lets AI assistants like Claude and ChatGPT connect to external sources of context.

Think of it as a standardized way for AI systems to “talk to” your existing data and artefacts without requiring custom integration work for every AI interface.

Instead of building separate integrations for Claude, ChatGPT, and every other AI assistant out there, platforms (or third-party developers) build MCP servers that work with all of them. It’s like a universal adapter - similar to USB - for AI platforms.

MCP servers typically expose three types of capabilities:

• “Tools” - functions the AI can call (example: HubSpot’s “create_contact” or Linear’s “create_issue”)

• “Resources” - data the AI can read (example: SQL databases, GitHub repository files)

• “Prompts” - templates that help the AI interact effectively (example: “Generate a sales email using this contact's interaction history”)

“Tools” are typically the most used capabilities, and typically interact with existing platform APIs to search, read, write, enrich and change data.

Adoption of MCP is growing fast. Launched in November 2024, there are already thousands of MCP servers listed in directories like Glama, MCP.so, and Composio.

Major platforms like GitHub and HubSpot recently released their own MCP servers.

Even OpenAI - an Anthropic competitor - adopted the MCP protocol across their products, in part because the broader ecosystem benefits of a standardized protocol outweighed the competitive risks of adopting a rival’s standard.

Subscribe now

What MCP isn't

MCP isn’t a magic solution to a lack of API coverage or extensibility. It is - for now at least - essentially a standardized wrapper around existing platform APIs. If your platform doesn’t expose data or actions you need via API, MCP might not be able to access them in a structured, reliable way either.

“Tools” for searching and browsing websites are available to MCP, but this type of unstructured data is often slower to access and harder to predict the availability of.

So MCP won't solve your API coverage gaps, but it will make them more visible to customers expecting strong integrations with AI products and features. As more customers rely on AI assistants as their primary interface, they’ll naturally demand the ability to interact with more data in more systems.

MCP also isn’t a replacement for existing integrations and partners. If anything, it augments them and opens them up to more use cases. It's like a new distribution channel that works alongside your existing partner ecosystem, not instead of it.

The ISV opportunity

For ISVs and SaaS platforms, MCP offers new ways to make their products “AI-native” quickly. A project management tool integrated through an MCP server suddenly becomes accessible to every AI assistant, potentially reaching millions of new users.

HubSpot recently launched the first CRM deep research connector with ChatGPT, enabling sales teams to analyze customer data and identify new opportunities using natural language within ChatGPT. Linear created MCP servers so AI assistants can create tickets, update project status, and manage development workflows directly.

The near-term opportunity is the creation of additional utility value for customers. Which creates incremental distribution value for ISVs and platforms. Getting your product embedded where users increasingly spend their time is a win for everyone.

The MCP advantage for AI platforms

There are obviously benefits for AI platforms like Anthropic and OpenAI, too. MCP solves a critical limitation - AI assistants perform best when they can interact with and act on real business data and perform real business actions.

Just in the past few months, MCP servers have been launched by:

• CRMs (like Salesforce and HubSpot), enabling AI assistants to interact or create customer data and automation flows

• E-commerce platforms (like Shopify and BigCommerce), enabling AI assistants to automate inventory and order management

• HRIS systems (like Workday and BambooHR), enabling AI assistants to interact with and analyze employee data

By connecting to enterprise systems of record, AI assistants start to generate tangible productivity gains quickly. When Claude can create Salesforce opportunities, update HubSpot contacts, or process Shopify orders through MCP connections, it transforms these interfaces from chatbots into business automation platforms in their own right.

Subscribe now

The integration acceleration effect

Here’s where MCP gets interesting for partnerships teams: it can accelerate the development of AI capabilities across partner products - and your own.

Historically, new integration development followed a predictable pattern. Customers request integrations, partners request APIs to build them, product teams add these requests to a backlog, and - often months or quarters later - the integration exists.

MCP changes this dynamic because fast AI platform adoption creates immediate market pressure.

When every user of every AI assistant expects the products and platforms they already use to integrate with them, API development - for AI use cases - gets prioritized. When competitors quickly launch comprehensive MCP servers, internal debates about prioritizing API coverage and extensibility get resolved quickly.

We’re seeing this play out in real-time.

Platforms that historically had limited extensibility and API coverage are expanding their programmatic surfaces quickly - specifically to support AI integration use cases.

What this could mean for platform partnerships

If you’re managing partnerships for B2B software products and platforms, MCP creates opportunities and requirements.

The opportunities are the ability to create utility value for customers - and the ability to create new distribution value - through AI assistants and platforms.

The requirements are platform and product changes required to ensure your products remain relevant as AI assistants become a primary interface in the world of work.

MCP adoption timelines are compressed compared to previous platform waves. Companies leaning into AI assistant integrations - through MCP - will enjoy significant ecosystem advantages as AI assistant usage grows.

Integration patterns we’ve seen before - where fully integrated customers retain better, and expand faster - are about to repeat at unprecedented speed and scale.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Yesterday, HubSpot announced they’re acquiring OrgChartHub. Dan and Austin - the two co-founders and sole employees of OrgChartHub - are joining the HubSpot Sales Hub team. I couldn’t be happier for them. They’re super humble, super smart guys.

And I’m not at all surprised this has happened - it’s a mutually perfect fit.

OrgChartHub is the perfect example of what I like to call “Ecosystem Entrepreneurs” - specialist creators building products that might not exist if the platforms they built atop did not exist. Every “true” platform has lots of “Ecosystem Entrepreneurs.”

OrgChartHub is the latest example from a playbook I’ve watched unfold many, many times. Small, scrappy “Ecosystem Entrepreneurs” build a solid business inside a platform ecosystem... before being acquired by that very platform.

Acquisitions like this aren’t accidental. They’re incredibly strategic.

Uniquely additive

Just after I left Facebook in 2015, a partner I’d worked with, KitCRM, was acquired by Shopify. KitCRM was a Facebook Marketing API partner, but they were also generating serious traction in Shopify’s App Store.

Michael Perry, Kit’s founder, was the perfect Ecosystem Entrepreneur. Humble, nimble.

Kit was a virtual marketing assistant - a bot - that proactively helped small businesses with marketing and advertising. Users interacted with Kit mostly through SMS or Facebook Messenger - they didn’t need to learn a new interface to use it.

“The goal here is to create the ultimate employee that goes beyond marketing,” Michael told VentureBeat. In the context of today’s AI chatbots, it was way ahead of its time. Kit was uniquely additive to Shopify’s platform.

On Shopify’s quarterly conference call, four months after the acquisition was announced, investors learned that Kit had already doubled its install base.

Customers loved it more, and trusted it more, now it was part of the Shopify family.

Subscribe now

Why Ecosystem Entrepreneurs win

The best ecosystem partners don’t just integrate one product or system with a platform - they ideate and create entirely new, unique products. They think and act like internal product and engineering teams. They deeply understand the challenges, needs, and wants of customers. They move fast, and innovate faster.

They’re all-in.

When I advocated for partners like OrgChartHub and Kit, it wasn’t solely for their benefit. Ecosystem Entrepreneurs often understand a platform’s customers better than internal teams do. Nurturing these partners was good for customers, and for us.

Brandon Greer’s LinkedIn post about the OrgChartHub acquisition captured this dynamic perfectly. Dan and Austin “took a big bet on our developer platform, our company’s growth, but most of all our customers.”

OrgChartHub had already proven product-market fit within the ecosystem. This de-risked the build vs buy decision. They were already - in many ways - part of the team.

Small partners create big value

If you’re an “Ecosystem Entrepreneur” building atop someone else’s platform, think bigger than just building. Act like you’re an extended part of their product and engineering team. Understand their strategy. Understand their customers obsessively.

And, if you’re part of a platform partnerships team, pay more attention to Ecosystem Entrepreneurs. Today’s small partner could be tomorrow’s game-changing acquisition.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

From 2010 to 2015, getting preloaded on mobile devices was the holy grail of app distribution. The mechanics were straightforward: partner with carriers, get your app bundled with new phones, and acquire users at a negligible CAC.

The golden age of carrier preloads

Facebook perfected this strategy at global scale.

As Chamath Palihapitiya explained in a 2010 Mobile World Congress presentation, Facebook built a mobile global distribution network of 200 mobile operators that was the envy of competitors: 100 million monthly active mobile users (25% of their user base) and partnerships with carriers to offer "Facebook Zero" - a free, data-charge-exempt version of their mobile site.

The results were tangible. After Vodafone UK offered a one-week free trial of “Facebook Zero” 20% more customers upgraded to Vodafone’s paid data plans.

Facebook wasn’t just acquiring users for themselves - they were also converting feature phone users to smartphones, driving vast revenue growth for carriers.

These preload deals weren't just about messaging and “like” buttons. Facebook negotiated system-level OS integration with device manufacturers, threading “Facebook DNA into the core operating system.”

By 2010, Facebook’s mobile reach touched 200 million users - 50% of their active users interacted with mobile products.

The new preload playbook, for AI

Fast forward to 2025 and the same distribution dynamics are emerging around AI assistants and search experiences. Samsung’s reported investment in Perplexity AI, combined with preloading their apps on Galaxy devices, isn’t just any old partnership - it’s the mobile carrier preload playbook adapted for the AI era.

The mechanics look similar to 2010. Hardware manufacturers provide default placement and OS-level integration, AI companies get friction-free user acquisition, users get next-gen AI experiences without discovering and downloading new apps.

But the distribution effects will scale even faster this time.

Samsung shipped 222.9 million smartphones in 2024. If just 5% of these users adopt Perplexity as their default AI interface, that’s over 11 million new Perplexity subscribers - comparable to OpenAI’s reported ChatGPT Plus subscriber base.

Subscribe now

Distribution, devices, and defaults

What makes today’s AI preload deals different from the carrier era is the platform layer they’re targeting. Spotify’s carrier partnerships enabled music discovery and consumption. Facebook’s preloads enabled social networking and communication.

AI assistants are about information access itself - the fundamental interface between users and the digital world. If Samsung preloads Perplexity, they’re not just distributing an app. They can potentially reshape how millions of people - young and old - discover information and interact with their devices. In every corner of the planet.

Amazon’s approach with Anthropic represents another evolution of the preload concept. By committing $8 billion to integrate Claude into AWS Bedrock and Alexa, Amazon isn’t just distributing an AI assistant. They’re making Claude the default choice - “core infrastructure” - for enterprise developers and consumers alike.

Defaults matter enormously for user adoption. Users don’t like friction. Which is why most users don’t actively seek out new apps, AI assistants or search experiences.

They lean into and trust what’s already integrated into their devices and workflows.

Samsung, Microsoft, and Amazon all recognize this behavioral reality. The difference between 15 years ago and today is that these partnerships aren’t just about app distribution - they’re oriented around shaping how we use AI in our daily lives.

The timing couldn’t be any better. Smartphones remain a “goldilocks device” with strong usage and utility inside and outside of the home. But the purchase intent of smartphones - and other devices - is static or declining. AI integration offers hardware manufacturers new options to differentiate devices, develop new form factors, and launch new subscription businesses.

Hardware manufacturers are back in the game

The smartphone era taught hardware manufacturers a painful lesson: controlling the hardware isn’t always guarantee of platform value capture. Facebook and Google built trillion-dollar businesses while manufacturers like Nokia and BlackBerry struggled to survive.

Samsung’s partnership strategy with Perplexity signals a different approach. Rather than just facilitating distribution for a new wave of AI platforms, they’re positioning themselves as investors - stakeholders in the future success of these new platforms.

Today’s AI partnerships will work for the same reasons mobile carrier partnerships worked 15 years ago. But this time, the stakes are much higher.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

I've been building products on the internet since I was a teenager (hint: for over two decades), but it was my first role as a Partner Manager on the Marketing API team at Facebook (now Meta) that laid the foundation for an “official” transition into product management at Intercom and Zalando.

After all that, I circled back into partner management for 4 years at HubSpot.

And then back into product management after that.

I’m not the only person to switch between partner and product management roles. I’ve been lucky to collaborate with many great partner and product managers that all seemed to share similar DNA with each other, and rotated between partner management and product management roles.

Here’s four traits they had in common.

They know how to say no (or not now)

Great partner managers live in a world of infinite opportunity and finite resources. Sales wants you to fast-track that partner integration that might close their biggest deal. Leadership has opinions based on other leaders they met at conferences and retreats. Every week brings a new “must-have” integration or partnership request.

The inexperienced partner manager tries to say “yes” to everything (and to please everyone). Great partner managers master the art of saying “no” - or more diplomatically, “not now.” They understand that every “yes” to a mediocre opportunity is a “no” to an opportunity that could be much more impactful.

Great product managers manage the same dynamics gracefully. Feature requests flood in from customers, sales, support, and leadership. The temptation is to build everything, and please everyone. But there’s discipline in knowing what not to build.

Great partner and product managers ruthlessly prioritize, and deliver with diplomacy.

Subscribe now

They’re roadmap influencers

Here's something I realized early in my Facebook journey: platform partner managers are effectively external-influencing product managers. These partner managers don’t just manage relationships - they influence what partners build, how they build it, and when they build it. They also help partners understand what not to build.

More than a few great partner managers I worked with at Facebook have since carved out successful careers in product management. Example: one of my teammates at Facebook, Sachin Monga, moved from partner management to product management at Facebook - and is now VP of Product at Substack - where this newsletter lives!

Sachin and I were - separately, but at the same time - trying to influence the roadmaps of Shopify and Wix. We had to convince them to integrate Facebook Ad buying with their platforms in creative ways, to make it easier for millions of SMBs to advertise.

This isn’t dissimilar to what product managers do internally with engineering, design, and go-to-market teams. Partner managers just do it with external teams and orgs.

Same skills, different audience.

They lean on intuition (and data)

Some of the best partners my teams and I worked with over the years looked unremarkable at first. They were quiet, humble, hardworking and under-the-radar - but became some of the most innovative and impactful players in their ecosystems.

Often the data didn’t tell a super compelling story about them in the early days. Their teams were small. They weren’t super well funded. They had a handful of customers.

Smartly was one of these partners. When we became aware of them in 2013, they were a tiny team based out of Finland. They had little funding and barely any customers compared with other Facebook Marketing API partners. But they were humble and hardworking.

They didn’t show up with asks - they showed up with questions. Great questions. Questions focused on helping customers, not Smartly. They acted on the answers fast.

They quickly displaced ecosystem incumbents, becoming Facebook’s biggest Ads API partner. And, within 6 years, they achieved one of the biggest ecosystem exits ever.

If we relied purely on “qualification” metrics - like company size, funding, and customer overlap - we wouldn’t have prioritized working with them. Great partner managers develop a sixth sense - an intuition - for potential. They spot the signals that data can’t capture: hunger, humility, technical curiosity, and customer obsession.

Great product managers flex the same intuitive muscle. You can A/B test your way to incremental improvements, but breakthrough products often start with a hunch that defies conventional wisdom. The data helps you validate and iterate, but intuition points you toward what’s worth building in the first place.

Subscribe now

They’re human Swiss army knives

Partner managers rarely have dedicated resources for everything they need. Want to get a new integration built? Product and engineering teams already have a long list of priorities. Planning a co-marketing campaign? You’re negotiating with the marketing team’s priorities. Better partner analytics? Join the product analytics or RevOps queue.

Great partner managers are usually generalists who can zoom out to understand business strategy, zoom in to debug partner issues, then jump into crafting messaging for a partner launch. Context switching isn’t just a skill - it’s table stakes.

Instead of building that integration, or lobbying a partner to build it, can’t we co-fund it? Instead of a co-marketing campaign, can we rally the internal troops to amplify the launch of a partner integration on social media? What’s a “something is better than nothing” approach to partner analytics? How do we get from 0 to 1 with no budget?

Great product managers operate in the same multidisciplinary reality. One moment they’re conducting user research, the next they’re facilitating technical architecture discussion, before communicating product launch plans to leadership. These days, great product managers use platforms like Lovable to quickly build and test ideas.

Great partner managers and product managers thrive in - and embrace - ambiguity.

Partner managers are product managers in disguise

If you’re a great partner manager, you’re already a product manager in disguise. If you’re a great product manager, you’re also a strong fit for a career in partnerships.

Both roles sit at the intersection of business strategy and technical execution. Both require translating vision into reality across organizational boundaries. Both demand a combination of strategic thinking, tactical execution, and diplomacy.

The skills transfer more cleanly than most people realize. What changes is context - internal teams vs external partners, direct control vs influence-based leadership.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

It’s September 2012, and I’m staring at evidence that one of our largest Facebook Ads API partners has violated our platform policies.

The offending partner was one of the first companies to get Facebook Ads API access. Their CEO was a familiar face of social media advertising, frequently appearing on Bloomberg. The previous year, before I joined Facebook, I’d watched him passionately advocate for my now employer in a BBC documentary.

They managed over $150 million in Facebook advertising spend for global brands like Heineken and Capital One. But they’d been sharing confidential information about alpha/beta Facebook Advertising products with clients. Which was a clear no-no.

This would be tricky to navigate - we had never encountered an issue like this before.

Your biggest partners aren’t above your policies

Partners will always be tempted to test the limits of platform policies. And it can often be tempting to let them. When a major partner violates policies, it’s easy to explain it away with “but they drive significant revenue” or “but they're strategically important.”

Yes, this partner drove serious revenue for Facebook and our clients. But our policies existed to protect three critical stakeholders: our clients, our other partners, and our platform’s integrity for the people who used it.

The moment you make a platform policy exception for one partner is the moment you undermine the integrity of your policies for everyone.

Subscribe now

A four-step fix

With this partner, I followed a four-step framework that I’ve used many times since across multiple roles. And - thankfully - no situation since has been public or “newsworthy.”

Align internally first

Once the situation is clear, and the evidence is clear, get all internal stakeholders on the same page, starting with legal. This is important before any external communication happens.

Yes, certain internal teams won’t be happy. Yes, there could be revenue - or other - implications. Address these concerns upfront and ensure everyone understands why policies exist and why they are enforced consistently.

Act decisively

Create a clear plan with specific timelines. Internal communications, external communications, and the content of them. Explore potential remediation plans. Explore potential impacts - good and bad. The longer you wait, the more likely it will be that information leaks and the situation escalates beyond your control.

Tough conversations are part of the job - embrace them rather than avoid them.

Communicate clearly

When you deliver the news, keep it factual and calm. Take the emotion out of it. The violations themselves and the decision to act on them aren’t personal - it’s an issue between two business entities.

Don’t react to any reaction the partner will have (and there will be a reaction). Don’t over-commit to future steps or potential remediation paths. Expect escalation - internal or external - and prepare leadership accordingly.

Offer a remediation path

Removing partners from programs or platforms for policy violations doesn’t have to mean burning bridges. It doesn’t make their company or the people working there “bad.” Humans are humans. Mistakes happen.

With this partner, we offered a six-month remediation path - they retained Ads API access, and a Facebook Solutions Engineer and I offered a full day on-site with their team to review their roadmap, provide support, and align on next steps. Their CEO appreciated our willingness to engage.

The outcome matters less than the precedent

The partner and Facebook re-established our relationship, and their business continued to prosper, eventually being acquired. But the real value was the message sent to our entire partner ecosystem: policies are non-negotiable, regardless of partner size or relationship history. Every partner would be held to the same standard.

That precedent protected us in dozens of subsequent situations. Partners knew we were serious about our policies, which actually made enforcement easier over time.

What this means for you

Every platform partnerships team will face a situation like this. The question isn’t if - it’s when you’ll face it and how you’ll handle it.

Your platform’s credibility with partners depends on fair, consistent policy enforcement. Exceptions don’t just undermine your policies - they undermine your entire program.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Most partner management advice focuses on traditional B2B partnerships: agencies, affiliates, and channel partnerships. But if you’re stepping into a platform partner manager role focused on managing technology partners at a platform company like Meta, Shopify, or Salesforce, your first month will look completely different.

Technology (or product) focused platform partnerships are a different beast. You’re not just managing one-to-one relationships with a handful of strategic “market maker” partners. You’ll also need to navigate and prioritise a fast-growing ecosystem of hundreds (or thousands!) of developers, ISVs, and technology partners building on top of your platform.

The playbook is different, the data available will (probably) be far less mature, and your stakeholders will span every corner of your company.

Here’s what I’ve found to work well in the first 30 days.

Week 1: Map internal stakeholders and org charts

Your biggest initial challenge isn’t understanding your partners - it’s understanding the culture, rituals, and nomenclature of your own company. Platform partnerships teams interact with and collaborate with product, engineering, legal, sales, marketing, developer relations teams - and often multiple business units and geos.

Every team has their own priorities, success metrics, and opinions about what partners should be doing. You should learn what these are as quickly as you can.

It’s usually best to start with product and engineering. These teams control the platform roadmap, API changes, and developer experience - if they didn’t exist, the platform wouldn’t exist! A breaking change could negatively influence partner relationships you’ve spent months building. So get to know your peers in product and engineering quickly, understand how they view partners, and understand any biases (positive or negative) they have about partners as quickly as you can.

Next, focus on go-to-market teams. Direct sales and agency teams are probably already recommending partners to customers, whether you know it (or like it) or not. Marketing could be co-marketing with the wrong partners because they lack clear visibility into which partners are strong or weak. Legal is probably already fielding partner questions about policies, violations, and everything in-between.

You need to understand the current state before you can influence the future state.

Don’t try to meet everyone all at once. Focus on leaders within each group who can help you understand how they work with partners today, and how they’d ideally like to work with them in the future.

Subscribe now

Week 2: Find the data (or admit it doesn’t exist)

Most platform partnership programs are flying blind in the early days. When I joined Facebook’s Marketing API team, we knew which partners were generating revenue through the Ads API, but we had no idea which partners were most popular by region, vertical, or agency type. When I joined the partnerships team at HubSpot, we weren’t yet using our own CRM to track and manage our partner pipeline.

“Where’s the data?” should be the first question you ask.

Your job isn’t to have perfect data - it’s to understand what data exists, where it lives, and what’s missing. Start with the basics: which are our top partners by revenue/install impact? By vertical? By geo? Which partners are growing fast? Which partners are static or declining?

If you can’t initially answer these questions, it’s not a failure - it just becomes one of your first projects. Build a baseline data understanding before you do anything else.

Week 3: Separate the signal from the noise

Every platform ecosystem is populated with partners who talk a big game but deliver little value. The most vocal partners are often the least loved by customers. They might have strong go-to-market engines but often offer weak products and support.

Meanwhile, your most valuable partners might be completely invisible. They’re humbly and quietly serving your customers by building reliable products, supporting them well, and helping your platform win new revenue - but they’re not loudly showing up at your events or flooding your inbox with endless asks.

Your job is to identify both groups. Loud partners usually need management and education about what a “good” partnership looks like. Quiet partners usually need an advocate - you - to invest in and support them to scale their impact.

Week 4: Control the controllables

You’re new. You can’t change everything all at once. Sales teams will continue to recommend partners that are top of mind for them. Let them. Product teams will still prioritize feature requests for tangible, revenue generating products over API change requests from partners. Let them. They know their world better than you do.

But you can start to influence them and collaborate with them. Create simple tools and dashboards to surface data and insights that make it easier for sales teams to recommend the right partners. It’s in their interest to do this. Build feedback loops that help product teams understand the impact partners have on the revenue and engagement growth of their products. It’s in their interest to know this.

It’s your job to help your colleagues understand how partners can help - not hinder - them and the growth of their pipeline and products. Focus your energy productively.

Subscribe now

Find your quick wins

Again, you’re new. But your peers - and leadership - will want to see quick progress. Your teammates will need to understand the value you’re adding, so they know they made a great hiring decision.

Identify 2-3 projects you can execute quickly that demonstrate a tangible impact.

That impact can be as simple as helping them know something they didn’t know before you showed up. The data and tools you build for yourself can help them too.

Example: one of my first - quick - projects at Facebook, was to build a simple Tableau dashboard that helped UK/Ireland agency teams understand which Ads API partners the major agency holding companies they worked with were using. They’d never had this visibility before, and it immediately changed their conversations with these agencies and influenced which partners these agencies collaborated with.

Quick wins should solve real problems for the people you’ll collaborate with every day. They can also generate data and insights that inform your longer-term strategy.

Your first 30 days lay the foundations

Platform partnership management isn’t just about managing relationships - it’s also about designing systems that scale and enable thousands of relationships to thrive.

Systems are foundations. Map the organization, find data, understand partners, control what you can, and demonstrate tangible value as quickly as you can.

Your partners - and your colleagues - are counting on you to get it right.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Often, the typical motion of a typical platform partnerships team looks something like this: win partners, onboard them, manage relationships, track metrics, keep iterating.

But for “market maker” platforms in particular, there’s an even bigger opportunity.

If you're running partnerships for a "market maker" platform (think Meta, Salesforce, Shopify, Atlassian), you also have a duty to orchestrate connections between partners.

Every partner has, after all, one thing in common - you.

Connecting partners with other partners creates a flywheel-velocity web of value that benefits them, your customers, and company. It can be a huge force multiplier.

Example: PayPal + Facebook + Marketing Partners

Back in 2015, when I was on the Marketing API partnerships team at Facebook, PayPal came to me with what sounded like a straightforward ask: they wanted to grow transaction volume (and average order value) for 2 million SMB merchants in the UK.

Their initial “ask” was pretty obvious: we (Facebook) should help them build their own ad buying tool, so their merchants could run ads via PayPal.

I pushed back.

AdTech wasn’t PayPal's core competency (at least not then). They were a payments company, and in the midst of being spun out of eBay. I knew from experience they’d have an incredibly hard time securing product and engineering resources internally.

My question to them: why reinvent the AdTech wheel when we already had dozens of Facebook Marketing Partners who’d already perfected their SMB marketing tools?

I suggested a lower-friction, faster-moving option: I’d help orchestrate partnerships between PayPal and three existing partners: AdEspresso, Driftrock, and Kit.

The structure was pretty simple:

• Each partner would create a compelling offer for PayPal’s merchants (example: 50% off for 3 months)

• PayPal would, in turn, promote these offers to their 2 million UK merchants, through emails, paid ads, and social media posts

• Facebook would also allocate advertising credits to incentivize customers to try each partner tool, and to try PayPal as a new way to pay for their ads

We launched it within weeks, not months.

It was a win-win-win all round. Partners acquired new customers, PayPal drove transaction volume, and Facebook activated new advertisers. Most importantly, customers learned how to promote their products and services on Facebook.

Subscribe now

A framework you can apply

This approach works well for almost any partnership scenario or partner type: technology partners, solutions partners, GSIs, SIs, affiliates, and more.

Start with these steps:

1. Create a partner value map

First, understand the unique value each partner brings and what they need in return. PayPal brought distribution and needed marketing tools for their customers. Our Marketing Partners had marketing tools and needed distribution.

It was an obvious match, once we mapped it out.

2. Design win-win-win structures

Every partner needs to “win” in these scenarios: Partner A, Partner B, and the platform. Without mutual and meaningful value exchange, the system breaks.

3. Provide air cover and incentives

Partners often won’t organically collaborate - they’re busy building their own businesses. And they often don’t trust other partners. You need to build that trust for them, whilst removing friction and adding motivation.

Facebook ad credits were a crucial component of the PayPal partnership - if we had “skin in the game” it was easier for other partners to trust the process and commit.

4. Think big, start small

Start with small pilot programs that involve a handful of partners: 3-5 usually creates enough incentives and value-mix. If I’d tried to co-ordinate 10+ partners in the PayPal example, it would likely have failed miserably. Prove the model works first.

5. Measuring Success Beyond Revenue

In the PayPal example, of course we tracked traditional metrics like revenue, customer acquisition, and retention, but we also measured relationship health:

• Partner integration rates: which partners were actively working together?

• Customer satisfaction: Are customers getting value from each partner?

• Time to value: How quickly do these new partner combinations generate results?

In platform ecosystems, everyone can win

The best platform partnerships teams don’t just manage relationships - they architect connections between every player and partner in the ecosystem. When you successfully get partners to partner with other partners, you’re not just facilitating transactions between them.

You’re generating case studies, playbooks, examples - gravitational pull - that creates value, attracts more partners, and builds defensible moats around your platform.

Your partners should be partners, too. It’s your job to help them discover each other.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

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, Nanigans
  

• Customer 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.com
  

• Indie 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.

Subscribe now

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

Subscribe now

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.

Subscribe now

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.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.

Cloudflare posted stellar Q1 2025 results, with 27% year-over-year revenue growth, 23% growth in large customers (>$100,000 annualized revenue), and a dollar-based net retention rate of 111%. That was music to the ears of those on Wall Street, with the stock popping +2.3% intraday and rallying since then to almost $170 - a 40% gain in less than a month.

The best bit? Partners had an outsized impact on these results. Here’s some stand-out partnerships strategy lessons from Cloudflare’s Q1 2025 earnings call.

1. Make partners your force-multiplier

For Cloudflare, channel-sourced ARR is compounding faster than direct, with their channel business growing 60% year-over-year, now representing 23% of revenue - up from 15% a year ago.

Partners drove ~$110 million of Cloudflare’s $479 million Q1 2025 revenue.

Partners aren’t just helping Cloudflare scale product innovation or existing customer relationships - they’re also helping Cloudflare land new deals. Cloudflare CEO, Matthew Prince, even mentioned a sizable partner-led deal in his prepared remarks:

“A large US government entity signed a two-year $6.2 million contract for Zero Trust. This customer evaluated several vendors to comply with new Federal Zero Trust requirements, and Cloudflare ultimately stood out as the vendor of choice due to our world-class security products and the breadth of our network. This was a partner-led deal and a great example of the progress we continue to make with our partner-first motion.”

Matthew also mentioned another interesting improvement in Cloudflare’s business:

“…another double-digit year-over-year improvement in sales productivity. We saw quarter-over-quarter improvement in our sales cycles even as we closed larger deals with more sophisticated buyers. And our new pipeline attainment was ahead of our forecast.”

Double-digit likely means a +12-15% improvement in sales productivity over the previous year. In practice this means more ARR per rep without adding incremental headcount. Creating a lot more operating leverage for Cloudflare.

Are these sales productivity improvements influenced by partners? Absolutely.

36% of the Fortune 500 are paying customers, and there’s no way Cloudflare could serve their needs - alongside the needs of 250,000+ paying customers in 190 countries - on their own. Cloudflare simply must be partner-first to serve each of them well.

Subscribe now

2. Measure what partners move

It’s no accident Cloudflare keeps a close eye on large customer contribution (the % of total ARR coming from accounts >$100k ARR), sales productivity, and channel mix.

Each of these is closely related - one very much influences the other.

Of course Cloudflare also keep a close eye on dollar-based net retention which is still strong at 111% - and they say large customers are a long-term tailwind to their DBNR.

So, what can platform partnerships teams learn from this? Three lessons:

1. Instrument at the opportunity level (wherever you can)
   Simple CRM tags for partner-sourced, partner-influenced, or direct can go a long way. Roll these up into large customer contribution and dollar-based net retention dashboards to answer the question “do partners help us win new customers and keep them longer?” Money talks, even for product-led partnerships teams.
   

2. Slice partner sourced/influenced by customer size and cohort
   Dollar-based net retention will almost always look different for enterprise, mid-market, and SMB customers. The same will be true of partner influenced and partner sourced deals. A rising partner tide should lift the enterprise cohort fastest (as Cloudflare’s revenue growth inside this segment shows, and as I’ve witnessed myself over the years).
   

3. Surface “partner-first” stories
   Was Matthew Prince directly involved in the $6.2 million contract for Zero Trust mentioned in his prepared remarks? Probably not - he’s running a 4,400 employee, publicly-listed company. The deal was likely surfaced to him from the partnerships and/or sales org to highlight the value of partners to Cloudflare. Storytelling must be a core skill for every platform partnerships team. The more mindshare partners have, the more they’ll feel like “part of the extended team.”

Subscribe now

3. Flywheels spin faster in an AI-first world

AI is an important inflection point for Cloudflare, and for its partners. It creates new opportunities to follow through on a “Consistent & Deliberate TAM Expansion” plan.

Cloudflare talked about three AI-first updates in their Q1 earnings call related to Anthropic’s new MCP standard, hyperscaler displacement, and VAR-influenced credibility.

Cloudflare’s platform flywheel has already been spinning up for a while. AI is already making that same flywheel spin faster. Matthew Prince again:

“The number of Cloudflare Workers AI inference requests powered by our network are up nearly 4000% year over year. The number of requests running through our AI gateway are up more than 1200% year over year. We continue to invest in the future, building the first, fastest, and most powerful model context protocol or MCP server.”

4000% year over year growth is impressive, even by “AI” standards. Much of that growth is being generated through partnerships with market-makers like Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow.

These types of partnerships are quick-fire “bets” - likely without any negotiated agreements or commitments. The mutual goal is to get out ahead of the market and become known as AI-innovators. But for Cloudflare, AI inference and gateway requests already seem to be generating incremental revenue value.

Moving fast with partners also helps Cloudflare uniquely position itself vs hyperscalers like GCP, AWS, and Azure. Each fast-moving MCP integration (and partnership) helps Cloudflare tell their unique platform story.

Matthew Prince, yet again:

“And I think that that comes back to the fact that the team has just built such a robust platform at this point that, that that people are saying we’re gonna move off the traditional hyperscalers and move to Cloudflare because the ROI is just so much better, the performance is so much better, and and the development philosophy is so much better.”

These stories aren’t just powerful because they’re Cloudflare’s to tell - partners can tell them, too. Every little win - thenZero-Trust deal, MCP server launches, and AI capability growth - make Cloudflare an easier sell for partners, too.

Partners also bring their own credibility to the table. AI-first is an opportunity for most businesses, but also a perceived risk. A government-accredited VAR brought Cloudflare in for a $6.2 million deal - that VAR helped build trust between Cloudflare and the customer, faster.

Cloudflare’s Q1 2025 shows us that a strong combination of platform, partnerships, and a new technology wave can - combined - create a vast amount of market value, quickly.

Subscribe now

If you enjoyed reading this post - or would like to ask me a question - comment below or reach out to me on LinkedIn.