Thinking about Product Integrations

‍

If you’re building a SaaS app, and it's 2024 or later, you’ll need to help your users pull their data from their existing sources and apps. No new user wants to manually enter data and it's very likely they already have their data somewhere and most likely another app. If you don’t give them some way to pull that data in, they’ll never onboard, they’ll never be happy, and they’ll never get activated. Which means you won’t be happy. We don’t want that, now do we?

‍

We solve this with Product Integrations. These are integrations that sit inside your product where your users can discover, configure, run, and manage them, by themselves. With the popularity of SaaS in the last 20 years ever since Salesforce started hating on installed software, your customers are using at least a dozen apps… all of this means that you’ll need to support integrations to many, many apps. 

Product Integrations are vital but they’re also a developer blackhole where the engineering team thinks its an easy build but the real-time sink comes from the hours of figuring out customer permission issues, going through code logs, figuring out weird and undocumented API behaviors, keeping up with API changes and trying to convince customers that swear they have access permissions, that they do not have access permissions. I’ve worked in integrations for over a decade, and no engineer wakes up and says “Aw jeez, I can’t wait to work on the 10th integration today!” it does get boring and demoralizing. So, you’ll ideally need a great framework that does the heavy lifting for you or even better an integration platform (hello 👋). Given all these issues, what's a good way to think about successful product integrations?

‍

A great mental model for Product Integrations is to think of them as product features

‍

A great mental model for Product Integrations is to think of them as product features. Everything that is true about product features is true for Product Integrations:

1. Designed and built by product teams
2. Does the feature solve the problem or does it perform a job (JTBD framework)
3. The feature should be prioritized and aligned with your business objectives. This should be easy since Product Integrations reduce churn, help onboard users faster, increase your LTV, unlock sales and a whole host of things. And by using an integration platform, you don’t incur the same time and cost of building them.
4. What percentage of users are successfully using the feature
5. How many users are able to successfully complete the feature journey? Ex: successfully setting up the integration
6. You need help and documentation for those features
7. You need to provide a UI and UX that is consistent with your app
8. You want to give users enough visibility into the feature so they can figure out and solve any issues with the feature (ex: telling the user that the Slack integration has failed because you deleted the Slack channel without having them reach out to support)
9. Is the feature discoverable?
10. Is the feature well communicated and marketed (product marketing)
11. Is the feature part of pricing or a tier? Is it tier-gated or usage-gated?
12. Measure satisfaction scores from customers on the feature (“You set up the Slack integration a day ago, how was the setup experience from 0-5?)

What I like about this mental model is that as a product creator, you already have this model in your head. Hell, we're sure you're awesome and building features. Just apply this thinking to Product Integrations. When thinking about picking an integration platform, create a checklist for this model to see which integration platform works best against it (spoiler alert, the best is Integry, fr).

What Product Integrations are not

There are many different types of integrations. Here's what product integrations are not:

Product Integrations are not Internal Integrations

You know, the kind you use inside your organization to connect internal tools. Product Integrations are always customer-facing and they will be set up multiple times by different customers. 

Product Integrations are not Enterprise Integrations

‍Product Integrations are also usually not one-off. Why? Going back to our mental model, would you create a feature that would only be used by one customer? I hope you answered no. Even if you’re an early product and you make a feature at the request of a single customer, I’m willing to bet your hope is that you’ll find more customers that will use that feature. 

How do you build enterprise integrations?

But, if you’re selling to enterprises, there will be custom-integration requests. We like to refer to them as enterprise integrations: these are customer-specific, one-off integrations that a contract demands and is needed for your customer’s success. What about those integrations? 

While we think hand-coding Product Integrations is a bad idea, hand-coding one-off integrations is even worse. Imagine maintaining separate code for every single enterprise customer? Yes, it's as awful as it sounds. 

You likely have three options when thinking about enterprise integrations:

1. Use an “Internal Integration”, no-code tool. For example, Zapier. Your services team would build those integrations or a partner or you could give your customers access to such a tool. However, as a customer, learning an entire integration tool and then being responsible for it working just doesn’t sound efficient. 
2. Use a product integration tool that is no-code, allows you to create one-off integrations and you can deploy it in your customer accounts alongside other product integrations. You still have to maintain the one-off integration but hopefully, because it's no-code, it's faster to build, change and debug (like, you know, Integry).
3. Your app could have its own workflow editor where users can build and customize integrations. This is of course a really large lift. If you’re in the marketing category, you might already have this. We think every mature SaaS app eventually has its own workflow editor. You can use frameworks provided by product integration tools to build such a workflow builder as well (are you thinking about it? Talk to us).

In Conclusion...

So, there you have it. Product Integrations are everywhere, they help customers get onboarded quickly, they help your customers receive ongoing value from your app without them logging in (integrations never sleep), and they connect with your customers' existing app and data investments. By thinking of these integrations as features, you can think about who works on them, how they get released, and how they are maintained. If you’re thinking about product integrations, reach out to us.

‍