Partnerships

Product partnerships are an ongoing topic of discussion for any CEO because they’re subject to so many variables. Not only are there different kinds of partnerships, but also different opportunities, depending on the product. Knowing which partnerships are worth pursuing, which last, and which are unlikely to be beneficial can be crucial to navigating the partnership process.

I spoke with entrepreneur and angel investor Scott Banister, perhaps best known as a co-founder of IronPort as well as an early advisor and board member at PayPal. He gave us his perspective on what makes for a fruitful product partnership. His take: Listen to what your customers want without losing sight of your company’s core vision.


Katya: How important are product partnerships for a company?

Scott: They are a mixed bag. First you have to make sure that you’re executing well on your core business; if you’re not, no partnership is going to save you. Google’s partnership with AOL in the early days was a big deal to Google, but it didn’t save them. They were doing well with their core product as it was, and the AOL partnership just helped them to distribute it to a wider audience. If their core product was crap, then it wouldn’t matter if they started putting that crap product over on AOL; it still would be crap.

Katya: There’s a notion out there that if a partnership is not equally beneficial then it’s going to flop. What is your perspective?

Scott: I don’t know if it has to be equally beneficial; it just has to be mutually beneficial. If both sides are benefiting, the benefits do not have to be equal to be successful.

Katya: What makes a partnership successful?

One thing to consider is how you are using the term “partnership.” It’s more commonly used to describe a relationship between two larger entities, and in that case, it’s done on a more one-off type basis as a highly negotiated business development deal. Apple is in a kind of partnership with all of the people developing Apps for the iPhone, but they’re not out negotiating each partnership arrangement. Of note is how the Zynga relationship with Facebook started and evolved: Facebook launched a platform; Zynga took advantage of that platform and then became the largest user of that platform. On the back end they had more of a partnership with Facebook than “Joe Random” developer.

Platforms that make it easy for essentially anyone to partner with a tech product company, historically, have been the most successful - Windows and iOS are prime examples. I think you commonly see that now, there are a lot of APIs available. So going back to what I mentioned before, there’s a spectrum of what a business partnership is and what is just taking advantage of an API that a company has made available. I think you’re probably more likely to be successful with the API model. Windows is just a set of APIs, as is iOS; when Facebook launched their platform, that was really just a set of APIs.

Katya: Coming back to the more major types of partnerships—specifically as they might relate to LiveJournal—I could partner with WordPress, Spotify and various other companies for certain features, or I could have users register with Facebook so people don’t have to create a LiveJournal login, for example. Where do you start and where do you stop? Where do you think that it’s more beneficial to develop your own features rather than partner with a company that already has something established?

Scott: I don’t think the way to make that decision is to think about partnerships. I think the way to make that decision is to think about product, and then that’s fundamentally a product management question. The way to resolve product management questions is by trying to figure out what the customers want and then work from there. You don’t work from, “Here is the list of companies that I could partner with for the features that I could use,” although that may inform your knowledge of what’s possible. You work from, “This is what our customers want from our product,” and then for each one of those things, you decide, “Well, I could build that myself, I could acquire someone who has that, or I could partner with some third party.”

Katya: Once you determine your customers’ needs, how would you analyze when it’s better to build versus partner? For example, if we wanted to integrate music into LiveJournal, I could build our own music player, but most likely big percentage of LiveJournal users already have a Spotify account. So should I build my own player and build it the way I want to build it, or should I go and partner with Spotify because they might want customers in a country where LiveJournal has customers?

Scott: There are a few things to evaluate. Since you’re doing this for your customers, you have to figure out what your customers would prefer. For instance, with a music player, you may find that your customers already use Spotify for their music, so therefore they don’t just want a music feature, they want a Spotify music feature. Your customers may not care. If your customer doesn’t care, then other considerations come into play: Do you want this to be an ongoing focus of your business? Do you want to take responsibility for this part of your business? Would you rather get the feature from somewhere else? If you get it from somewhere else, are you okay with being in bed with that someone else for a potentially long period of time?

Katya: What do you think the consequence would be of living in an infrastructure where each of us might have a new product, but we empower that product by taking features, APIs and codes from many different web services instead of creating them on our own? It might move us faster, but does the innovation slow down?

Scott: I think that’s partly what is happening. The tech industry is historically a story of building upon itself. Intel is making processors, Microsoft is shipping operating systems, and Lotus is shipping out applications. You export some APIs to others, and you import some APIs from others as well; that’s bound to make things more efficient. I think that is clearly a good thing, and I believe what’s becoming more and more common is that people realize that part of their business strategy is likely to involve the importing and exporting of APIs.

Katya: Do you think the tech industry will get to a point where all code will be open source and people will use whichever parts of a code they want? Or is that just not realistic?

Scott: Open source is different from exposing APIs. No, I don’t think it’s likely that the tech industry gets to a point where everyone is exposing all of the software that they write because there is a lot of value in the software. Everyone goes through a decision-making process for each piece of software they write: “Do we want to keep this software as a trade secret, or do we want to release this software as open source?” Part of how you make that decision is, “If we release it as open source, other people get to benefit from it, but we also benefit from the fact that a larger community is using it and enhancing that piece.” So you make different decisions for different reasons. But I don’t think you see it all go open source; that seems incredibly unlikely.

Katya: How do you decide whether or not to release your product to open source?

Scott: If you’re going to release something to open source, you don’t just make that decision based on, “Is it ok for our business if we release it to open source?” There’s work associated with releasing it to open source. You have to patch it up, you have to be able to release it, it has to be able to be improved upon, and you have to be able to reintegrate those improvements back into your core product. So there are aspects of your product that you’re going to build that, while maybe you don’t particularly care whether they’re trade secrets or not, you’re still not going to package them up as open source because there’s no clean way to carve them out and put them out there. I think there are things that strategically make sense to release as open source and things that strategically make sense to keep as trade secrets, and then there are things that fall somewhere in the middle where it is not even worth your time to try to figure out; therefore it just ends up being secret by default.

Katya: How do you feel about exclusive integrations? For example, you can only log in to Tinder with Facebook. I personally (and, I guess, many other people), have serious issues when services will only let users sign up with Facebook, but would Tinder have grown as fast without that seamlessness?

Scott: I think it’s been proven that consumers like Facebook Connect. Even if you offer them a choice of Facebook Connect or creating their own account, the majority of users will choose Facebook Connect. In some cases it’s also beneficial to the business to encourage people to use Facebook Connect. For example, it makes it more likely that a person provides a photo, and it provides some sort of verifiable identity; that helps make their product better.

Katya: But I don’t have a choice. And I have a problem with that.

Scott: Is it good for every person in the world? Maybe not. I think you can always argue that more options will be better for certain people, but options always come at some cost to the complexity of the system, and not just in software design complexity, but also in system design complexity.

If you look at successful companies and products, simplicity tends to be one of their product values. When you’re evaluating your product, product roadmap and user interface, you have to keep simplicity in mind. If there are features that are being built up over time, eventually you may have to repeal some of those features because you might end up creating too much complexity.

Katya: Thank you so much for your time, Scott. I just have one last question: which product do you think will blow up in the next 24 months that is in the very early stages, or that we haven’t heard of yet?

Scott: I’m going to be boring and say the Microsoft HoloLens might be a big deal.