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.
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.
Crossbeam’s overall partner ecosystem consists of three main focuses:
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.
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:
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.
Brent says that the senior executives at Crossbeam know that what they do best as a platform is being a partner ecosystem. So its core product strategy is for Crossbeam 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.
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.
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. The parts of the integration must be done correctly, as the costs of updating/changing an active integration can be extremely high due to the need to transition or sunset existing customers. Additionally, suppose you wanted to make breaking changes to your integration after it’s released. In that case, you’d need to figure out how to support multiple instances of your API, which can be easier said than done!
The work of building a tech partnership doesn’t end once the integration is live. In many ways, that’s just the start because that’s when the co-marketing, co-selling, and customer support work comes in.
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, tech, 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 teams on the partner’s side).
Customer support strategies
Customer support is another huge issue when it comes to integrations, especially for those that are partner-built. Crossbeam provides their team with standard FAQs they can turn to as a first response resource, which generally fixes the problem of common user setup errors. Failing that, they would then pass the users 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.
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 has customers go and 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.
Longer-term, Crossbeam has noticed that 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.
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:
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.
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 deals with the problem of attribution in three ways:
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.
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 possible types of use cases partners may want to build.
However, how your API is designed is equally important as what endpoints to expose in your API.
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:
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.
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.
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. Sign up for a Paragon demo today, and we’ll help you take the first step towards accelerating your integration strategy.
