Partnership

Origin & evolution

The key-partnerships block belongs to Alexander Osterwalder and Yves Pigneur's Business Model Generation (2010). They sort partnerships into four types: strategic alliances between non-competitors🥊CompetitorMarket IntelligenceA competing product or companyView reference →, coopetition between competitors, joint ventures to build new offerings, and buyer-supplier relationships that secure reliable inputs (OpenStax). The canvas frames three motives behind any of them: optimisation and economies of scale, reduction of risk🎲RiskComplianceA risk to the product or businessView reference → and uncertainty, and acquisition of resources or activities a firm lacks (Strategyzer).

Coopetition is the most counter-intuitive of the four, the case where direct rivals cooperate on a shared layer, often to reach the volume that makes an activity economic for either of them (OpenStax). The framework's value is that it forces a firm to name its dependencies explicitly, which is where buried risk usually lives. A model that quietly relies on one supplier or one channel partner looks sound on paper until that partner changes terms.

How it works in practice

A fintech offers consumer lending. It cannot hold deposits, so it forms a strategic alliance with a chartered bank that originates the loans; the fintech handles the app and underwriting. That single partnership is the spine of the model. It governs the relationship with a contract specifying revenue share, compliance obligations, and a two-year term.

It also runs a buyer-supplier relationship with a credit-bureau data provider, and a partnership with a payments processor whose API it embeds for repayments. When the bank partner signals it may not renew, the risk the canvas was designed to expose becomes concrete: the lending model has no second originator. The fintech starts a parallel alliance with a second bank, accepting thinner margins for resilience.

Partnership vs. its neighbours

• Integration partner🗿Integration PartnerPartners & EcosystemAn integration partnerView reference → is a narrower, technical relationship: a third party whose product connects to yours through an integration. A partnership is the broader business relationship, which may or may not involve any code; an integration partner is one kind of partner, defined by the integration itself.
• Partner program🎗️Partner ProgramPartners & EcosystemA partner programView reference → is the scalable, templated scheme through which many partners are recruited and managed at once. A partnership is one specific relationship, often bespoke; a partner program is the machinery for running them in bulk.
• Key activity🛠️Key ActivityBusiness ModelA key activity the business performsView reference → is something the company does itself. A partnership is precisely the activity or resource it has chosen to source externally, so the two blocks define each other by what falls inside the firm versus outside it.

In the graph

In the Unified Product Graph, partnership🫱🏻‍🫲🏼PartnershipBusiness ModelA strategic partnership sits in the business-model domain and connects through business_model_partnered_via_partnershipBusiness Modelpartnered viaPartnershiphierarchy, anchoring it as a building block of the model. A contract_governs_partnershipContractgovernsPartnershipcross-domain edge attaches the legal terms, keeping the relationship and its governing agreement as separate nodes, and partnership_with_integration_partnerPartnershipwithIntegration Partnercross-domain links a business partnership to the specific integration partner that realises it. That separation lets the graph distinguish a relationship from the contract that binds it and from the technical integration that expresses it, so a dependency can be traced from the model down to the clause that could break it.