Strategy & Implementation of Third-Party Connections in Products

Building a product that connects to multiple third-party products is a common approach — an annotated twitter thread exploring strategic and execution challenges.

Source: Clipart

1/ Many enterprise products rely on a “provider” or “connector” model to be fully capable. This is much harder than it looks and much more of a potential failure point than most might think.

A thread on strategy, implementation, challenges.

Frequently in building a new product (company) at some point in the pitch you hear “oh we’ll build a connector” or “we have a provider architecture”. When stated this way it often comes across as a pretty straight forward addition to both the business and product architecture. In practice this is enormously difficult to pull off in a sustainable and complete manner.

Your strategy is always clear — you are building a product that must connect to data, expose functionality, or rely on a 1:many set of partners to be fully realized. Examples: connect to SaaS data, auth models, logs, join n products into one experience, analysis reporting, etc.

The strategy starts from the basic assumption “of course we will want to connect to all the major <X> vendors and that provides a complete solution for customers”. No one disagrees with this. Whether you are building a data analysis package that “joins” (in the DB sense) SaaS data from multiple vendors, provides a rich user interface across multiple silo products, or analyzing data from multiple sources this is an obvious customer need.

SaaS/cloud does not make this new — the world of systems integration or “ETL” have been talking about this for decades. What’s new is that there’s an assumption that the cloud makes all of this easier. In fact one might argue even though there are APIs, actually implementing this sort of approach is even more difficult these days than in the days of directly accessing SQL tables of direct connection via DB drivers (like ODBC).

The benefit to your product is obvious. The core strategy question is why does anyone care about your problems. Everyone is always busy. Everyone always wants to serve customers more. Not everyone feels their product has big holes waiting to be filled in.

Customers hear the pitch and love this. I mean who doesn’t want all their silos of apps to easily connect? Who does not want to do a “join” between ticketing, demand-gen/upsell programs, and CRM or something like those?

This is especially true if your product is trying to slot in to a product/stack that is itself expanding. For example, most building reporting/analysis “compete” with the native capabilities even though most native capabilities are far behind and slow to improve. Grrr.

There’s often a base assumption in building connectors that the semantics (data) or experience (UX or feature set) are somehow “fixed” among potential providers/connector “sources” and so there’s an opportunity to be a sink for those. Unfortunately in any dynamic/growing market the sources are all actively moving both up/down a stack and potentially across the stack.

Consider customers that deploy ERP from one vendor. ERP is notoriously adjacent and dependent on a database at the low end, a variety of infrastructure at the base level (identity for example), and of course a broad set of potentially adjacent “app” level products (applicant tracking, expense reporting, employee experience, etc.). At any given time building something that requires a provider to be built by an ERP vendor means you are likely potentially bumping up against the strategy the ERP vendor has for growth. An example of this is SAP and how it has grown (via a bundle!) both up/down and across the range of capabilities. SAP HANA even built its own database, so take that #1 partner Oracle!

In practice the third party product probably has no interest in being “dis-intermediated” and so won’t likely want to just be a source of “data” or give up “user experience” just to appear open, especially to a startup.

One of the most common mistakes made by both end-customers and new products building a provider architecture is that existing companies are open to being “disintermediated” by a new entrant into the market. This one-sided view of the situation is all too common.

A good “consumer” example of this is twitter. Early on the world, including leadership at twitter, were very open about their API and were very happy to allow third-party twitter clients. The community embraced this. I have to admit I remember hearing an interview about this topic with then twitter execs and thought “well this isn’t sustainable” simply because a third-party client would prevent twitter from exposing any new features in a timely and consistent manner, especially monetization. It was experience with email and messaging that informed my views on this — the difficulty of evolving this category by only taking a client or server view and not a full end-to-end view.

Classic challenge is “access to data”. Most data sources have APIs but these are almost always “read-only” and not designed for bulk access, reporting, updates, analysis etc. If you have multiple third parties in same category, chances are data access is also uneven/different.

The other half of disintermediation is the idea that companies with a successful solution will be excited to provide data access. To me this is the key issue with SaaS today. Unlike past on-prem solutions, today’s SaaS applications have pretty rich and accessible APIs to the data which leads to the impression that companies are open to access to data. In practice this isn’t really the case.

These APIs, as we know, are almost never designed as structured access to information but are generally straight forward OBJECT APIs that support GET and ITERATE methods rather than bulk retrieval and certainly not bulk updates. Rarely are you getting access at an implementation level but rather access is at a higher level of abstraction. This is for a whole host of reasons from scale to safety to versioning over time.

This means that APIs are basically “reports” or “flattened” views of data. This leads to many provider architectures that attempt to cache large amounts of data in a middle tier in order to rebuilt/recreate the structure to enable reporting, analysis, joins, etc. For a whole host of reasons, your provider solution really can’t be a cache of data (security, privacy, etc.) This can work, but it is very rare and the value really needs to be unique (eg Blackberry Enterprise Server).

Then even if you can figure this out for one provider of data, the challenge is that the provider API developed will have substantially different implementations and performance profiles for each different data source. Email again is another place where this shows the challenge. If you want to connect to both O365 and Gmail the protocols and characteristics of each are just too different to really provide anything more than a least common denominator experience across them.

What it so tough here is that often the problem you are solving is one expressed by customers as in “the reporting engine is awful” or “we always need to combine multiple sources of data” or “they don’t have a mobile app”, or “we use X and Y together”, etc.

The other area of disintermediation is one where no company wants to give up which is in expanding an existing category. Quite often this is in the area of reporting or analytics that cross multiple categories.

Most all new business apps require some level of reporting. While there are many open source tools for the basics of charting and analytics, the work to build out a great solution in a new product that isn’t primarily reporting is usually backburnered early on. Most every early stage company gets feedback that they need better reporting. This in turn creates opportunities for third-party tools which then need connectors to a broad range of data sources.

The problem runs up against the business reality of all these companies selling solutions that are the data. These companies are invariably focused on broadening the use of their product to more “seats” and that means making the reporting or dashboards consumable by more people. Ultimately this implies some level of disinterest or even hostility to a third-party solution aiming to block that opportunity.

All of this is happening under the guise of supportive customer feedback or insights. You’re receiving lots of affirmation that a provider/connector strategy is needed to plug holes in existing products. It is just that the product with the holes isn’t so open to an approach. That’s the trick.

So a first step from a strategy perspective is to have a super clear view of a value proposition for third parties. Why does their product get better if they support a provider/connector model? *And* why doesn’t it get worse? Both relative to their roadmap you might not know.

Before you build a connector architecture you want to understand why the product you are connecting to will get better because of this work. This is for two reasons.

1. It is likely you will need help from the company you are connecting to and if your “story” for the connector is not one that improves their product, that help will be tough to come by. In addition to help, understanding the roadmap and long term stability of what you are connecting to can come from this sort of relationship.
2. At some point you will not be able to build all connectors yourself and would love to reach a state in the market where other companies build connectors to your product as part of their plans.

Often non-product attributions play into analysis. The third party might be willing to cede some control for a substantial opportunity to improve the product, gain distribution, or connect with new customers. Learn what providers might want to improve — treat them like customers.

The product you are connecting to might have all sorts of shortcomings, many of which you might know about and/or address with your product. What you want to understand is if there is alignment between you and that company with respect to these shortcomings. Do they see the market challenges and opportunities the same way you do? Building connectors is a product design challenge just like any other feature, but the customer is the company that builds the product you are connecting to.

Beyond the product dimensions, the question becomes how does the presence of your product connecting to their product improve things for them? Do you help them to gain distribution, new customers, new market segments, or maybe you help them to secure fragile customers they are losing in the marketplace. Even with those answers, you want to know how sustainable a connector-based relationship might be. Will the company just integrate the feature? Will you really help them, or will they help you gain access to distribution or customers?

To execute on this requires listening and carefully developing a dialog over building such a model rather than just showing up. There are many challenges in possible in implementation even with what you perceive as a very strong value proposition.

Who to target? Most any of these models have a steep curve of importance. There’s salesforce and then all other CRM. There’s Office apps then other productivity tools. And so on.

Really important to be sure to start with the important one. Don’t start with the easy one.

It is very easy to get lulled into a sense of progress if you knock off the easy ones. Those partners are likely going to make it easy for you especially if they see an opportunity for an “Anyone But <X>” consortium of vendors aligning to create a de facto standard w/o leader.

There might be many potential connectors to be built and likely just one or two that are the bulk of the usage.

It is important to develop an architecture that spans all of these. Too often there’s a view that getting the first connector done will speed things up for the others, but this only works if the products have similar APIs, data formats, and performance characteristics, etc. You can easily find yourself with one connector that works and a long road to get 2 through 10.

Quite often all the “other” players will like to align and even create a consortium around connectors which hopes to have 2 through n gain a market footprint bigger than the leader. This strategy “anyone but” almost never works because customers are much more pragmatic and often not willing to be pawns in an industry game, even if such consortiums make for great press. Check out the ODMA for one that historically was all about connecting to document management solutions for an example of this.

How to target? When targeting 3rd parties there’s a good chance motives will be suspect, especially if you are visible, category leader, or just big. Parties will want to know “why are you doing this”? Your pitch will always sound like good for industry, but is it?

The third party will think “you know what is good for the industry?…if we win the category and dominate, and have the UI, data formats, and own customer connections…that’s what is really good for the industry” ;-)

You want a winning approach for 3rd parties themselves, not just a perception win or win for you. If you have big logos that need something, then they are almost always the best voice for this type of architecture. Big logos needing multiple companies to work together is key.

Given all we’ve talked about, it is likely that any provider architecture will be seen as commoditizing or disintermediating, and thus will face resistance.

Conversely much like cross-platform or hybrid cloud, customers will almost certainly be champions of a provider architecture—they will feel freedom from lock-in as well solve interoperability problems.

The key to winning over the apps/solutions you want to work with likely rests with getting large customers to voice, or perhaps require, connectivity to your product. That is a tall order, but it is often the kind of breakthrough that both works and demonstrates viability of the approach.

When you begin to design your API, important to step out of your implementation and problem space and recognize that your “narrow” view of the world (as seen through your product) is a subset of what third parties see as the market. Avoiding least common denominator is key.

Frequently your first view of the architecture of a provider solves your problem. The trick is to make sure it solves the problems introduced by such an architecture.

User interface is an example: eg, Nest Connect which didn’t work super well. They built a limited way to control third parties (or be controlled) and almost never could you elegantly access the power/flexibility of Nest or third party devices through this model.

Most all data connections struggle with performance or when trying to go through an API versus the native implementation. Having your product rely in a connection that feels “second class” works for no one.

The API needs to be performant and functionally rich as a baseline. Imagine what it would be like to be designing API inside a potential third party and it’s your product. What would you want? That is very different than what you might be after in your product from the outside.

Beyond baseline capability you will also want to design some “escape mechanism” where providers can surface their unique capabilities for both unknowns and known unknowns (known stuff not in your API). Give an opportunity for UI to shine. Early on you’ll evangelize this heavily.

One need be prepared for connectors to be gamed. That’s why SaaS data sources rarely have full SQL access — they know devs will just replace the whole UX for a product. Connectors will be used to upsell customers, insert branding, or do many things you totally don’t expect!

Printer drivers in Windows are a classic example of a provider architecture that have all of these elements above.

Customers of course want their choice of printer to just “work” with a computer.

Printer makers have no desire to be viewed as interchangeable commodities. The manufacturers go through great lengths to support new features like duplex, n-up, zoom, scale, draft/final, cover pages, water marks, native fonts, scanning, faxing, label printing, even page description languages (PCL v Postscript) and so on. In each new model of a printer they add features that need to “shine through” the software.

The printer driver that seemed so simple is all of a sudden the union of all printer makers capabilities. Very quickly it becomes impossible to code. You have to have an architecture that may support all features, no given printer supports them all. Plus printer makers have their own ideas for user-experience to enable those features.

Then the marketplace for printers has a leading player (HP) committing massive resources to make an “HP Printing Experience” across Windows, Mac, devices, and even device-free printing. They are the leaders and so will have no problem distributing their own apps, drivers, control panels, etc.

Building on this, printer makers want to have their own connection to customers to sell consumables. That’s more space in the interface for printing that needs to go “somewhere”.

Seeing all this, the smaller share players don’t see a need to just do the minimal work to support a “generic print driver” model. So then very quickly the whole approach becomes really difficult.

BUT WAIT, the value of standard printer drivers for quality, performance, reliability, and convenience is super high, especially for corporate customers that might have many different offices around the world using many different printers.

As you can see this simple example—printer drivers—shows off the amazing set of issues one can have in building a provider architecture for even the most straight forwardly expressed customer problem.

Finally you will need to do the work yourself and not assume there is a line of people at other companies waiting to support your provider (often this gets confusing because of the line of startups to support some big Microsoft or Salesforce API).

A huge part of connectors/providers is building a team/organization that views this as a mission, not a one-off. Maintaining them, keeping them secure/performant, and keeping up with changes from the big players is key to your value prop. This isn’t an outsourced afterthought.

Far too often in pitches the idea of doing the work for the long tail is left as an exercise to the reader to complete. In practice, the long tail of connected products becomes critically important. This is especially true if for a given product it requires multiple connection points (for example a SaaS dashboard versus a printer driver). For any given customer, all it will take is one missing connector to make your entire solution a “non-starter”.

The implication is that once you go down the path of creating a product that relies on connectors, it will very quickly become a sales necessity and ultimately a competitive advantage to be in the connector business.

Ultimately, building a product that has a strategic dependency on connecting to third party tools/data is a big deal — much bigger than “build some connectors” and has a lot of potential risk and challenges to consider. The payoff of course is huge but so is the investment.

PS/ If you’re thinking of building your business on the connector API to something else then consider all these things in reverse. Imagine what the motivation is for offering connector? Will you get the performance, distribution, features you need, etc.?