Technology alliances

This in-depth article covers the types of technology alliances and success factors for these partnerships at the product, sales and marketing levels.

Technology alliances create a superset of your own product, which customers can use, ideally seamlessly. They are part of a build vs. buy vs. partner strategy.

The business case for technology alliances

Pragmatically, few companies, if any, can address the entire set of use cases for a given market. Within each market, products tend to also address part of a business or customer workflow, while leaving important tasks unaddressed.

A business application can have a full set of core features, and yet significantly benefit from third party vendors providing data backup, archiving, or content acceleration over the network for faster performance. This example highlights the fact that the technical skillset to create business application tends to be different from the technical skillset of network performance, or that of data backup, restore, and archiving to cold storage.

The business case for technology alliances stems from the following considerations:

• What do customers and users do with a product, which leverages a third party?
• Is there a technical benefit for customers and users from improving the integration with these third parties?
• Is there also a business benefit from vendors working together in sales engagements, to refer business to each other, and co-market?

Product integration

Standalone integration

In many cases, technology integrations and loose alliances can happen without a contract between the two firms. Developers and engineers in each organization can simply read the public product documentations, listen to what customers are requesting in terms of enhancements, and make it happen within each of their products.

More formal relationships can accelerate the process by having service level agreements, known technical contact points who have context for what each party is aiming to build, and stated goals either in a term sheet or contract. Still, in this base case, each of the two or multiple products are sold standalone. They are however more compatible, and perform better together.

Steps toward a joint product (“combined product”)

Technology partnerships can progress to a model of distribution, or embedding. Some of these steps can include:

• A reselling model, in which product A resells product B (partner product). Reselling occurs on a case by case, from customer demand.
• An OEM model, in which product A embeds product B into its core product. Unlike reselling, the embedded business models tend to apply to every unit of product A which are sold.

The critical role of documentation in technology alliances

Product and technical documentation play a central role in building successful technology alliances. Many founders, when asked why their product became viral and widely adopted by their technology ecosystem, noted that their product had very clear and detailed documentation.

Doing so allows developers and engineers from third parties to understand the functionalities and features at a deep level. It also allows them to create technical integrations via APIs or other methods, simply by reading the docs. Your technical ecosystem may create virality and adoption for your product through documentation, and by rarely or never asking anyone for answers or technical help. They will find these answers and insights on their own, which is fast, and scalable.

Technical support strategies when stacks involve third parties

In standalone integrations, each company supports its own products. Beyond this basic case, there are ways to formalize joint support so that customers can enjoy a more predictable and collaborative. This can be done between two companies with a support agreement between product teams. For example, this allows engineering teams in each of the organizations to provide technical support and bug fixes to one another as they work on the integrated product experience.

It can also be done through a collaborative support network. Members can then work with one another on a one-to-many basis, instead of having to draft bilateral agreements every time.

Co-marketing for technology partnerships

Technology alliances can also place an emphasis on joint marketing and selling. This can be done with a baseline of product integration, or in addition to an enhanced product alignment.

The developer and technical audience

Developers tend to focus on the product side of partnerships, with the works described earlier in this article. They also value documentation for the combined products, that they are not left with understanding each standalone technology.

Some of the developer marketing initiatives can include:

• Technical roadshows, webinars and conferences.
• Free credits to the joint products for testing, development and when it makes sense, light production usage.
• Co-branded giveaways.

Non-developer and non-technical audience

End users of joint products or combined products tend to be less technical (with exceptions depending on the product and market). As a result, the messaging and co-marketing can focus on:

• Features and functionalities of the joint product.
• Branding

From a sales perspective, technology alliances can include a significant demand generation component, with referrals and lead sharing.

Partner marketplaces and catalogs

Over the past decades, many technology alliances have taken shape through partner marketplaces. The marketplace provides a baseline of resources for partners to build their product on top of the platform they are provided with. Examples include mobile phone app stores, business application app stores and marketplaces.

As each marketplace becomes the place for customers to search for, and discover new products, the dynamics tend to create network effects, as we explain further in The Mind Share Market.