Integration Strategy - An Overview

My background, some key assumptions, and open questions

Personal Background

While this Substack is predominantly about synthesizing external sources of information on Enterprise Ready product, organizational and technical strategy around integrations is something I do feel qualified to speak about from my own experiences.

I was on the Microsoft Power Query team as a Senior Product Manager* for four years. Power Query, if you're unfamiliar with it, is the data ingestion interface (generally paired with the Mashup Engine as a single capability, though sometimes split up) used in Excel, Power BI, and a number of other locations (Power Automate has a connector for it, Azure Data Factory has an integration I helped implement, Dataflows, and so on).

My core responsibilities eventually included product ownership of (almost) every connector in the Power Query portfolio, with one large exception of SAP connectors

, because that was a lovely year+ long ramp that my boss had recently done.

I don't recall exact numbers (you can check at the Power Query website!) but this included something like 50-70 in house connectors, and an equivalent number of third party ones. Obviously, many of these required very little attention, but were still my responsibility nonetheless.

Lay of the land

Before I dive into any details on integration strategy (such as 1st vs 3rd party integrations, supporting across multiple platforms, whether you have a certification program or not) I want to lay some foundations that I learned, some obvious and some hard discovered.

In my experience, integrations generally have a power law falloff. This isn't universal - you can imagine an industry where there are only two providers that matter to provide integrations for and thus don't have a power law falloff - but it is what I saw in business intelligence.

This means, effectively, there's an 80/20 type effect, at least. That is, 80% of your user needs are covered by 20% of the integrations. When I say at least, I mean it may be even stronger - you might find that 80% of needs are covered by 5% of integrations.

Unfortunately, every enterprise is going to have a few of those integrations outside your core support list, and if your product lies at the beating heart of the enterprise in some way (business intelligence, log analytics, workflow automation) it is highly likely that there will also be some rare and unfortunately hard to support integration that perhaps only one or two customers will use.

Open Questions

Obviously, this introduces a number of questions, each of which deserves its own short analysis.

First, you need to understand what the key, must have, table stakes integrations are. The ones shared by the majority of your customers. This may be obvious, but I'll dig into a way to think about it. Firmographic breakdowns may help here as well.

Second, you need to determine where your internal support cutoff is -- and under what principles. On the Power Query team, while we'd developed many of the original connectors for third party services, it became more difficult to maintain these as the product grew, and we transitioned them where we could to ownership by the third party service. This wasn't universal - for example, something like Salesforce we kept in house - but done for lower usage connectors that we were not responsible for the service. Even internally where we could we had the owning team take responsibility for the connector such as for certain Azure services.

Third - placed together because these questions need to be answered together, not necessarily in order - you need to determine the technical solution for integrations that you don't develop or offer yourself, and you need to determine the organizational plan around it. I'm disregarding the idea that you don't need a solution - that's fine for SMB, but it's not going to fly for enterprise. Very briefly, this could include third party integration vendors, APIs, drivers, SDKs, etc. on the technology side, and certification programs, marketplaces, or a simple wild west of 'share what you want' for the distribution.

I’ll address each of these in their own post.

* It was a Program Manager title, but Microsoft's Program Manager role - at that time and I believe to a degree currently as well, incorporated the duties of what is broadly in industry called a Product Manager.