Originally posted on Andreessen Horowitz
Nearly every early tech startup at some point gets enamored with the idea of partnering with another tech company. This is usually driven by the heady, very seductive idea that a partnership will accelerate credibility, sales, and minimum viable product (MVP) quickly and more easily than doing it yourself — by using another company’s resources or by drafting on the traction of an existing platform. Those are very appealing propositions to a resource-strapped startup that is scrambling for a real, repeatable sign of product-market fit.
The problem is, these technical partnerships rarely work if you’re in an early or “pre-chasm” market. [By “technical partnership”, I mean specifically a partnership with a company whose primary business model is selling a tech product — in contrast to partnership with the channel whose primary business is reselling and value-added services around someone else’s product. Partnering with AWS, Google, Microsoft, Cisco, VMware, Salesforce and other products startups, for example, would all be technical partnerships, while VARs, resellers, consultants, integrators, and distributors are not.]
Tech partnerships also have downsides that more often than not outweigh the good: in reality, they can require a tremendous amount of resources, give away your secrets, damage your relationship with your customers, commit you to onerous terms that may poison your company for future strategic relationships. I made this mistake many times and had to pay the full range of those consequences; I write this post from the position of extreme skepticism and paranoia exactly because partnerships are so appealing to first-time tech founders. So I hope in this post to cast a bit of shade — and hopefully save you time I wasn’t able to save myself.
Partnerships with other startups
Startups often try to use technical partnerships as a way of engaging the market before they’re really ready — or before the market is ready for them. The product may not be full-feature complete; the community is still small; or, most commonly, the go-to-market function is nonexistent or immature. At this point, founders often believe that one solution might be to find other startups to work with, in the hopes that a partnership will have a multiplicative effect (2×2 = 4, yay!). Common proposals are to “support each other’s platforms” so that the total addressable market grows by allowing each startup access to the superset of customers being targeted by each alone.
This almost never works. While there may be some nominal additive value of a joint effort, all of the things that make startups hard are amplified too — it’s risk, squared. A startup will do anything they need to to stay alive (as they should!). That means pivoting, entering adjacent markets, killing products, changing go-to-market models, open sourcing, changing deployment model, changing pricing model, and so on and so forth. A high likelihood of these kinds of changes are often the only thing you can rely on from a startup. These are often the dynamics that are actually multiplicative (.2 x .2 = 0.04 … oh shit!).
While there may be some nominal additive value of a joint effort, all of the things that make startups hard are amplified too – it’s risk, squared.
Amplified risk is only one of your problems. Even in the most benign case where massive changes don’t cause major misalignments, what happens more often than not is… nothing. One or both sides will expend resources and then drop the project as real business takes priority. On the other hand, when startups do manage to get some traction with customers, they will then sometimes turn on each other — for account control, for improved fractional revenue, or to blame the other party for product issues.
There also tends to be an adverse-selection bias at play in all these situations. If a startup has the resources and time to partner with you, that’s a pretty good signal they’re not at a dead run trying to keep up with market demand. In the early days of Nicira, we tried to partner with all the new OpenStack companies. Now, a decade later, only one of the nearly dozen remain, and they are the one we never had meaningful partnership discussions with. I guess they were busy building a business.
Partnerships with large companies
Startups partnering with startups tends to get obviously bad pretty quickly. Large companies, on the other hand, can appear to be exceptionally attractive partners. They often have formal partnership programs and an established brand — if they are market incumbents, they have a latent customer base just ready for innovation; if they’re not, they have the resources to launch a large go-to-market effort. What’s not to love?
But the hard truth is, large companies use partnerships solely to further their intensely self-interested goals. If those are ever at odds with the startup (which is often, particularly if you’re successful and starting to affect customer behavior), the partnership will very quickly become a liability. Any knowledge shared, access given, or dependency created can now be used against you… and will be.
Large companies are also savvy about who they partner with and why. The majority of their energy is focused on other large companies, where they are often locked into a competitive/cooperative détente. It’s rare that a large company will get much value from partnering with a startup. When they do, it’s generally for optics — to uplift a new platform or product of their own: They’ll be quite happy to add your logo to their slides and website, and they’re quite happy to have you on stage. This is actually perfectly rational behavior for them. A group of startups running around crowing about the partnership gives a large company a nice PR and marketing push; adding a host of logos creates a sense of momentum.
However, it’s also important to remember that the history of our industry is littered with examples of large companies using their leverage to take advantage of small companies, even after an amicable partnership.
A good mental model to use before entering a partnership is to assume — If what you’re doing is strategic, you’ll kick off a build vs. buy decision. If what you’re doing is not, it won’t be prioritized — and is therefore highly unlikely to be resourced sufficiently enough to get anything done. Either way, the outcome is not favorable for the startup. If you’re lucky, you just waste resources, and there’s no gain. If you’re not, you create a competitor with special access to your company.
That said, sometimes partnerships are necessary, or even a good idea. At Nicira, for example, we couldn’t deploy without partnering with the various Linux distributions, the hypervisor vendors, and the cloud orchestrators. So, go into it knowing what to expect. Always assume that:
- They’ll use the opportunity to learn from you.
- If they see a good opportunity to compete, they will.
- If you give them access to customers, they’ll use it to drive their agenda.
- They’re exceptionally unlikely to concede a strategic control point or give you access to strategic accounts.
- They’ll have no qualms killing your company by changing the terms of the partnership, or the technology or channels you’ve come to rely on.
Remember, the “muscle memory” of a large partnering organization is gained through complex (often competitive) relationships with other large companies. Smiling while they stab you is expected and practiced behavior.
Common partnership models
There are many potential forms of partnership between two tech companies. Below I cover the most common that we see between startups and larger companies — and highlight what to watch out for.
You’ll often see a startup granted the “privilege” of integrating with a larger company’s platform through a structured, formal partnership program. This kind of partnership will often allow the startup access to otherwise restricted APIs, or documentation, or a distribution channel, like a package manager. Some platforms require this to interoperate and enforce that either technically (e.g., code signing) or contractually (e.g., voiding support if someone runs an unsupported extension). Others use partnerships primarily as marketing vehicles that are intended to be mutually beneficial to the platform as well as to the participants.
Platform integration like this often looks desirable to the startup because it will both make their product look more mature, and (they believe) create a deeper, more meaningful relationship with a large company — leading to something like the large company actually selling the startup’s product. But platform risk is actually one of the single greatest risks a startup can take on.
Large companies will always preserve the ability to monetize services they build on top of their platforms. Any “special” access you’re given can be revoked at any time. So not only are you educating them on how they might do that, if you are successful in creating an attractive market, you’re almost ensuring they’ll compete. History is so rife with examples like these, that they’ve become hackneyed: Microsoft and the browser, Apple and music, Amazon and any number of AWS services. Remember, to a large company, giving something away for free in order to uplift a platform makes sense — even if it kills off a user of that platform. A very small multiplier on a very large number is still a large number.
That said, there are many cases when platform integration is required and so is unavoidable. For example, it’s hard to sell datacenter software to the enterprise if you don’t support Red Hat Enteprise Linux. In these cases, the obvious (but important!) integration rules apply — namely, stick to industry-standard interfaces, and always prefer public interfaces over private or restricted interfaces. This makes it much more difficult to revoke your access. And if you’re lucky, you may get portability between different platforms as well.
Finally, and most importantly, if you have to go down this path, the most powerful force to guide a partnership with a large company is customer pull. Line up as many customers as you can to ensure that the company you’re partnering with allocates the appropriate and necessary resources to your partnership, and that don’t jerk you around. I have had many experiences of large partners either refusing to partner, or requiring overly onerous terms, and then doing an about-face when one of their larger customers threatened not to renew unless they worked with us. In the end, customers always carry the largest sticks.
In the end, customers always carry the largest sticks.
Another partnership opportunity startups find attractive is to list their product on the solutions marketplace of a larger company — the AWS Marketplace, the RedHat Ecosystem, the Cisco Marketplace, Google’s Cloud Launcher, etc. This is usually rationalized by the idea that it will increase sales velocity by funneling customers to your product. But that actually rarely happens in a market category-creation situation. Your presence in marketplaces like these is simply not enough to educate a customer on the value of your solution. On the contrary, you may lose the enormously valuable opportunity to establish a direct relationship with the buyer.
In an early market, it’s very important that you drive the conversation with the customer, both to understand how they view the problem space, and to set the criteria by which you’re evaluated. Online markets can work against this because they constrain how you present your company because they are often built to enable lower-touch sales. An online market, for example, may define your competitive set based on how they organize the logos in the market — or force you into a simplistic pricing model just because you’re listed alongside other companies who post their pricing publicly.
For early market enterprise companies, you should avoid participating in an online marketplace unless there is (a) an existing buying behavior in your target customer base that will buy through such a marketplace, or (b) marketplace participation is strictly required in order to operate on an important platform. The possible downside of entering an online market while you’re working to understand the market, set the industry discourse around your product, and work towards a scalable sales mode is far greater than the upside.
Joint go-to-market (indirect)
Indirect go-to-market here refers to a partnership in which you bundle or OEM your product to another product company, and let their sales force do the heavy lifting. Many startups view this as the ultimate coup: “We’ll be like the Brocade or Intel and make billions without any sales force!”
Unfortunately, it’s also a tremendously effective way to make your company irrelevant. In early markets, OEM and bundling relationships with existing products is an extremely effective mechanism of self sabotage. There are just so many ways it can go wrong:
- You cannibalize your own market because generally you don’t have direct control of pricing.
- You can’t extract as much value as you deserve, because you don’t have the relationship to demonstrate the value (in early markets, often this involves deep technical discussions).
- With bundling, your product is far more likely to be shelfware, which means that you’re incredibly unlikely to get a renewal.
- You have no point of account control for upsell, expansion, or cross-sell.
- You have no brand stickiness, because the customer doesn’t know you’re powering the solution — and so you can easily be replaced by a lower cost solution once the market matures.
The message here is very clear: In early markets, particularly in deep tech, if you lose account control, you’ve lost your company. Of all the potential partnerships with other product companies, this one is the most dangerous. It’s true that there are always exceptions to the rule, and some startups have pulled this off to phenomenal success (the early days of VMware being one notable example). But you should only do this if you’re able to negotiate an exceptionally favorable deal that doesn’t lock you into one partner, and allows you to maintain direct sales. When Diane Greene set up the OEM strategy for VMware, she was able to get non-exclusive OEM relationships with Dell, HP, IBM, and Cisco. And she did this while building one of the best enterprise software sales teams ever seen in our industry. Almost no one else has been able to pull that off — and it’s likely you won’t either.
Joint go-to-market (direct)
In a joint go-to-market partnership model, a startup will align its sales force with a larger product company. The basic idea is either for your product to be carried by their reps, but sold as an independent SKU (as opposed to the indirect method above), or for a joint selling motion where both of your sales teams are involved in an account. This model is attractive because it promises an increase in sales capacity and access to an existing customer base.
Of all the partnership models, this is the one I’ve seen work the best. Nicira (once acquired by VMWare) had a strong sales partnership with Palo Alto Networks, for example. But this model tends to be best suited for more mature market situations, and they certainly only work with real commitment from both sides. The majority of our joint direct go-to-market efforts failed; a number devolved into messy squabbles with the customer fighting for strategic control or wallet share, or finger-pointing over deployment issues.
I’ll say it again: Customers are the best method for guiding a partnership. A go-to-market partnership should be seen as a coordinated accelerant of an already existing synergy in the market, rather than an attempt to create one out of whole cloth. So you should only engage in a joint direct sales effort with a larger company if you believe that you’ve established a scalable, repeatable sale independently, and if you have enough experience in the field to know that your product naturally aligns with your partner-to-be’s product.
You also will want to make sure that a) your partner is sufficiently committed to the partnership, and b) their sales team will actually help you. Generally this means that there is some incentive for their team to bring you into a deal and get the deal closed. There are many mechanisms for doing this. The most common is giving SPIFs (sales performance incentive funds, a financial incentive) to your partner’s sales team for bringing you into a deal, or helping sell your product. Getting the other company to commit to a product-specific quota on your product is even more effective.
Partnerships are won and lost in the field. Behavior will always follow business, and will be dependent on whether your partners are making money by partnering with you. I believe one of the many reasons VMWare was so successful was that for every dollar VMware made, the partner ecosystem made eight. That said, no amount of will, structure, or effort will create product-market fit if none exists. And no amount of business development meetings and executive assurances will create a friendly relationship if there is naturally a competitive element in the field. So it’s important to only use joint go-to-market with a partner to accelerate a product synergy that’s already been demonstrated organically in the field — and not try to create one.
Tech partnerships are so common — and such a ubiquitous false step — precisely because they are so seductive at first glance. Of course, partnerships do work at times. And if executed carefully, they can be a boon to both sides, so it’s worth entertaining partnering discussions. In the end, though, use the natural pull of the market to guide your partnership strategy, watch your back, and ensure you have practical expectations as to the actual benefits. Otherwise, you’ll have effectively sold your company without collecting payment — and expended a lot of resources to do it.