test test

I’ve worked in partnerships at two companies now and I often get questions from friends and peers asking me “what does it actually mean to do partnerships?”. Well, I’m actually still figuring that out myself, but I thought I’d share more about what I’ve learnt so far, the frameworks I use to approach partnerships, and some deep-dives into great and not-so-great partnerships. But first, I’ll spend this post explaining a bit about why they have become so key to the wider business ecosystem, and especially tech.

At its very highest level, I’d describe a partnership (or others may say business alliance) as an ongoing relationship between two organisations that seeks to help both parties achieve their objectives. Key drivers tend to be innovation, revenue growth, access to new markets, and access to new customers. As Jagdish Seth outlined in his analysis of business alliances almost 3 decades ago, this relationship is deeper than that of a seller-customer relationship or even an investor-founder. It only falls short to mergers & acquisitions in relationship depth.

Even though the commercial structure has proliferated, there has been a distinct lack of literature on partnerships in business when compared with other areas such as product & management. Studies show a 600% increase in articles covering alliances/partnerships between 1993 and 2012 in relevant journals, but nonetheless the term is still ambiguously defined, with different job specs across companies. 

My main mental model is to break these down into two separate pillars: ‘buy-side’ partnerships and ‘sell-side’ partnerships. The ‘buy-side’ seeks to reach objectives by leveraging a partner’s product. ‘Sell-side’ partnerships help third-parties reach their goals while also gaining a new distribution channel. A partnership can combine just one or both of the ‘buy-side’ and the ‘sell-side’. 

Where alliance structures used to be quite rare and less “sexy” than M&A, they’ve gradually become more common. The dynamic of partnerships has transformed since they began in the post-war era – shifting from enterprise alliances to ecosystem development. Let’s dig a bit deeper into the history of alliances and partnerships to help contextualise why they arose and how trends are shifting.

In the post-war era, strategic partnerships were largely limited to large enterprise businesses with existing distribution channels and large legal teams to negotiate complex deals. A great example is in the travel industry — in the 90s, five airlines partnered to form the “Star Alliance”, sharing offices, operations, and facilities which in turn benefited consumers with lower costs and greater choice. However, due to the complexities of building and joining this alliance, it was limited to the largest players in the industry, and also limited to a scale where the marginal cost of adding a new partner was greater than the marginal benefits they added to the alliance. By 2006, it only had 18 members – a fraction of the thousands of airlines globally.

In the 1990s, software was similarly lacking in scaled solutions. The market was dominated by on-premise solutions, meaning businesses would need to install software on their own servers via a license. For instance, Oracle and SAP dominated the ERP market during this period. Within their commercial construct, partners were defined as third-parties that could install the ERP software on behalf of the end-users. Each integration was highly bespoke and local; if an end-user wanted a new application, a system integrator (basically a development shop specialising in a platform) would need to build it specifically for their integration. This benefitted the partners in the short-term by giving them regular and recurring projects, however the localised solutions meant the network effects were minimal. These solutions weren’t listed on an app store, they had to be built each time, worsening the end-user’s experience.

Salesforce was founded 2 years after Star Alliance and recognised the opportunity to be had via partners. They were cloud-based from the start, which meant customers could suddenly self-serve both Salesforce’s software and additional applications on the Salesforce app marketplace. 

These cloud-based services enabled third-party partners easy access to the Salesforce software to build functionality on top. In 2004, just 5 years after foundation, Salesforce had over 150 independent software vendors building apps on the Salesforce infrastructure. With this dynamic, Salesforce flipped the scale problem on its head – their network benefited from each incremental new partner and app, with low (if reducing over time) incremental costs to adding a new partner. Oracle and SAP had to play catch-up. In 2004, Oracle had 91 partners, even though it had been founded 22 years before Salesforce. 

Yet into the 2010s, alliances were viewed as off-limits to startups – a distraction from the core focus, finding product market fit. Paul Graham critiqued BD teams in as a distraction in his seminal essay “do things that don’t scale”:

Partnerships too usually don’t work. They don’t work for startups in general, but they especially don’t work as a way to get growth started. It’s a common mistake among inexperienced founders to believe that a partnership with a big company will be their big break

I agree with his point that startups shouldn’t allocate unnecessary resources to certain deals, whether that be changing the product roadmap just to get access to one new large channel to market, or wasting commercial resources on indirect channels where direct should be the main focus. 

However, Paul wrote this in 2013 when the paradigm shift was beginning. In the same year, Shopify had only 82k active merchants and Stripe had just launched Stripe Connect. Both were examples of platforms with a self-serve, API-centric strategy. This meant that a startup could easily add functionality and distribution to aforementioned platforms while also enriching their own functionality. I could build a solution related to Shopify and then access their wider community of businesses. This shift was transformational, and hasn’t been acknowledged enough. 

APIs provide far more scalability when compared to complex commercial structures of old. The key benefit is that information and data becomes the main resource shared, not physical assets. For decades, small airlines like Air Malta had been unable to get access to the huge demand for air travel since they had access to trivial demand relative to large airlines and alliances. When Air Malta worked with third parties to build their own API, they reached profitability for the first time in two decades.

This was achieved via access to new distribution channels, including listings on the Ryanair website. They didn’t need to scale their team to a size necessary to manage such a partnership. It was entirely automated. Meanwhile, Ryanair was able to enrich their offering with new and more frequent routes using the Air Malta fleet. They most likely also received some form of ‘commission’ as the gatekeeper to their own marketplace. The incremental benefit was significant, while there wasn’t really any incremental cost by adding Air Malta. To Paul Graham’s point, it would have been an  immense waste of resources for Air Malta (or a startup similarly seeking a distribution opportunity) to either build a direct integration into Ryanair or to chase a partnership, but the provision of an API solved (or at least mitigated) both issues.

This brings me onto my next point – that APIs enable businesses to self-serve their relationships. Businesses across sectors, from Shopify and Stripe to Ryanair and Kraft, can build APIs that are open to third-parties. There doesn’t need to be any complex deal or legal work as the API is “cookie-cutter” for the majority of use-cases. Startups can build functionality on top of a larger incumbent and then benefit from access to their channel. For Shopify, that means a new partner can suddenly access 1m ecommerce businesses, 87% of which use at least 1 partner app regularly. 

That’s a huge market for a new business that otherwise would have been largely off-limits until they reached scale or built their own direct channel to market. In 2019, the Shopify partner ecosystem generated $6.9bn in revenue, over 4x Shopify’s $1.5bn 2019 direct revenue. Shopify, Salesforce, and many other platforms like to boast about the size of their ecosystem because it demonstrates they have an ecosystem more valuable than the separate parts. Ben Thompson calls this “the Bill Gates line”, which differentiates a platform from other commercial structures. As Chamath recalled in his interview with Semil Shah from Hatstack VC, Bill Gates once told him:

A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.

By adding more partners, the platform creates a network effect. Eventually, there comes a critical point at which new businesses are starting up purely to service users within their ecosystem. Accounting platforms are a great example. Sage & Xero have both built robust app marketplaces, with some apps like Xavier (analytics for accountancies) built purely to service the Xero community. While it may sound niche, it can be a recipe for success. Xavier was recently acquired by the later stage Receipt Bank, another business that deeply depends on the wider accounting platform ecosystems while also adding their own unique functionality.

Modern partnerships do still cover the traditional enterprise alliances between two enterprises, but that isn’t the sole focus any longer. Instead, the goal is to build rich and robust ecosystems that can easily serve new partners at scale, rewarding those that provide functionality, and/or distribute into new markets. This is a cross-functional role, where product and engineering are also key stakeholders to make sure the product grows into and with distribution opportunities and/or that the partner provides the right functionality. For most, if not all companies, the defining question for any partnership should be “how can this improve our product for our users” or “how can this allow me to access a strategic market sooner/cheaper”. They aren’t an alternative to finding product fit and deep user focus, but they can enhance a business’s existing offering and provide a new channel to market without being a distraction.

Successful startups of the future won’t have spent months or years working on a large distribution deal with an enterprise partner, but they will have a strategy to build a wider ecosystem. They should know the right which markets they want to capture, which organisations they should ally with to reach them, and when they will be at a scale to engage a complex deal. While partnerships can be produced earlier today than in any era before, startups should also know when not to chase partnerships, and when to focus on direct sales and product market fit.