Skip to content

StartupBD: The Integration is the Product

September 1, 2017

We’re in a postmodern era of software where the value of an application isn’t only from features it provides, but what new features it creates when integrated with other applications.

The role of the BD manager is evolving to look like that of a product manager and product marketing manager. But the “product” that needs to be built, maintained and marketed to prospects and customers is an integration. The challenge of the BD team and BD programs is they can build, maintain, market, and measure these integration/products at scale, and in an efficient way.

In any list of application capabilities, many of them inevitably will only be possible when the application is connected to other parts of the IT environment. An unconnected application and a rock in the middle of an open field are equally as awkward in their respective environments.

Sure, you could say that applications have always been connected to one another in some way. But with applications moving to the cloud coupled with the easing ability to create and manage APIs, IT software and hardware that were previously entirely disparate can now connect to share data and create new workflows.

For example, an HR system, a firewall, and a collaboration platform all offer certain value to customers. But when these three systems are deeply integrated and sharing data, new secure workflows are created and/or automated that the creators of the HR system, the firewall, and the collaboration platform could never have individually imagined.

But the customer imagines them because they’re feeling the pain. And the smart vendors learn to imagine them because they listen to the customer.

Gone are the days of the “Barney” partnerships when two companies made a PR announcement that they are working together simply to generate PR. Frankly, no one is fooled anymore; customers aren’t impressed by such announcements, to say nothing of the journalists who are expected to cover it.

BD teams (the good ones, anyway) now actively discuss customer use cases when contemplating an integration between their respective companies. Is there a real use case that can be jointly solved? Has the use case been validated by the market?

And as important, once the integration is completed, is there commitment from both companies to bring the feature/integration to market through marketing and sales activities?

Such is the rise of the customer validated use case solved not by a product, but by an integration.

Integrations therefore need to be created and treated as if they were products. A customer will often want to know not only what the application does, but how deeply it integrates with other applications and what new use cases created and solved by this integration.


Comments are closed.

%d bloggers like this: