Lessons From Scaling to 50+ Integrations - Bynder

Unlike regular product features, building integrations requires in depth research in different verticals that you and your team may not have expertise in.

Take HubSpot for example. Early on in their journey, their product was purely designed for marketers. The success and traction they garnered was directly due to their product team's ability to develop a deep understanding for the needs of marketers, and designing features for HubSpot that would streamline marketing automation workflows.

However, over time they began to build integrations that were meant to be leveraged by other teams outside of marketing (particularly sales), and this meant that they needed to either build expertise around those new users, or leverage 3rd party partnerships.

This was the exact same situation that Toni Aquino, Group Product Manager at Bynder, found her team in. Bynder is a digital asset management platform (DAM), that has rapidly scaled their integration roadmap to over 50 integrations over the past 2 years.

With that came a lot of learnings, and this article will abstract and elaborate on some strategies that Toni shared on our podcast, so you can avoid running into the same challenges.

Why integrations are crucial for growth

Companies and teams are using more technologies than ever before to manage their day to day operations, especially with the recent shift towards remote work.

Today, everyone is dispersed and integrations and have become one of the main levers for teams to stay as productive and efficient as they had been when they worked together.

For Bynder, having a growing library of integrations has enabled them to become extremely embedded in their customers’ marketing automation stack, which leads to significantly better retention.

However, as customers’ demands for integrations grow, so do the operational challenges of scaling a SaaS product’s native integration roadmap.

Prioritization of Integrations

Sales will always come to you with requests for integrations, because that is what they hear from prospects.

However, if your sales team is not diligent in parsing out whether or not the integration requests are dealbreakers or nice to haves, it can lead to months of development work building an integration that no one uses.

The requests that customer success gets on the other hand, are often derived by very real and tangible use cases that the customers are actively looking to support.

That’s why today, Bynder’s customer success lead has become Toni’s trusted advisor for streamlining requests, as they have a much clearer sense of the real needs of the customers.

Now, optimizing the prioritization process just the beginning - the real challenge comes with delivering the integrations.

Early days of building

Knowing which integrations to build does not automatically translate to knowing what use cases to build for.

So ensure you also have a clear process for your sales and customer success teams to document the use cases prospects/customers have shared.

At first glance, all the use cases will seem very unique, given the variability with how the customer describes the request, as well as how your team ingests and documents that information.

And ultimately, custom deployments of workflows for individual customers are not scalable nor repeatable, which is why you’ll want to minimize the custom work required as much as possible.

“Prior to everyone working remotely, we ran into quite a few requests for integrations and took a very custom approach. What the pandemic brought was needing to move very quickly and needing a less custom, guided approach - ultimately simplifying the use cases.”- Toni

At Bynder, they aim to have 80% of the use cases as boiler plate workflows, and 20% left for custom use cases.

in order to design these boilerplate workflows, you’ll need to analyze and consolidate as many requests as you can into a few bucketed use cases.

For Bynder, this is generally quite a straightforward process given the simplicity of most of the use cases. They’ve group it into:

1. Bringing data into the DAM

2. Sharing assets out of the DAM

3. Transferring data between two apps within the DAM

However, this grouping exercise alone is not enough to start building the integration - after all, the intel came through a game of telephone, from your core users’ coworkers, to your core user, to your sales/CS team, then finally to you/your product team.

Without talking to the intended users of the integration, there will be many gaps in knowledge around the context of the use case, and how it fits into their broader workflows. This leads us to the topic of integration design and discovery.

Workflow discovery

This step is where companies often struggle. So we asked Toni how they handle the integration workflow discovery process at Bynder.

“That’s the million dollar question, because the person that’s typically giving you the information is not the actual user, so we’ve had a lot more success in challenging our customers to bring in those additional users. In terms of scalability, the discovery piece is actually a big challenge, because getting to the day to day users not always at your disposal.”

Luckily, if you ask the customers that requested the integration in the first place, there’s incentive for them to contribute to the discovery process as it will directly impact the value they get from your product.

In terms of the format for these interviews, here’s what’s worked well for Toni.

“I’d encourage you to bring in a focus group you can probably do a Q&A and a survey in an hour’s time. You could spend 5/6 hours having individual interviews, but typically you get a lot more in a white boarding or group session.”

In cases where you really can’t access the targeted end users, you can also try looking internally.

Often times you may find a SME in a similar role, especially for vertical agnostic roles like sales, marketing, HR, accounting etc.

Scaling

For your first few integrations, it’s definitely within reach to go through the processes outlined above. But scaling your integration roadmap is not so simple.

“Ideally we could build everything, but that’s both a development and knowledge challenge,” says Toni.

On top of the engineering and product constraints, your customer success function will be burdened with having to be familiar with every single integration.

“Regardless of all the documentation you put out there, a customer when in a pinch is going to go to you, and that started becoming more of a challenge for us internally even, knowing who to route questions and tickets to.”

Frankly speaking, it is simply unrealistic to expect your support and enablement teams  to be well versed in all the integrations that you build.

The overarching theme here is that as you scale your integration roadmap, the burden of maintenance also scales.

Bynder’s partner ecosystem

Once Bynder experienced these growing pains that they started transitioning towards a partnerships and ecosystems model.

“Building an ecosystem allows us to take a step back and say yes, we’re the experts in DAM and the flow of content, but not the specifics of every single integration.”

Here’s an example of an integration that Bynder promotes, but was built by their partner Magnolia.

The prerequisite to a partner-led strategy is that a partnerships and ecosystem model is generally only realistic once you’ve built enough traction as a company. Otherwise there’s very little incentive for the 3rd party app to partner with you (ie. are you providing them access to a large enough pool of potential customers).

That said, once if you are able to gain buy-in from a partner by demonstrating the expected value of of the partnership, the dance is in determining how much and what each partner will be contributing. The larger partner will almost always have more leverage in the deal, which means in many cases your team may still be in charge of building the integration. Regardless, simply having access to a partner’s subject matter expertise throughout the build process can be worth pursuing the partnership, not to mention the opportunities for co-marketing and a joint go to market.

The transition from fully owning your integration strategy to opening up your ecosystem to partners and 3rd party integrators is not as simple as opening up your API. Here are some of the key takeaways and advice that you should be aware of:

Building best in class examples

Similar to what Matt from SugarCRM shared in the previous episode, Toni emphasized that building a solid foundation for integrations before opening the gates to partner-built integrations is crucial for success.

There will be similarities to how 3rd party apps of a specific category should interact with your platform. For example, customers that ask for a Salesforce integration and those that want HubSpot will generally have similar use cases.

However, just as it’s difficult for you to know the ins and outs of every 3rd party app, it is equally challenging for partners to understand how to best integrate with your app.

As such, it is in your best interest to go through a proper discovery and design process for the first integration you ship in any given category, so partners that want to build adjacent integrations have a reference as to ‘what good looks like’.

Equip them with best practices, use cases, and requirements, so they don’t have to start from scratch. This will not only speed up the speed to market for the integration, but it will also enforce a consistent experience across your various integrations.

One caveat, however, is that while integrations for the same category may seem identical, it’s important to build for the differentiating features of each 3rd party app.

The workflow ‘template’ from the fist integration will get you most of the way there for subsequent integrations in a category. Yet what sets a world class integration experience apart from an average one is in designing for the nuances between each 3rd party app.

Speed to market and tooling

Given the impact integrations have on customer acquisition as well as retention, speed to market needs to be a priority.

As such, building and scaling integrations in-house simply isn’t an effective strategy. This is why Bynder has leveraged embedded iPaaS tools both internally and for partners to accelerate the development of their integrations.

By using embedded integration platforms, they’re able to still maintain control over the uptime of the integrations while providing their partners all the tools necessary to easily build effective integrations between their apps and Bynder.

Plug: If you’re looking to close and retain more customers by scaling your integration roadmap, see how Paragon, the most extensible embedded iPaaS in the market, can help.

Shift in focus

The shift to a partner strategy will also likely impact the scope of work for the product manager in charge of integrations, which is exactly what Toni experienced at Bynder.

Instead of writing user stories for engineering, she now spends most of her time managing a multi-disciplinary team across product marketing, analytics, and customer/sales insights.

This is largely due to the fact that the work for launching an integration has spanned beyond just adding it to a sprint and shipping it through the engineering team. Ultimately, building a successful partnerships motion for integrations requires buy-in from the entire organization.

Cross-functional insights are crucial for identifying gaps that potential partners can fill, and investing in any partnership will require effort from multiple teams when it comes to co-selling, co-marketing, and joint customer success.

Support and Maintenance Challenges

“Regardless of all the documentation you put out there, a customer when in a pinch is going to go to one person, and that started becoming more of a challenge for us internally, knowing who to route things to.” - Toni

Generally, customers will not differentiate between who ‘owns’ an integration. When they encounter an issue, whether that’s due to user errors or bugs, they will naturally reach out to the support team that is most convenient in the moment.

Without clearly defined SOPs for who owns the support and remediation efforts, the customers will find themselves thrown back and forth like a ping pong.

I’ve personally experienced this multiple times as an end-user of Segment. Every time event data doesn’t pass through properly to one of my destination applications, such as Autopilot (email automation SaaS) or HubSpot, getting answers has been a nightmare.

Segment will say that they didn’t build the integration, and the 3rd party destination app will suggest it may be a Segment limitation.

That’s why it is important to have clear alignment and documentation for users to know exactly who to contact with questions/bugs for each integration, and this may vary per partner.

Wrapping Up

To sum it up, integrations are becoming table stakes for customers during purchasing decisions as companies adopt more SaaS tools to manage their operations than ever before.

Having the right strategy and framework in place for scaling your roadmap crucial for enabling sustained long term growth, and leveraging 3rd party partners can be an effective approach once you’ve gained traction.

If you have a backlog of integration requests that needs to be shipped in the next 2 quarters, you definitely don’t want to be building them in house. See how Paragon will enable your engineering team to accelerate integration development by 5x by booking a demo today!