A Product Manager’s Approach to Building Integrations for SaaS Software [Mind the Product]

Software as a service (SaaS) has become much more attractive to customers as SaaS companies embrace the idea of offering rich integrations with other platforms.

All of which means that open APIs have become an important aspect in driving growth, because a stellar API means that it becomes easier to integrate with your SaaS. Easy authentication and the use of REST hooks will lower the barriers for other web applications to build and offer connections to your web app, which opens up avenues to attract and retain customers.

Mailchimp, for example, has leveraged this strategy aggressively, and arguably was ahead of its competitors in pushing integration. Integrations also expose the depth and breadth of an SaaS product that may not be immediately apparent. This gives added incentive for a user to open the product, and use it for a longer period of time.

While working on a knowledge management solution aimed at custom support and sales teams, we integrated with several customer support desks and CRM. Below are some of our learnings, as well as approaches and practices that product managers can look at as they start thinking about the integration of their SaaS software.

Integration Types

Broadly, integration falls into two categories:

Data Integration: These patterns address the requirement to synchronize data that resides in two or more systems so that both systems always contain timely and meaningful data. Data integration is often the simplest type of integration to implement, but requires proper information management techniques to make the solution sustainable and cost-effective. Such techniques often include aspects of master data management (MDM), data governance, mastering, de-duplication, data flow design, and others.

Process Integration: The patterns in this category address the need for a business process to leverage two or more applications to complete its task. When you implement a solution for this type of integration, the triggering application has to call across process boundaries to other applications.  Usually, these patterns also include both orchestration (where one application is the central “controller”) and choreography (where applications are multi-participants and there is no central “controller”).  These types of integrations can often require complex design, testing, and exception handling requirements. Such composite applications are also typically more demanding on the underlying systems because they often support long-running transactions, and the ability to report on and/or manage process state.

Integration Practices

We may not realize it, but building integrations is relatively expensive, because:

• You need access to the system you’re integrating into (did you pay for that partner program of one of those big vendors yet?)
• You need to learn the API of that system
• You need to design, code and test the integration itself
• Every time you or the other vendor performs an update, you’ll have to run regression tests. As things change on either end, you may have to make some changes and re-release. Worst case, you’ll have to redesign your integration.

In fact, integrations can often derail product roadmaps, so it is imperative for product managers to plan them well. Here are nine considerations which I found very useful to bear in mind when working through integrations.

1. Good Integrations Start With Customers

Treat integration like building any new feature – find out whether your customers have a real need for it, and whether building it actually attracts the right sort of customers. Whether the integration request comes from partners or from customers, the first step is to find at least two or three customers who are interested in using it. If you can’t easily find customers who will use the new feature, then you should ask yourself whether it’s a good idea to build it.

I’ve found it particularly useful to check with customers which other software systems they use during initial discussions, and then to make it a part of the persona definition. Integrations that can delight several current customers or help you to close deals with several prospects of course get prioritized.

2. Prioritize Long-term Roadmaps Ahead of Quick Hacks

When building an integration, it’s tempting to figure out the quickest possible way to get it out the door. And while I agree that shipping fast is generally the top priority, it’s important to remember that there are two companies involved with any integration, and generally a lot of coordination penalties. If your integration is built on top of a system that will soon be depreciated, it’s usually a good idea to wait until the replacement is rolled out and fully tested. Otherwise, you’ll build the integration, get people to start using it, only to scramble to fix things when the integration inevitably breaks.

My experience has been that the real work begins after the first couple of integrations. While initial integrations were factored into roadmaps and engineering workload, we were not realistic about what it takes to maintain what we had built. APIs change, improve, and require you to adapt. And APIs disappear, for minutes, for hours, forever. The technical debt of API integrations can become daunting. It is essential to plan for these.

3. Maintain Good Data Quality for Outbound Integrations

When conducting an outbound Integration (an integration that is sending data to another system), remember that your data is now in two or more applications at once. If you had bad data or too much data in the source application, you’ll now have bad data in the target application. This has the potential to create a significant data hygiene issue.

While integrating with Salesforce, we made the mistake of incorrectly assuming that importing and exporting data from Salesforce is the same thing as integrating in real-time. In reality, exporting data files in batches provides only a snapshot of information at a moment in time. So it is important to understand whether your integration is a real time or a batch integration. And regardless of how often data is imported and exported as files, some applications will not be in sync with real-time changes. Understanding this reality will help to ensure data is accurate and consistent.

A strategy that worked well for us was to audit the data semi-regularly to ensure it was as clean and consistent as possible. SaaS integration is all about communicating information from one application to another, so the cleaner your data, the easier the entire process will be.

4. Support Your Users’ Big-picture Plans

Integrations support and enhance your customer’s big-picture process. They are valuable because they embed your product in a SaaS ecosystem. Integrating your product with other SaaS products communicates to your customers that your company is looking to improve its entire user experience.

Better user experience supports increased engagement, which is the high-level antidote to churn. Add concrete value to your product by adding integrations—you’ll combat churn and support your company’s growth.

5. Build a Foundation

When you’re new to building integrations into your product, it’s easy to start building without a proper architecture in place. If your first integrations are built as a one-off, they are likely embedded into the main source code of your product. You need an architectural layer that is aimed at integrations specifically, and that allows you to deliver integrations independently from your core product. At minimum, this means you have an API that exposes your data and functionality. You can either build your integration directly on that API, or have a specific integration layer that has additional functionalities like caching, scheduling of data transactions, transformation capabilities and so forth.

We learned this the hard way when initially confronted with the unexpected hurdle of integration with Slack, we gave into the temptation to create custom code to enable integration and communication with a Slack channel. Implementing this ad hoc solution limited our growth potential because we needed to strap on more and more code as we integrated with other platforms such as Salesforce and Zendesk. In fact the custom code led to a brittle connection that was easily broken when we tried integration with Salesforce. Because of this, it was only a matter of time before we outgrew our custom code and needed to strip it all out in favour of a more scalable system.

6. Consider Scale and Speed

Any time you exchange data between servers, you need to consider the scale of the data and how quickly it needs to be processed. Sending 100 records per hour is very different from sending 10 million. If your partner has an API that accepts 50 events at a time and you need to send 10 million events, you may be in trouble, unless that API can handle massive parallelism (or the data doesn’t need to get there for quite a while). On the flip side, you don’t need to be able to ingest one million events per second from your endpoint if the actual load is going to be miniscule.

A design philosophy that we adopted was that of caching data from external APIs that we might need to serve on the application. We built a separate background process for automated data collection from the API, and then build applications on the resulting database. This isolated the application from latency and rate limit issues.

7. Documentation

If your product supports multiple integrations, you’ll thank yourself for the good documentation down the line. Everyone agrees that great documentation is important, yet it often gets tossed to the end of the list.

8. Track Your API Users to Gauge Integration Effectiveness

It’s important not to get stuck in the correlation vs causation trap here. While we’re likely to find that users with integrations are better customers, this doesn’t mean we’ll see the same result if we convince any user to connect integrations. But you could look for early signs of engagement, such as more usage in the first two weeks than the usual signup, and seek to “lock that in” with opportunities to magnify the value your service provides.

In order to gauge the effectiveness of your integrations strategy, you’ll only need to know a few things about your users:

• Who has upgraded / converted
• Who has downgraded / churned
• Who has used an integration

In our case, we correlated “integrated users” vs “non-integrated users” to in-app activity, and again to freemium conversion. This analysis surfaced that the most likely customer among our trials were users who enabled an integration early on. This turned out to be a highly reliable and actionable “buy signal.”

9. Integration Options

There are are handful of options software companies can take when it comes building integration. Historically the three main options have been:

1. You can develop an open API for your product to let your customers build integrations on their own. But simply put, your API is not enough. The main issue with this options is that integrations are only accessible by your customers’ developers and you’ll most likely suffer from low user adoption.
2. Send your customers to citizen integrator tools (like Zapier and IFTT) to manage their data mapping needs. Although these tools seem like an attractive option, they force you to send your customers outside of your product, sacrificing your user experience, plus your customers will have to pay an additional price to integrate your product to their app ecosystem.
3. Build native integrations so that the integration feels like a natural extension of the product. I personally favor this approach as it helps you truly exploit the capabilities of the partner platform but, depending upon on the stage of integration or how confident you are whether it will deliver dividends, you may want to go with any of these approaches to test your integration.

Conclusion

Even though cloud computing has made it easier and more affordable to deploy business apps, it has created a need to simplify process flows that cross multiple platforms from multiple vendors. Offering pre-built integrations helps software companies remain competitive and have a deeper understanding of customer needs. However, building integration is really difficult. The sheer number of applications, platforms and services that you may need to integrate is growing at an incredibly rapid pace and it’s very difficult for your developers to keep up. Hence it is important to choose the right integration options for your software.

The post A Product Manager’s Approach to Building Integrations for SaaS Software appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2019/03/a-product-managers-approach-to-building-integrations-for-saas-software/