Build an Integration Capability, Not Just Integrations

Integration is usually a thorn in the side for a product leader. You're asked to integrate to anything and everything, but not at the expense of your core product vision and the other features you've already commited to.

How do you navigate this impossible task? How do you spend time and dollars on building integrations, when they are necessary for your success but not really why your users want your product. It's not really why your investors gave you money. It's not really what insprired your team to go on the journey.

Most product leaders fall into a familar pattern, reacting to and often deprioritizing integrations as they would any other feature. But, this is a misguided approach!

In this post, we talk about why you should, instead, look at integration as a strategic and fundamenntal capability and not just a list of features you need to build. The result will be a clearer path toward achieving true "platform" status.

What is an integration capability?

Thinking about integration as a capability is a mind shift from where most product teams naturally begin. To understand that shift, it's worth looking at how most SaaS product teams handle integration, especially in the early and growth stages of the business...simply as any other feature.

Integration as a Feature

Most of the time, the product leader's natural inclination is the treat an integration to another system like any other feature request.

The request might come from the sales team: "I can close this deal this month, but I need to commit to an integration to X!".

It might come from your customer success or support team: "This customer said they're going to leave if we can't integrate to Y."

It might come the market: "Our CEO just returned from an industry event. He said we must build an integration to Z."

These integrations-as-features get cataloged, quantified for business value and size, and prioritized like all other features. When they bubble the top of the list, the engineering team estimates, builds, and tests them just like they would a new widget on the UI.

It's understandable why this is the starting point. After all a feature request is nothing more than ask to make the product do something. Just because that something is talk to another product, why would you treat it differently?

You should treat it differently, because integrations are fundamentally different than typical features.

Integrations tend to be more complex than typical features. They are adjacent to (not part of) your core value proposition. They are heavily influenced by the capabilities of a product built by another team at another company. No other feature your team will build shares these attributes.

As such, there are a number of problems with looking at integrations as features:

• It's reactive. You never develop a strategic intention about where you want to fit into your ecosystem, because you simply respond to requests from customers or stakeholders. That often means underinvesting in the effort to decide whether you should even build the integration to begin with.
• It ignores the reality that integrations are fundamentally more complex than typical product features.
• It leaves little room for aligning the integration and its delivery with the efforts of the business development/partnership team, who is building the human counterpart to the data integration.

Treating integrations as a feature works fine at first. But typically somewhere around the 12th one you build (+/- 50%) this approach starts to create technical debt, manual processes that must be executed, and an increase in unit cost of ownership.

Instead, you should look at integration as a capability that you build, not a set of features that you deliver.

Integration as a Capability

At the end of the day, yes, you need to deliver integrations--individual parts of your product that interact with other ecosystem products to create a cross-product experience for your mutual customers.

For most B2B SaaS companies who get to any level of success, they'll do this dozens of times, if not hundreds. It is not reasonable to think you can build a sizeable SaaS platform (and truly mean the word "platform") without accepting the responsibility of providng this level of connectivity.

To set yourself up for success, think of integration as a capability, not just a feature.

Integration as a capability is about the developing your approach to building out connectivity; not just building out that connectivity. It's about having a process and a philosophy around prioritizing, designing, and delivering integrations. It's about how before what.

This is a mindset shift, and it requires product leaders to not be solely driven by short term needs. Yes, those short term needs are important and many must be addressed. But, the product leader has to also make room for the long term vision. Deciding how the team will approach connectivity means thinking about integration as a capability.

Questions that should be considered:

• What does the team who designs and builds integrations look like? What are the roles and the skills they possess? How do they work together?
• What's our methodology for deciding which customer requests to react to and which to politely decline?
• What's our methodology for deciding for ourselves which integrations are important for meeting our strategic goals?
• What's our strategy for standardizing how these are built, so we minimize cost of ownership?
• How are we going to make ongoing updates to enhance the functionality of the integrations? What about keeping them compatible with future API versions?
• How locked down and consistent will our integrations be? Will we allow for highly customized or completely bespoke ones? How will that work?
• What's our philosophy for monetizing integrations?

All of these are critical questions to answer. None of them are answered by reactively building integration features. You must develop your approach--your integration capability--and allow it to evolve as your company does.

But, just saying it doesn't make it so. What does it look like to get there?

How To Get There

Building an integration capability (so you can build integrations as features most effectively) doesn't just happen overnight. It's arguably a journey that doesn't end until the company does.

That doesn't mean there isn't a defineable path to success, though.

You can map out your journey from reactivity to mature capability using a simple crawl-walk-run approach. This helps you think about what's important at which stage of your evolution, so that you invest time and effort in the right things.

The following describes what that crawl-walk-run approach looks like.

Crawl: Establish the Basics

In the crawl phase, your goal is to set a foundation of good practices for defining, designing, and deploying integrations. These fundamentals are important, helping you to avoid significant friction points that show up in the not-too-distant future. You shouldn't boil the ocean, trying to behave as if you are an ecosystem hub platform, before you're ready.

A best practice foundation includes two things: 1) a set of building blocks that help you construct integrations consistently (i.e. an iPaaS-like ability) and 2) a process that takes ambiguous requirements about two systems connecting and articulates what the integration should do and a fine-grain level of detail.

Integration Building Blocks

Integration is a volume game, even more so for a product team supporting a bunch of customers. To build dozens (or more) integrations that support hundreds (or more) customers who move thousands (probably more like millions) of pieces of data requires you to "build in" scale from the beginning.

Consistency enables scale, because it allows you to expand your team. It removes the burden of having "that one guy" who knows how all the integrations are wired up. If integrations are built with similar blocks, using similar patterns, you can train somebody to understand those and they can understand all of your integrations.

Architecture desicions (should) enable scale. Think about the levels of data processing you'll do at peak levels of success. Choosing a framework and building blocks expand to meet those growing needs means you don't have to rip and replace your integration infrastructure at every new level.

Established functionality enables scale. If you use existing tools that transform data, talk to APIs, handle API keys and Oauth handshakes, and all of the other things that need to happen in various integration scenarios, it means you don't have to wait for your engineering team to build those basics.

Incidentally, most of those things are commodity features that have been built a million times. Why invest in doing it again?

We typically bring in an open source integration framework to establish this foundation of building blocks. It minimizes the investment a SaaS company must make in the basic functionality for integration, so they can invest in building those integrations.

Best Practice Process

There's an underappreciated art to taking someone from "I want X product to talk to Y product" to a set of use cases that defines the cross-product experience they actually want to a detailed specification that tells the engineer what it needs to do.

Here's what you don't want:

• To be getting the use cases right while building the integration--that's building a car while you drive it
• Engineers deciding how the thing should work in order to deliver the desired experience
• To be naive to the realities that building the integration means living within the means of two imperfect APIs (or maybe even a lack of APIs)
• A templated, reusable product integration that was built so specifically for customer #1 that it actually isn't reusable

You can avoid those pitfalls (and the list could go on) when you establish a process that is purpose-built for defining and designing a product integration.

You can usually get away with defining product features in broad terms like user stores or themes. Most product managers do. You can get away with it because generally when you are building a product, you are only limited by your imagination and your budget.

This is not the case when building an integration, because the reality of the APIs and the specific data you are integrating dictates strict rules to you. You can't experiment your way through an integration, so you must establish a design-then-build process.

Walk: Make Connectivity Native

When you've begun to master using a standard set of building blocks to create integrations using a best practice process, you should start to look at how you embed those integrations more fully into your product. In other words, how do you make them more native to your user's experience?

There are many ways to build a native connectivity experience, but here are some common places to start:

• Providing screens within your product for users to configure and enable/disable the integration. This configuration could be a form with a few blanks to fill in and it could be a data map or workflow editor to allow for significant customization to a given integration.
• Built-in authentication handling, especially when doing Oauth handshakes.
• Providing data visibility to give the user a contextualized understanding of what data is moving through the intnegration and what has succeeded and failed.
• Building in integration marketplaces or other ways that help your user discover and enable even more connectivity, making you a stickier, more central product in your customer's technology stack.

These are the basics. These are tablestakes. Remember, an integration's goal is to create a cross-product experience that further enables your user to accomplish their goals.

The way you embed one product's capabilities into another has a lot of room for creative thinking. Under the hood, the fundamentals are the same (data in or out), but the way that's expressed and exposed to your user can be a differentiator.

But, I need the native features now!

Of course you want your native product integrations to be expressed natively in your software product. No user wants to call customer support every time they need to set up or modify an integration.

The practical reality is that increasingly so, users expect this self-service ability to integrate your product with others. It's a tough sell to ask them to wait while you build out a "crawl phase" integration capability. Your user doesn't care.

Like many things in life, the lines between crawl, walk, and run are blurry. While they provide a general framework to consider, the goal is not to encourage you to ignore reality. That means it is often necessary to build out some amount of the native functionality early. You might be required to kind of build the car while you drive it.

But consider the following:

• This is yet another reason to build on an existing set of building blocks--a framework that introduces more stability than custom-built integrations would.
• Just because you have to work ahead, doesn't mean you can skip the "crawl phase" altogether. Poorly built integrations that are beautifully embedded within your product are lipstick on a pig.
• Start as small as you can building native integration capabilities untiil you've mastered the "crawl phase" responsibilities. Don't work farther ahead than you have to.

Run: Externalize Connectivity

Achieving the ideals of a true "platform" means that you accomodate for the full spectrum of connectivity possibilities that make you the best possible citizen of your market. This positions you to be a hub of workflows and data for your users. For example, it makes you a Salesforce or a Hubspot floating atop a endless sea of niche CRMs.

Yes, you need to have a high volume, best practice API for supporting the long tail of integration use cases. Yes, you need to provide your own native integrations and surface them through native experiences that support your users finding, configuring, and owning those integrations. Yes, you need to partner with third party iPaaS providers and SIs.

But, when you are truly "running" with your integration capability, you are able to expose all of the foundational pieces you built for your own team to build integrations to an ecosystem who want to build to you.

This means exposing your building blocks and standards, allowing external partners to add to your integration capability. Usually this kind of experience is centered around app store and a partner portal that provides self service ability for those partners to submit integrations. It's usually coupled with an at-scale ISV partnership program.

Democratizing how your product integrates with others means transitioning from being part of an ecosystem to becoming a center of gravity around which an ecosystem develops. At this point you aren't just a product--you are a lifestyle. People say things like, "I'm a <your product> developer," instead of, "I'm a developer and sometimes I customize <your product>." You enable others to build businesses and revenue streams around your business.

This is a big vision, and it looks different for everyone who gets there. Most software products never reach this level of connectivity. Typically, the company is acquired or goes out of business before it gets here. But, as a product leader, you should always have this vision in mind.

Think about what your product looks like in a fully realized platform vision. This is how you look at connectivity as an integration capability, and not just a reactive set of integration features.

You'll build a lot of integration features along the way, but the ultimate goal is so much bigger.

***

If this is a journey you're looking to go down, we can help. We offer a full suite of products and services that enable software providers at all level of maturity to progress toward becoming platforms of their ecosystems. Let's start with a conversation about how we can get you there.