Deciding Which SaaS Integrations to Deliver and How to Deliver Them

Product and engineering leaders at SaaS companies are constantly challeged to decide which integrations are right to build, which are best to outsource, and which aren't worth the team's time or resources.

If you've been part of or accountable for making such decisions, you know how difficult it can be. Rarely is a decision to provide an integration an obvious "yes". Even if it is, the answer to "how?" (the inevitable follow up question) is just as vexxing.

This post will lay out a mental model for thinking through these two questions: should we? and how?

It'll help guide your team's and your decision making when it comes tackling these challenge questions, so that you can make most effective use of the dollars, time, and resources that you invest into your integration program.

Why categorize potential integrations?

It's worth asking up front, why even bother with all of this? Can't you just react to customer asks as they come in? Can't you just blitz as many integrations as possible, because more is always better?

Consider two points: 1) your team has a finite amount of resources--primarilly time and money--to spend on any given product initiative, integration or otherwise and 2) integration is hard, especially when your team probably isn't setting out or optimized to solve integration challenges as the primary value proposition.

The first point means that you simply cannot say yes to everything. There isn't enough time in the day. There aren't enough engineers to work on everything. There isn't enough money to spend on it all.

Furthermore, investing time and dollars into the wrong integration also costs the missed opportunity of picking the right one.

You are forced to decide how many integrations of the x possible integrations you could deliver are you going to actually deliver? Which ones are they?

The second point means that making suboptimal choices about which integrations to invest time and money into can have a particularly bad ROI.

When building integrations, making a wrong decision isn't usually a matter of netting a 10x ROI when you could have picked a different ont that would net 15x (in other words, still not that bad). It's more likely a matter of investing into an unprofitable money pit instead of a profitable one.

These are high stakes decisions.

Deciding to invest in certain integrations will dictate how your product can plug into the ecosystem it occupies. It will open (or close) swaths of your total addressable market. It will ratchet up revenue opportunity or become an expensive obligation.

Making matters more difficult, you have to make these decisions with imperfect information. You also have to make them with the understanding that no peer, compeitor, partner, or stranger can be copied to gaurantee success. There is no playbook withthe answers. You are on your own.

In terms of the Cynefin framework, building and executing an integration roadmap is a complicated problem. That means that while there isn't an obvious answer, you can use some relatively standard information patterns to make more potential good decisions (and fewer bad) about which integrations to deliver and how.

Approaches to Providing an Integration

This post is going help you think through which integrations to deliver and suggest how to deliver them. To do that, you need to how you could deliver an integration.

The following are the typical high-level approaches available for providing a given integration:

• Custom-build the integration natively into your product
• Leverage an embedded iPaaS or integration framework to build it
• Partner with an iPaaS who can provide integrations from your product to others
• Enlist a solution integration or channel partner to build it
• Allow your customer to build it

For a more detailed dive into these options check out this post.

Native Built

A native built integration is baked into your core product. It's homegrown. There is no separation of concerns between the integration and the value the core product offers.

Building a native integration is one of two places most product teams start (the other is fully outsourcing), usually the chosen path of product teams who haven't gone through this before. It's not necessarilly a wrong choice, but it's not one that requires a team who has seen/done this before.

Building integrations requires a few things:

• An application architecture that supports integrations (leverages an asynchronous messaging framework, provides API for data access, can scale to meet data demand spikes, etc.)
• Or, the architecture can be expanded to support such things (warning: this is potentially a huge undertaking)
• A team that understands how to architect an integration framework and successfully build integrations leveraging such a framework
• Time and patience to get it wrong a bunch of times

In other words, it's achievable, but not easy. There are sometimes reasons that this juice is worth the squeeze, but overall teams tend to pick this approach more often than they should.

Embedded iPaaS or Integration Framework

Instead of building integrations from scratch, many teams will leverage a commercial embedded iPaaS (integration platform-as-a-service) or existing integration framework.

Typically the former involves a software license with a third party vendor. The latter may as well, but there are other ways to accomplish this including use of open source software.

However, these approaches are simiilar in the sense that while they allow you to deliver integrations on an existing set of building blocks. The architecture, the design approach, and the workflow come out of the box. The integrations appear native to your customer, but under the hood, your team didn't have to spend time building the engine.

This is a happy medium between partnering out to a commercial iPaaS and building natively. You maintain more control of the customer relationship, but you don't have to invest in solving the problem of writing high scale integration software--a problem that's been solved many times over.

iPaaS Partner

If it doesn't make sense (or you don't have the resources to) build an integration yourself, partnering with an existing commercial iPaaS is a potential alternative.

Typically there is some investment to build an iPaaS connector that is required to kick off such a relationship. Your team may sign up for that, using whatever tooling the iPaaS provides. Sometimes the iPaaS will take on some/all of that responsibility.

But, generally speaking, once you have a connector in that iPaaS provider's library, a customer is able to use the iPaaS to build an integration to any other connector.

The biggest drawback is that you relinquish a chunk of the customer relationship to that iPaaS company. There may be a formal partnership agreement between you and the iPaaS, but usually your customer also has a separate customer agreement with the iPaaS.

This means you cede potential revenue opportunity, you add to the cost of ownership for your product (to your customer), and you trust someone else to manage something that is pretty important to your mutual customer.

On the other hand, it allows you to rapidly expand your ecosystem connectivity footprint and offload some of the responsibility for providing integration to a company that is well-suited to handle that responsibility.

Solution Integrator or Channel Partner Built

Another strategy for offloading the integration is to partner with a solution integrator (SI) or channel partner.

Now, as a fundamental prerequisite, in order to consider this approach you must have an existing SI or channel partner network. If you do not, it's a project in and of itself to build one.

An SI or channel partner, like an iPaaS, will have their own commercial relationship with the customer to provide the integration (and possibly other solutions). However, unlike an iPaaS, the approach for providing the integration may be less predictable.

Some partners may actually use an iPaaS of their choosing to provide the integration. Some may build on an integration framework or even build completely from scratch.

This approach tends to have a lot of variability, which isn't necessarilly a bad thing but isn't typically the goal.

Customer Built

Finally, you always have the option to let your customer build the integration. This is allows you to be hands off the wheel, but it avoids bringing in a third party who establishes their own relationship with your customer.

The biggest, most obvious drawback is that your customer must have the willingness and resources to do this themselves. They may already have an adequate iPaaS, enterprise service bus (ESB), or other technology that is suited to the task. They may feel comfortable building from scratch as well.

Unlike all the other options, a customer-built integration can only ever be leveraged for one customer. And, the level of support you have to provide that customer is very dependent on how well thei built the integration.

This approach also means that you must provide a fairly robust set of APIs or interfaces to get data into and out of your product. Otherwise, to what do they integrate?

Customer-built integrations are more common up-market and with enterprise customers. But, if you have a smaller customer with an IT guy who hacked something together, it wouldn't be the first time.

Categorizing Potential Integrations

The first step is to categorize your list of potential integrations. This might be a dozen, many dozens, or even of hundreds of potential integrations that you might consider delivering. 

(Remember: deliver doesn't necessarilly mean "build yourself".)

Bucketing integrations into one of four categories that describe how having the integration will impact your product's presence in its ecosystem will put some general priorities in place. As we'll discuss later, it'll also help you decide on how to deliver the integrations.

The four categories are:

• Ecosystem imperative integrations
• Ecosystem important integrations
• Ecosystem adjacent integrations
• Ecosystem irrelevant integrations

We always advocate that you take a portfolio approach to your integration strategy, and these categories help to describe what that portfolio could look like.

Ecosystem Imperative

Ecosystem imperative integrations are non-negotiable must haves. They are the integrations that are required for potential customers to really take you seriously.

Likewise providing these integrations will unlock relatively large swaths of market opportunit; customers who consider the integration a must-have. This is the fat part of the curve, not the long tail, in terms of addressable market.

It's critical that you correctly identify your ecosystem imperative integrations. These should be understood from the CEO-down, discussed at board meetings, and described in the company's pitch deck. Typically, the founders for a software company know what at least some of these are on day one.

Your list of ecosystem imperative integrations can evolve as your product and market approach do. The list can grow as well.

But, be discerning about what integrations you bucket as "imperative". This is the highest level of importance and it'll be used to justify the most investment. Politicking an integration into this category without the proper dilligence is not a tactic that will create success over the long term.

For most early and growth stage companies, if your list of imperative integrations is longer than a dozen, you should check your decision making parameters. If it's more than two dozen and your product isn't really big and broad, you're probably missing the point.

If you're worried that you've only identified a few imperative integrations, you're probably doing this right.

(These aren't perfect numbers--just rules of thumb.)

How to Deliver Ecosystem Imperative Integrations

Most of the guidance in this post is general and dependent on your specific circumstances. This is a rare exception.

You should have full ownership of delivering any and all ecosystem imperative integrations. If you think you shouldn't, you should have a really good reason why that is.

There are only two appraches that afford you the full ownership: building natively or with an integration framework with a license that grants you control. Building using an embedded iPaaS is almost full ownership and sometimes is the right move, but still fundamentally controlled by a third party.

Mind your licensing agreement. Be careful about building your house on rented land.

If an integration is truly imperative, it must be deeply embedded with your product experience. It must be of your most sophisticated integrations. And, it arguably must be a contributor to the company's enterprise value..

If this sounds difficult and expensive, trust your instincts. This is why it's critical that your list of ecosystem imperative integrations is relatively short and each integration on the list meets the proper criteria.

Ecosystem Important

Ecosystem important integrations don't quite cross the threshold of mission-critical for company and product success. They are important, but not having these integrations doesn't prevent the product from providing value.

Like imperative integrations, adding important integrations may open chunks of market share. If an "important" integration is a fundamental blocker for a set of customers, it should only be a very small percentage.

More than likely these are the integrations that your customers are kicking down your door for, but that aren't standing in the way of those customers using your product.

You do want to try to provide most or all of the important integrations on your list, but with important integrations your approach can be more flexible.

How to Deliver Ecosystem Important Integrations

Important integrations afford the most flexibility among valid approaches for delivering the integration.

Building these integrations natively or on your chosen framework/iPaaS is a sound choice, provided it doesn't prevent delivery of an imperative integration. Offloading these to third party iPaaS or SI/channel partners is also appropriate.

This optionality means you'll probably use multiple approaches. This begs the question: how do you decide which approaches to take for subsets of this bucket of integrations.

Consider using a nine-box priority matrix to decide. Focus on building the highest value, lowest cost ones yourself and offloading the rest to third parties.

Of course where that line stands is relative. As your integration program matures and you have more capacity and ability to build more integrations in-house, do it. Expanding your owned connectivity footprint adds value to your company. It's ultimately the destination for any software company that will be hugely successful.

Ecosystem Adjacent

Ecosystem adjacent integrations are not important for executing your ecosystem strategy or establishing your connectivity footprint. They are useful to some of your customers, but not necessarilly all that beneficial to your company from a business perspective.

Commonly, these are integrations that get too much investment. It's easy to convince yourself and your team that what should be an adjacent integration is actually an important one. It's easy to react to a squeaky wheel customer to invest in such an integration.

More often than not, investing heavilly in adjacent integrations will have a negative ROI. There just aren't enough potential customers who can generate enough value to justify the investment.

But, none of this is important to the customers who want these integrations. That's why some customers will be empassioned about these integration requrests. It's helpful to have a better answer than, "No, but maybe someday," for those customers.

How to Deliver Ecosystem Adjacent Integrations

Ecosystem adjacent integrations are best left to the third parties or your customers themselves.

Third party iPaaS or SI/channel partners probably have a good understanding of your customer's business. They probably have an economic model that justifies providing this integration, even though you don't. They are also built to sustain something that only one or a few customers will use.

Offloading adjacent integrations to partners or to your customer does add cost for your customer. While this can be a customer experience risk, you actually find out pretty quickly just how important the integration is when the customer has skin in the game.

It's unlikely that you ever end up providing ecosystem adjacent integrations yourself, but it does happen. If your integration footprint grows to hundreds of integrations, you might justify continuing to buid them.

More likely, at that point you've matured to a point where the ecosystem is building their own integrations on your platform. This is the gold standard, and it means the adjacent technologies will use your tools to build to you.

Ecosystem Irrelevant

Ecosystem irrelevant integrations are mostly unimportant. This category represents strange, one-off requests from customers or conceivable integrations that have no obvious business value.

Irrelevant integrations represent huge areas of risk for your business. They tend to be technical debt money pits.

These integrations should not really be anywhere on your product roadmap. If you find that you have irrelevant integrations already in your product, you should make plans to sunset them.

Why even identify these? A big part of knowing what your team should deliver is knowing what your team should not. This helps to build clarity around your integration stategy. Don't over-invest here, because the list of irrelevant integrations is theoretically endless. But, spend a little time deciding what you won't provide.

How to Deliver Ecosystem Irrelevant Integrations

The short answer is: you shouldn't provide ecosystem irrelevant integrations. Don't invest in these. Don't waste your time and resources.

However, an insistent customer should be able to leverage an SI/channel partner or build such an integration themselves. You should acknowledge with them that you API may not even support such a bespoke integration, nor will product roadmap items be added to support it.

Assuming your API can support the request, the risk is manageable if someone else builds it.

Other Parameters to Consider

There are some other parameters you should consider when trying to decide what approach to take to deliver a given integration. These kind of cut across all four categories of integrations.

How configurable is the endpoint?

How much variability wil the integrated endpoint system have from customer to customer? Is the product more of a highly customized framework or a very consistent SaaS product? What are your customers' expectations?

The more configurable the external system is, the more complex it is to build an integration to it. You have to consider far more "what if" scenarios. This increases the cost of building the integration yourself, sometimes significantly.

Consider if integrations to highly customizable endpoint systems should be outsourced to partners.

What do your primary competitors provide (and not)?

What integrations are your competitors providing already? How are they providing them?

Your competitors may be making good decisions, using a similar decision framework. But, there may be market opportunity specifically because you took a different approach.

For example: do all of your compeitors partner with iPaaS vendors to deliver a given integration? If you are able to provide it more natively, you can differentiate by providing a more tightly built integration that doesn't increase cost to your customer.

Bespoke integration or product integration?

Is the integration in question bespoke or productized? Do your customers requirements even allow for a productized, repeatable integration or is every customer so different that they require a custom project?

If the latter, building integrations yourself is really really hard. Consider outsourcing such integrations.

Delivering these yourself is achievable, but most software vendors who execute this startegy do so with a team that they acquired through M&A at some point.

A Matrix of Factors

Deciding which integrations to delliver and how reqires you to evaluate a matrix of factors. There can also be multiple right and multiple wrong answers.

Using a sound and consistent framework for making these decisions won't gaurantee that you always make a good decision. It will, however vastly increase the odds that you do.

‍