Building a "Best of Breed" Product Integration Program

If you're a software team, product integration can be an effort that is value-generative and differentiating. But, many software teams struggle with it. Integration becomes seen as a burdensome, but necessary distraction from building their core product.

The fact is, if you sell a B2B software product, you have no choice. Product integration absolutely must be a priority for you. You can allow that to remain a necessary evil, or you can build a best of breed program for attacking integration requirements.

In this post, we'll dive into what a best of breed product integration program looks like, and how one can impact your software business overall.

What is product integration?

In general terms, software integration is the act of making two pieces of software pass data to and from one another in service of an end user's goal. This can include things like:

• Business users within a company automating a process across multiple technologies (e.g. an employee onboarding process)
• An end consumer making multiple apps on their iPhone share data (e.g. Apple Health)
• A digital agency tying together multiple technologies they've implemented on behalf of their client

These all count as integration, and while each shares some best practices and commonalities, each also has some very unique qualities

Product integration is one particular type of integration--when a software vendor (sometimes called a "publisher") needs to make sure the software product that they build and sell exchanges data with other products in their market. This is usually to satisfy required and high value requests of their customers.

Product integrations are important to a software vendor, especially when they produce business-to-business (B2B) software.

Reality check: no software product alone satisfies all of a user's needs. The software vendor's customer uses on average 8+ different tools in a day to do their job. If you are one of those tools, you add value by working seamlessly with the other seven (or more).

The extent to which a software vendor is able to put more integrations with more features into the market largely impacts their rate of success. Having more integrations opens up more of the sales pipeline (customers who "need that integration to buy"). It creates stickier customers who can change their tech stack without having to rip out your product.

But, here's the rub...

Product integration is hard.

Frankly, all software integration is hard, but product integration brings a unique set of difficulties with it. These include the following:

• Every minute or dollar spent on a product integration is a minute or dollar not spent on the core product.
• When you build a product integration, it doesn't just support one customer one time. It has to support as many customers who require it.
• That means you have to design it like a product feature by building enough flexibility to adapt to ~80% of customer needs.
• ...without building so much flexibility that it's a maintenance nightmare.
• Then, all of this times the number of product integrations your market demands. This could be dozens or even hundreds.

Oh, and you can't just ignore the problem, because your competitors definitely aren't.

Product teams as early as "seed" stage through large, well established vendors all struggle with versions of this problem. It just means and looks a little different to business in different stages.

The pain is most acute (and where Blended Edge spends most of its time) is in the growth stage for a software company. This is likely an era of hypergrowth--or at least investor expectations for it. It's a time when you have too many jobs to do and too few people to do them. And, it's a time where you don't have a long list of available integrations to help you close business in your pipeline.

The struggle tends to manifest itself as a version of this:

• You start coding new integrations from scratch, because that's what your engineering team knows to do.
• You build them as MVPs that close the deal but have little regard for scale.
• You sell more of them.
• You start having priority arguments about whether you "build this next integration" or "build this next product feature.
• When you get to build a new integration, you do it quick and dirty to get it done.
• Also, you still haven't gone back to pay off the technical debt on older ones.
• Thus, you create a soup of problems for your team.

This metaphorically grinds the gears of your growing software company to a halt. Your investors didn't write you a check to be an integration company--unless you are one--yet you have to spend more and more time and money on integrations.

And, since most software companies are not integration companies, it is uncommon that you have engineers who have experience with building scalable product integrations. So, you keep spending more and getting roughly the same result.

What does "best of breed" product integration look like?

A best of breed product integration program looks different. It's value-additive, not a cost burden to the business. It's a feature not a bug. It's an enabler of revenue, not an inhibitor or product innovation.

That program looks like this:

Consistency, repeatability, and throughput are key to making product integration really work for your software company. It's not just about the "building the thing" part of the process.

Explore and Triage

Your program should have a regular process for exploring and collecting integration opportunities. These might come directly from sales leads. They may come in from the partnership organization moving relationships forward.

You can also use market research, customer development and other "outbound" methodologies to add integrations to the queue that may be good strategic opportunities. Where are your competitors not? Where are they, but aren't executing well? What new interesting experiences could you create with certain integrations?

Then, as you collect integration opportunities, you need to triage and prioritize them. You have a limited capacity to deliver integrations and hopefully more opportunity than you can address. That means you want to ensure you take on the best opportunities first.

First, use a standard structure for defining the business case for a product integration opportunity. It should include assesments of revenue potential, known difficulties, and strategic value. Then set a regular cadence of estimating and prioritizing the opportunities based on their relative effort and impact.

Then work from the top down.

It's important to understand that regularity is key. The backlog of integration opportunities should be a living thing, not a static punch list. Don't just do this exercise once and move on.

Design

What often rears its head as technical complexity for an engineer is actually something else. It's lack of business understanding of the integration and lack of an integration design (i.e. requirements) that delivers on that understanding.

Most software teams utilize some form of requirements definition for product integrations, but it usually lacks in some/all of the following ways:

• Lack of consistency from one integration project to the next
• Too much design that is based on a single customer's requirements
• Not designed from a foundation of business use cases that represent the desired inter-product experience
• Lack of thought for and documentation of the deficiencies and incompatibilities of the two APIs in question, relative to use cases
• Did not include a suite of tests that demonstrate how the integration will deliver on the use cases
• Lack of consideration for how the integration will be "templatized" for use from end customer to end customer
• Lack of consideration for how the integration will be managed over time

Building a product integration is kind of like building a product feature in terms of how you design it. Don't fall into the trap of assuming that it's a technical task and a developer can figure it out.

Deploy and Monitor

Eventually you do have to put pen to paper, so to speak, and actually produce the integration. The more able you are to do so with minimal coding and minimal variation reduces time to market and total cost of ownership.

This is where the integration technology itself plays the biggest role.

Usually an early-stage engineering team's default approach is to "build it"--to write the code themselves. This turns into conversations about how to build a properly reusable integration layer for the product, how to manage all the data flow across compute resources that cost money, and how to see what's happening with data in movement so you can support customers.

None of these conversations is about your core product offering, and none of them are small conversations.

A best of breed program uses best of breed technology to create consistency of delivery and automation of monitoring. Today that usually takes the form of an embedded iPaaS system.

This takes your engineering team away from solving problems that have already been solved, so they can focus on your customer's problems and your product that solves them.

Measure and Market

For a product integration to be as value additive as possible, it must have life beyond the initial construction. An in-market integration that serves actual customer needs is a huge marketing asset. It should be leveraged as such.

Measuring the data in motion through your integrations has both internal and external efforts. 

Internally, you can attach customer business value to certain things (good and bad) happening to the integration. This helps with prioritizing issues to be addressed and gives customer success teams a data to bring into their conversations with customers. Externally, it provides that same detail to your marketing and sales teams, to help them drive more adoption of your product by touting its integration capabilities.

Marketing how many integrations you offer and how effective they are at delivering business value is a huge asset. Make sure you have the tools and processes in place to bring those integrations to market.

How To Get There

While this sounds like a lot, understanding what it takes to get there is actually quite simple.

You need two things: 1) processes to consistently address each phase in the product integration lifecycle process above and 2) technology that helps you automate as much of that process as possible.

Most software companies, especially. in the growth stage, fly by the seat of their pants in terms of delivering integrations. They custom code or hack together integrations instead of using best of breed technology and disciplined process.

Making even small steps toward building a best of breed integration program can create a serious competitive advantage.