Product Manager's Dilemma: Build vs. Buy

Integrations have become the easiest way to turn a product into a platform. Extending your application's reach by either embedding yourself into an ecosystem of applications or creating new ones. A recent research paper found that API adoption predicts a 10.3% increase in a firm's market value. Making API integrations important is a necessity instead of a nice feature.

We know integrations are important, but how you approach your integration strategy will also have substantial impacts on how quickly you go to market and claim those future gains. This guide will uncover the hidden nuances in deciding whether to build integrations yourself or to look for an integration platform partner.

Where Is it on Our Backlog?

Where do integrations live in your organization and is the priority the same across departments? What might be seen as a critical component to capture market share in the product management could be seen as a thorny black hole in engineering. Integration platforms increase your feature throughput by delivering on your roadmap without increasing development backlogs.

Build: Top priority and you have the capacity in your roadmap and development team.

Buy: High priority but lacking the development capacity and expertise.

Do We Need Just a Connection or a True {Advanced} Integration?

The level of interaction you have with the integrated applications matter. Simply getting information from one system and directing it to another is fairly straightforward. Updating, transforming and orchestrating that information that is intertwined with your application and business model is inherently more complex. How will you handle authentication, eventing, and pagination? Which API specification will you use? Do you need to transfer in bulk?

Build: Simple use case of pulling data from one application to another in its original state.

Buy: Getting, Transforming, Updating, and Orchestrating data to your application.

Do We Want to Handle Business Logic in App or in API?

Integration platforms have the ability to put event-based business logic directly into the API. Saving development cycles by orchestrating the data on the fly based on the activity of the user and data being integrated. If you think about your organization as a car, do you want to focus your efforts on just the core engine or expand the scope to include intake and exhaust?

Build: Let your application handle all logic, even the mundane bits.

Buy: Transforming data and adding business logic directly into the API.

Do We Need to Build More Than One?

Odds are that your customers are just as, or even more, connected than you are, such that you will likely need to have multiple integrations to cover different use cases that are represented from multiple applications. There were over 5,381 MarTech applications alone in 2017. This wouldn't be an issue if all APIs were made the same, but we are far from it. Can your application consume both JSON and XML? Can your application receive webhooks? Even if it does, a majority still only allow polling so you'll need to add polling logic in as well. Testing environments, sandboxes, and SDKs add to the delivery timeline.

Build: Want to live within the ecosystem of one application (HubSpot).

Buy: Want to live within multiple ecosystems (Marketing Automation and CRM).

Who Will "Own" it and Maintain it Once Operational?

Integrations are not only fluid by nature but ongoing. You need to define who will own the maintenance of version changes but, more importantly, the additions. You're not the only one building new features. The source application will have new resources, fields, and logic to take advantage of. Who will take these changes back to the product and with what priority? What if the developers who built it can't maintain it? The best fire drills are the ones out of your control.

Build: Clear process and ownership of maintaining parity with the source application(s).

Buy: Let the platform capture changes, allowing you to decide your own pace of product change.

Do You Want Speed or Experience?

In partnering with an integration platform, you also gain the expertise and guidance of the various applications with which you're integrating. In doing so, you accelerate your time to market by leveraging other people's experience with those various applications. This trades time in the market integrations for the time your team would have to spend learning about integrations.

Build: Want to spend more time learning how the application's APIs work.

Buy: Want to spend more time in the market selling the integration.

Ultimately, when it comes to integrations the decision to buy vs. build becomes: how much time do you want to be building in your application vs. building against other applications? We have seen how accelerating time to market with integrations more than outweighs the cost of bringing in a platform.