Scaling an Integration Ecosystem with Partnerships and API Design

Crossbeam is a leader when it comes to building out a world-class integration ecosystem. In the first six months of 2021, they launched 30+ integrations through the Crossbeam Partner Cloud. 

We recently interviewed Brent Gann, Senior Product Manager of Ecosystems at Crossbeam, about why integrations are such a central piece of Crossbeam’s strategy and some of the challenges around building them. 

Brent is unique in the integrations world because he’s sat on both sides of the aisle over the last decade. A professor of computer science, he previously built products as an engineer, transitioned to an API product manager, and now manages the creation of product ecosystems as a product manager.

You can watch and listen to the complete discussion with Brent here. However, if you’d prefer to read a summary, this post is for you.

TL;DR

• Crossbeam is a partnership ecosystem platform that allows companies to enable partnership data and unlock co-sales and co-marketing opportunities.

• Crossbeam’s integrations make their partner data “actionable” and create new use cases for customers to get value from Crossbeam data.

• New use cases start from forming hypotheses around how their data can be used and then seeking to validate those hypotheses with real customers, sometimes building an MVP.

• Senior management at Crossbeam believes that the company should focus on what it does best and find ways to unlock new value through integrations.

• Integrations are not a one-and-done thing. Instead, they must be built incrementally and nurtured to respond to new customer use cases.

• Maintenance of integrations is one of the most resource-intensive components of managing an integration ecosystem.

• For long-term growth, it’s much more effective to build embedded integrations than to use a stop-gap like Zapier.

• To calculate the ROI from integrations, Brent and his team have developed numerous ingenious ways to attribute impact on revenue and retention.

• Crossbeam’s team has had to build a complex testing infrastructure in-house to test their integrations at scale. 

• To build an API successfully, Brent recommends ensuring the whole team is on board, doing a lot of listening during the discovery phase and ensuring that the code is as user-friendly as possible.

• Brent is confident that the 2020s will be the decade of partnerships as more and more companies realize the value of deep specialization and doing things outside their specialty through integrations. 

What is Crossbeam? 

Crossbeam bills itself as “LinkedIn for partnerships.” The company, founded by Bob Moore and Buck Ryan in 2018, provides businesses with a partner ecosystem platform (or PEP, for short) to help them build more valuable partnerships.

Central to Crossbeam’s value proposition is the enablement of partnership data. By using account mapping, companies that work together on Crossbeam can figure out where their customer bases and prospect lists overlap, allowing them to unlock innumerable co-sales and co-marketing opportunities.

How does Crossbeam enable businesses to build partnerships effectively?

Crossbeam’s overall partner ecosystem consists of three main focuses: 

1. First, integrations built and maintained by Crossbeam: This conventional model of integrations allowed businesses like Hubspot to proliferate. 

2. Integrations built and maintained by partners: Crossbeam helps partners build integrations with its platform, supporting them through the scoping phase and ensuring they use Crossbeam data to maximize end-user value. 

3. API as a product: Crossbeam views its APIs as a set of products requiring as much diligence, research, and discovery as any user-facing product feature. 

Before we get into it, let's provide context on Crossbeam's partner data, which is the fuel for all their integrations. Crossbeam allows companies to upload data from their CRMs into a neutral and secure environment to identify overlaps with other companies' CRMs, without worrying about oversharing proprietary data.

As a result, this partner data from Crossbeam provides an added layer of insight on any customer/prospect, which can then be leveraged in infinite ways.

Why are integrations a fundamental part of their product strategy?

Even before Brent joined Crossbeam in 2021, the company had already launched a thriving integration marketplace called Partner Cloud. Crossbeam offers numerous ways to leverage data from mapped accounts across partners in the Partner Cloud. For example:

• By integrating Crossbeam and Marketo (marketing automation platform), marketing teams can build targeted, dynamic audiences in Marketo based on Crossbeam’s overlap data without manually defining the lists. This enables users to build highly effective co-marketing campaigns, including promoting partner-led webinars and highly contextualized and personalized outreach. 

• By integrating Crossbeam and HubSpot, account executives (AEs) using Crossbeam can trigger workflows, set sales follow-up tasks, and build reporting dashboards to monitor partner campaign performance, all within their CRM. 

Brent sees the idea of making Crossbeam data actionable (what he calls ‘actionable partner data’) as a critical driver of Crossbeam’s decision to embrace integrations. By that, he means the process of identifying new use cases from the partner data created within Crossbeam, such as overlaps and shared accounts and surfacing it to their customers’ various teams like sales and marketing.

While their primary users are partnership managers, a lot of demand for Crossbeam data has come from their customers’ cross-functional teammates in the sales, marketing, and customer success functions.

However, SaaS teams generally contain a low ratio of partner managers, so automating the sharing of actionable partner data is immensely valuable. 

As a result of the time they save and the added value they create, uptake of integrations has surged, with five to six Crossbeam customers adopting new integrations daily. Crossbeam’s long-term goal is for everyone in their companies to access partnership data in their daily workflows—without having to go through four or five different logins to access it. 

What led to Crossbeam’s strategic focus on integrations?

Crossbeam's leadership team has been extremely intentional with their product strategy. They know that in order to succeed, Crossbeam needs to focus on what it does best and enable customers to do more across other platforms via their integrations. Put another way: Crossbeam isn’t a marketing automation tool nor a sales tool, but its data can make your go-to-market teams much more effective. 

To maximize the enablement of partner data, Crossbeam treats integrations like an extension of their core product. Whereas many companies approach integrations as add-ons to their product and assume that one use case will be sufficient, Crossbeam believes that the more people who access Crossbeam data for their specific use cases, the more customer value is created. 

This leads to a powerful network effect: the more integrations built, the greater the potential for exponential growth and value creation. It’s no wonder why HubSpot and Slack have become such dominant players in their respective spaces.

However, this focus on integrations as a driver of value comes with its own set of challenges, which is what led to the creation of Brent’s role at Crossbeam. The company needed someone to move its integration roadmap forward, build a network of partners, and find better ways to send data.

Determining use cases for integrations

Crossbeam’s team starts by looking at their existing customer data and formulating hypotheses for areas where that data can be mapped to identify potential use cases for their integrations. In most cases, they seek to validate those hypotheses with real customers before starting to build an integration. If the integration is straightforward to create, the Crossbeam team will even build an MVP version of the integration to beta-test it with co-customers.

Interestingly, Crossbeam uses its product to find beta-testers for their integrations. Brent describes an example of developing integration with a marketing automation tool. By utilizing the CRM overlap feature, crossbeam can use its software to easily find all customers who are also customers of the third-party app.

Once an integration goes live, however, given the high interest and usage, additional use cases for that integration will naturally pop up. Customers will naturally think of new ways to leverage Crossbeam data within these 3rd party platforms. As a result, the expansion roadmap for their integrations essentially writes itself. 

The challenges of building integrations

Brent shares the same perspective as us, in that lots of SaaS companies think integrations are something that can be done once and then forgotten.

Crossbeam’s preferred approach is the best practice of building iteratively - which is how most product teams treat their core features. It’s simply not feasible to be aware of nor build for all the possible use cases simultaneously, especially since those are constantly evolving. So it makes much more sense to start small, build out, and ‘grow’ the integration over time. 

However, starting small does not mean it’s easy. Every component of each integration must be carefully designed and implemented, as the costs of updating/changing an active integration can be extremely high due to the need to transition or sunset existing customers.

Integration maintenance and testing

Even when you have access to Crossbeam’s level of resources, parts of integrations still break all the time. Unfortunately, this is an evergreen problem: integrations are messy by nature, so having a robust monitoring suite and testing process is critical. Otherwise, it’s very difficult to identify where things went wrong - was it an issue with your product or the third-party app, or did your user simply misconfigure a setting? To reduce the probability of breakage, Crossbeam has a robust testing process consisting of three types of testing:

• Unit testing, which is where you test the specific part of the integration you’re currently building

• Integration testing, which is where you test the whole integration to see if it works

• System testing, which is where you test the integration at scale

While unit testing is relatively straightforward, integration and system testing often require Brent and his team to build a complex testing infrastructure.

Let’s assume that Crossbeam was testing an integration with partner X. To do this properly, they’d need to build both a Crossbeam and a partner X instance. But what if the integration is required to pull data from Salesforce? They’d need to build a Salesforce instance, which would be connected to both previous instances. The more third-party representatives are involved in the integration, the more complex the testing work becomes. No wonder Brent says his team has run strategic betas for a long time to ensure everything works properly. It’s an expensive way of testing things—but it works.

Tech partnerships

As a leader in the partnerships space, Crossbeam's team is well aware of the value tech partnerships can bring. For them, building integrations not only address specific customer requests, it unlocks joint go to market opportunities for them with the integrated partner.

Additionally, they've opted to offload the development of their integrations with smaller partners, which has further allowed them to accelerate the growth of their integration ecosystem.

However, this doesn't come without its challenges.

Brent points out that product management is a game of telephone even at the best times. You must communicate with numerous stakeholders, including product, revenue, engineering, and customers. When you add integrations into the mix, that game of telephone becomes even more complex, as you have 2x the stakeholders (from all those same teams on the partner’s side). 

Partner-built customer support strategies

One of the most prevalent challenges is around customer support, especially for those that are partner-built.

Brent ensures that in order to provide prompt support to customers, they need to arm their support team with integration specific FAQs that they can turn towards. This generally helps them address user-driven errors, but failing that, they would then triage the issue to the partner in as few steps as possible so that the partner can look into the issue further. 

It’s very important to Crossbeam that the customer always feels like the integration is part of the ecosystem, regardless of who built it. In cases where Crossbeam didn’t build the integration, they still want their customers to feel they can come to Crossbeam with issues and that support will be there for them. 

Why you should be the one to build the integration

Whether you think so or not, integrations are inherently a core part of your product—the integration user experience you provide your customers can make or break their perception of your product. For that reason, every SaaS business should always try to own as many integrations as possible to retain control over that user experience. In Crossbeam’s case, this is especially true for their CRM integrations.

Of course, for the long tail of one-off integration requests, Crossbeam does direct their users to use Zapier or pay 3rd party dev shops to build the integrations on the customers’ behalf. These options have been a necessary stop-gap when users clamored for a particular integration. However, this was not a preferable solution by any means.

Crossbeam has noticed, however, that longer term, the cost of middleware like Zapier starts to eat into their revenue for any particular integration over time, as customers resort to paying for the 3rd party service instead of Crossbeam for the integration. While it’s somewhat of a predictable cost, it’s not as profitable as building in-house, especially given how much quicker integration development has become with an embedded iPaaS like Paragon. Ultimately, the more integrations you embed in your app, the more you can monetize the value created.

The only exception to this rule is when a particular integration is much more lucrative for the 3rd party company than for you. In these instances, Crossbeam prefers the partner to build the integration as they’ll be incentivized to continue improving the functionality for years to come. 

API best practices 

In order to enable partners to build integrations towards your product, you want to ensure you have a solid API for them to work with, which is easier said than done.

The challenge of building a robust API is the lack of boundaries regarding potential use cases. Compared to building integrations, where clear use cases have been defined and the third-party API is already documented, building an API requires a deep understanding of the potential types of use cases partners may want to build.

While most companies are focused on determining what endpoints to expose in their API, Brent emphasizes that the design of your API is equally important.

Design and User Experience

It’s easy to forget that the engineers interacting with your API are, nonetheless, users. That’s why user experience is often overlooked when designing APIs, as it’s easy to expect them to just figure it out through the documentation.

To design a well-thought-out API that puts the developer experience at the forefront, make sure you consider the following factors:

• How will you handle authentication

• How should users access specific calls

• What do objects look like

• What scopes need to be created to limit access to data

Ultimately, the best-in-class APIs need to be standardized, well documented, and as flat as possible. And the art lies in the balancing act of having the right amount of data made available with the least amount of calls.

API Documentation best practices

Flatter APIs

Flatter objects are easier to map and, as a result, require far fewer calls to get to the necessary data.

Standardized responses

Regardless of where a user calls an object, they should get the same object back. For example, if you call to get an account from Crossbeam, no matter where you make that call, the object you get back should always be the same account object. There may be some empty fields sometimes, but you should always get the same standardized values back. 

The ultimate goal here is to ensure that API code is user-friendly. As an engineer, it’s easy to think in mechanical terms about things like button placement and forget that the person on the other side of the API is an actual user. However, Brent’s thinking on this has become much more user-centric since he switched from being an engineer to working in product.

Additionally, because you will inevitably need to make breaking changes to your API once partners have begun to integrate with your product, you need to figure out how to support multiple instances of your API, which can be easier said than done especially if left as an afterthought.

Measuring integration ROI

But how do you accurately attribute revenue to an integration you've built?

That's the million dollar question. It’s notoriously difficult to attribute a deal or an increase in ARR to one or more integrations or partnerships without a robust process for measuring the ROI of that integration. Crossbeam, however, is hoping to help address the challenges of attribution for their customers in three ways:

• They’re building an integration with Gong. This would mean that every time a partner gets mentioned on a sales call, that partner’s information gets fed back into Crossbeam.

• They’re creating an activity timeline within Crossbeam that tracks events like the prospect having a call with a partner at a critical point in the sales cycle or the prospect mentioning that they need a particular integration. 

• They listen carefully to their AEs and pay attention when an AE thinks that an integration is critical for closing a deal.

Brent acknowledges that none of these solutions is perfect and that attribution is still a problem. However, with a robust framework, you will be well-equipped to address it.

Integrations are the future of SaaS growth

Historically, companies created value either by building solutions themselves or by acquiring the solutions built by other companies. But, as the growth of the SaaS industry shows, it’s getting easier and easier to build things. For companies that grow solely through product development and acquisitions, there’s a risk that a smaller business will build a better version of a more minor part of your portfolio and knock out that part of your market and ARR.

Brent’s solution to this paradigm shift is to focus on integrations and partnerships. He even goes as far as to say that he thinks that the 2020s will be the decade of the partnership movement, just as the 2000s were the decade of engineering and the 2010s were the decade of product management. 

Everybody wins if each company focuses solely on what it does best and partners with other businesses to do things outside that. Customers win because they can choose the best product in each solution category. And the companies that create the best solutions in every niche prosper because happy customers are unlikely to churn. So the market benefits the most when each SaaS provider has its unique specialization and integrations that connect all the different specialists. 

The recurring theme throughout this is just how important it is for your SaaS company to build a robust integration ecosystem. They are paramount to shortening sales cycles, winning more deals, reducing churn, building new use cases, and improving retention.

However, despite all these benefits, building integrations from the ground up is not a good use of engineering resources nor a scalable solution. That’s why even companies like Crossbeam use embedded integration platforms like Paragon to help offload over 70% of the engineering work required per integration. Book a demo of Paragon today, and we’ll show you how you can take the first step towards accelerating your growth with a better integration strategy.