Making Integrations Key Product Features

Before coming to Prismatic, I was a product manager for several B2B software companies. Early in my career, I worked for a company that built hundreds of integrations. We were in a market where we simply couldn't compete or be successful without a high volume of integrations.

And we were successful. But building and maintaining those integrations became difficult as we got bigger. It wasn't uncommon for us to spend more than 50% of our development capacity for a given quarter on integrations.

I've seen first-hand the value that integrations can provide to SaaS companies. But I'm just as familiar with the challenges associated with building those integrations.

I joined Prismatic in part because our goal is to make it easier for B2B SaaS companies to connect their products to the other apps their customers are using.

How vital are integrations for your product?

For a long time, software integrations weren't a priority. Sure, everyone knew they needed them, but they were often relegated to an engineering backlog or "we should have something in a few months."

But integrations are too important to your customers, and to your product, to treat them as second-class citizens. Customers need those integrations to create data consistency across their tech ecosystems, eliminate redundant data entry, and decrease the time their employees spend working with different applications.

A recent report from G2 reaffirms the value customers find in software integrations. As we can see from the below, integrations are now a top consideration for companies buying SaaS systems.

It used to be enough to provide a robust, well-documented API for your customers and turn them loose to create whatever integrations they needed. A solid API is still essential, but your customers now expect you to provide the API and the integrations that will use it.

As a B2B software company, you must decide how you'll meet the integration needs of your customers. And stepping up to that challenge now instead of later can determine the long-term success of your product.

The key to this challenge is to stop thinking of integrations as services or something you can bolt onto the product somewhere down the line. Instead, integrations must become key features of your product.

How do you make integrations into key product features?

Based on my experience as a VP of Product and having worked with hundreds of B2B SaaS companies, here's how you can change your integration approach and meet the challenge of your customers' expectations:

• Get good at planning integrations. It's easy to be reactive when it comes to integrations. But doing so isn't healthy for you or your customers.
• Build integrations that scale with your customers. You've probably built a one-off integration that suits a particular customer perfectly – and then had to completely rewrite it for the next customer. This approach simply doesn't scale.
• Give your integrations the visibility they deserve. Integrations are often in black boxes. And that makes it hard for your prospects and customers to know which integrations you offer.

Get good at planning integrations

You've either been thinking about the integrations you need for your product, or you've already built a few. In either case, you probably know some of what you must do, but do you have a comprehensive plan?

Integration planning helps you avoid recency bias (a huge issue with integrations) and incorporate integrations in the same processes you use to build, deploy, and manage the rest of your product.

Let's look at what should be covered in your integration planning.

Evaluate integrations alongside other product features

What is true about any new product feature? Saying "yes" to it means you must say "no" to something else. The same is true for each integration.

Without unlimited time and dev resources, you must determine those features that provide the greatest value for your product and customers. As a result, integrations need a seat at the table when building out your product roadmap and determining what you need to grow your product and customers.

Integrations need to be elevated from the position they've traditionally been in: "We'll get to the integrations after we've taken care of the important things." And don't fall into the trap of saying that you'll spend X% of your dev time on integrations. You know what happens to that block of time when you need to get "real work" done on the product.

The most essential integrations you can build will be outcome-driven. That is, they will solve well-defined product and customer needs. Ensuring you are solving critical needs is better than just taking every customer request for integrations and setting up a FIFO burn-down list.

No one likes to build bespoke product functionality for customers. Unfortunately, integration development is often the culprit of such custom development. However, including integrations in the overall evaluation process and prioritizing them accordingly helps to forestall such inefficiencies.

Be realistic about everything integrations entail

Integrations are superficially simple. Connect app A to app B and transfer data X. But there is so much more because integrations follow the iceberg principle: 90% of the integration is below the surface.

At the very least, integrations must be built, deployed, and managed. Here's a brief list of what that includes:

Building integrations

• Webhook management
• Event scheduling
• Auth
• Testing framework
• Dev and prod environments
• On-prem connections
• Transport protocols

Deploying integrations

• Integration marketplace
• Versioning
• User configuration
• Customer-facing dashboards

Managing integrations

• Provisioning resources
• Scaling resources
• Handling security
• Logging and alerting

It's easy for companies that are just getting into integrations to overlook the amount of work that goes into an integration behind the scenes.

And, if you are doing a single integration for a single customer, then figuring this out might be simple. However, the real solution means you do everything in a way that scales when you have 20 integrations to deploy and manage across 500 customers.

For example, you need a way for your customers to authenticate. Most apps these days support OAuth 2.0. This provides a simple user experience for customers, but quite a bit goes into implementing integrations that use it. You'll need infrastructure to generate and receive the auth URLs. Once authenticated, most apps will expire tokens, so you'll also need a service that periodically refreshes the token.

Check out our blog post for more details on what makes up an integration.

Don't neglect integration requirements

Integration requirements are often overlooked or ignored. "It's pretty simple," your dev says, "I don't think we really need to do all that documentation." Perhaps the integration is simple, or at least it appears that way. But, no matter the complexity of the integration scenario, a straightforward, repeatable process for gathering requirements is essential to successful planning.

Here are the main things that will vary from one integration to another.

• What will trigger the integration?
• How often does it need to run?
• How will the data be transferred, one-way or two-way (or more)?
• What auth method will each connected app use?
• What API will each connected app use?
• What data is to be transferred?
• What transport languages will be used?
• What transfer protocols will be used?
• Does data need to be modified within the integration?
• What varies between customers and should be configurable?

As with any other product feature, you want to provide your devs with all the details they need to build the required functionality. This helps you avoid the all-too-common scenario where you code an integration but then have to rebuild it immediately upon deployment – because there is a substantial disconnect between what the customer needs and what the integration provides.

Integrations also benefit from multiple perspectives when you are gathering requirements. Talk with all the stakeholders (technical and non-technical alike). Where possible, talk with stakeholders from various customers to ensure you capture the full breadth of business requirements.

In addition, you should chase down any needed integration complexity during the requirements phase before you and your team have committed to a course of action. Coming up with critical integration use cases the week before deploying the integration to 50 customers is usually enough to derail the project altogether.

Depending on the integration, you may have access to the other software vendors (tech partners) you are connecting with. If you do, take advantage of that access. Maybe they've had others build integrations with them and can help you avoid common issues. Or perhaps they can provide you with detailed API docs, so your devs don't spin their wheels trying to figure out what query will work in a given situation. Whatever the case, don't be shy about asking for assistance. After all, the integrations you are building also provide value to your tech partners.

Check out our blog post for more details on capturing integration requirements. You can also download our integration specification template.

Build integrations that scale with your customers

The traditional approach to building integrations doesn't scale. By providing every customer with something custom to them, you create many slightly different versions of the same code (which you now need to keep track of), and support is a total nightmare. Not to mention that your dev team is never big enough to stay ahead of new integration requests.

That's why you must move from the traditional services model to the productized model for integrations.

Every time you build an integration, there will be things you miss, no matter how many customers you talk with. That's the nature of software. But you don't want to build 20 different integrations for 20 customers, as we've just discussed.

So, how do you handle the different customer needs? You define your customers' shared needs and ensure you've covered them in the integration. Then, you look at the things that are unique to customers and figure out which ones should also be handled within the integration but as configuration options.

For example, it's common for different customers to have non-congruent data needs. By including data mapping in the configuration, you can allow all of your customers to transfer the data they need without building a separate integration for each one to make that happen.

Beyond thinking about what should be configurable, you'll also want to build your integration code in reusable chunks – just as you would with any other product feature. Once you've built a service to handle OAuth token refresh, for example, you have it on hand for any integration that needs it.

Give your integrations the visibility they deserve

You are no doubt familiar with integration marketplaces. You've probably used one yourself. And that's precisely what you need for your integrations.

Other features of your app are discoverable. Your integrations should be as well. Customers should not only be able to see what integrations you provide but should also be able to activate them and configure them (in most cases) without contacting support.

Traditionally, we have this idea that only the bigger players/large companies should have integration marketplaces – partly because of the work those marketplaces require to set up and manage. But every B2B SaaS company with integrations should be showcasing and making them available via an integration marketplace.

Modern tools, such as the embedded iPaaS, make it feasible for any B2B SaaS company to create a beautiful, white-labeled integration marketplace. And this can be done for much less time and money than it traditionally took to custom-create it from scratch.

But beyond an integration marketplace, you should consider other places to call attention to your integrations, such as within your marketing website. Remember, you want to treat your integrations the same as you do the rest of your product features.

So, don't be afraid to make noise about them. Press releases, social posts, and emails are all legitimate avenues for spreading the word. Integrations can add remarkable value to your product, so make sure your customers (and future customers) are factoring integrations into their buying decisions.

Finally, with integrations, you usually work with a third party (tech partner). Take advantage of that relationship for cross-promotion purposes. Doing so can strengthen partner relationships and increase your visibility in new market segments.

Who benefits from making integrations key product features?

You do. And your customers do.

Making integrations key product features sets you up to win more deals, deliver integrations without disrupting the product roadmap, reduce your team's onboarding and support efforts, improve your customer experience, and increase product stickiness (and customer retention).

The good news is that you and your team don't need to learn a bunch of new skills to treat your integrations as product features. You're already doing all the right things with existing product features. Now, do those same things with your integrations.

If you are ready to level up your integrations, schedule a demo, and we'll be glad to show you how Prismatic can help you turn integrations key product features.